Make use of presentation-time protocol
Introduction
The final goal here is to make use of the presentation-time protocol [1] in XWayland for X11 Presented windows. X11 Present extension provides X11 clients with MSC/UST timestamps for presented Pixmaps [2].
Currently in XWayland we just return the system time when the frame callback gets processed by XWayland or when a timer runs out [3]. This is not the real time of presentation.
But analogous to the X11 PresentCompleteNotify event there exists the presented event of the presentation-time protocol that is supposed to give back the real time of last commit's presentation and some auxiliary data for allowing a Wayland client to synchronize its painting loop with the the screen moving forward.
Design differences
The Wayland protocol (that means the presentation-time protocol) and X11 Present extension design do not match perfectly though:
- X11 Present provides clients with the current UST/MSC values continuously on request or triggers an event when a certain MSC is reached. Wayland protocol only retroactively informs clients of last commit's clock/MSC value and only if the commit actually was visible on the output (for example not if the surface is occluded). Instead the client is expected to drive its painting loop according to the refresh argument the presented event provides and realign it with later events.
- In X11 Present the output/crtc the Pixmap presentation is synchronized to is transparent to the client while Wayland protocol specifies this explicitly. On an output target change X11 Present transforms the MSC delta such that for the client it is monotonic.
Advantages/challenges
Making use of presentation-time protocol has the following advantages for us:
- X11 clients can synchronize to the real presentation time.
- XWayland Present implementation can use the sync_output event and the refresh argument of the presented event to provide better MSC feedback than currently with the frame callbacks and a fallback timer [4].
The following challenges:
- The calculated MSC value can diverge from the real MSC value over time when a surface is not visible and no presented event is received for long periods to realign the calculation timer with. Idea: Do not expose the "real" output MSC values and keep the current mechanism to have a MSC value per X11 window. Bump these according to refresh value.
- Explicit output synchronization is not part of X11 Presented extension. Idea: Do not expose output information and just as now set the first crtc [5]. On output sync change just keep on bumping the window's MSC value, now with the new refresh rate.
- For certain displays Wayland protocol requires the refresh argument to be zero [6]. What kind of displays are these in practice (adaptive-sync?) and how to handle them?
- We have one more code path if a compositor does not support presentation-time protocol. Idea: Since presentation-time is one of currently only three stable protocol extensions [7] we can justify to require Wayland compositors with XWM part to support this extension if they want to make use Presented Pixmaps in upcoming XWayland releases.
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/blob/master/stable/presentation-time/presentation-time.xml
[2] https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/f61f9a3ee1aa77ebcc67730cda9bfde88e4e9c5f/presentproto.txt#L392
[3] https://gitlab.freedesktop.org/xorg/xserver/blob/0839b0523a01067cb9c9b53ebdd9ce4c00f0eb12/hw/xwayland/xwayland-present.c#L203
[4] https://gitlab.freedesktop.org/xorg/xserver/blob/0839b0523a01067cb9c9b53ebdd9ce4c00f0eb12/hw/xwayland/xwayland-present.c#L38
[5] https://gitlab.freedesktop.org/xorg/xserver/blob/0839b0523a01067cb9c9b53ebdd9ce4c00f0eb12/hw/xwayland/xwayland-present.c#L313
[6] https://gitlab.freedesktop.org/wayland/wayland-protocols/blob/82d4c152a5163fc39c6c1fbf3b27578449d6be8e/stable/presentation-time/presentation-time.xml#L228
[7] https://gitlab.freedesktop.org/wayland/wayland-protocols/tree/master/stable