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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel