wp_presentation: Issues with definition of wp_presentation_feedback::presented timestamp semantics
From the spec:
The timestamp corresponds to the time when the content update
turned into light [...]AFAIK no compositor implements this so far. Instead, the reported timestamp is from the KMS atomic commit completion event, which corresponds to when the display hardware starts scanning out the frame with the new surface contents. The first resulting photons will generally be emitted at least a few milliseconds later, potentially multiple display refresh cycles later though.
This was discussed before, e.g. in !248 (comment 2248796), where the suggestion was that compositors should just be fixed to comply with the spec text on a best-effort basis. Some issues with that:
-
While HDMI has information about the delay between scanout and photon emission in EDID, I'm not sure DisplayPort does as well, and e.g. DVI/VGA most certainly don't. So the compositor can't always automatically determine a plausible interval between the starts of scanout and photon emission. This means that the timestamp effectively corresponds to either scanout or photon emission, depending on circumstances the client cannot know about.
-
Existing clients which rely on the current reality that the timestamps correspond to scanout may start malfunctioning if the timestamps start corresponding to photon emission. (@derekf previously raised a similar point in !248 (comment 2250793))
-
Xwayland can't make use of the wp_presentation protocol timestamps if they correspond to photon emission. While the Present extension spec is a bit vague on the semantics of the timestamps, in practice they have always corresponded to scanout in the xserver implementation, so that's what X clients expect. If Xwayland started setting timestamps corresponding to photon emission instead, some clients would likely break.
Proposed solution
- Change the spec text to match current reality that the timestamp corresponds to start of scanout. This solves all 3 issues above.
- Add a new event which reports the compositor's estimate of the interval between start of scanout and start of photon emission. There's a special value which means "don't know".
Together, this allows clients to reliably know what the timestamps correspond to, and to calculate the estimated start of photon emission if desired and possible.