Wayland presentation extension (video protocol) WIP after RFCv2

[Michel Dänzer]

Hi Pekka,


reviving an old topic... Inspired by the thread "RFC for a render API to
support adaptive sync and VRR" currently happening on the dri-devel list.


On 2014-02-26 10:30 AM, Pekka Paalanen wrote:
> Hi all,
> 
> I just wanted to mention where I am with this at the moment, as it
> seems like it will be some time before I can come back to this.
> 
> The RFCv2 thread started at:
> http://lists.freedesktop.org/archives/wayland-devel/2014-January/012988.html
> 
> Since then, there has been plenty of discussion, some protocol changes
> towards a v3, and I have a WIP implementation. My current work can be
> found at
> http://cgit.collabora.com/git/user/pq/weston.git/log/?h=presentation-WIP2
> for now. When I get back, the branch will be rewritten and/or
> abandoned.

I looked at
https://git.collabora.com/cgit/user/pq/weston.git/commit/?h=presentation-WIP4&id=5cacb71c28052d9a491ad969d74d9145cfe9936d
.


First, I'd like to question that "turns-to-light" are good semantics for
the timestamps, since the Wayland compositor and driver stack generally
don't know the delay from scanout to the display emitting light.
Applications which are sensitive to this delay can deal with it by other
means, e.g.:

* Video players usually have a delay setting, which the user can tweak
  for optimal audio/video sync.
* Some games have a calibration function, e.g. displaying regular
  flashes and asking the player to press a button on each flash.
* Mario has access to very precise measurement gear at work, the data
  from which is used in applications for this I presume.

The protocol tries to account for that the compositor may approximate
the "turns-to-light" time:

        Compositors may approximate this from the framebuffer flip
        completion events from the system, and the latency of the
        physical display path if known.

But I'm afraid that's not really helpful, as it means the application
cannot trust the timestamps but needs something as described above
anyway. So it doesn't really buy anything over "scanout starts"
semantics, for which the driver stack can provide accurate timestamps.


Also, both higher-level APIs I know of which allow the application to
specify a target timestamp for presentation (VDPAU and
VK_GOOGLE_display_timing) use "not before" semantics. So, maybe the
not_before flag can be dropped, and flags can be added later for
different semantics, if a need for them ever materializes.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer