[RFCv3 weston 00/15] Wayland Presentation extension

Pekka Paalanen ppaalanen at gmail.com
Fri Mar 7 04:03:48 PST 2014

From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>

Hi all,

here is the third RFC of the Wayland Presentation protocol, now
with a complete implementation!

RFCv2 can be found at
and the email thread contains extensive discussion, from which
the conclusions have been implemented. Let me know, if I missed

The changes to the protocol itself are listed in patch 6/15. I
have not forgot about the new features listed in
and I intend to write a protocol patch to get the discussion
about those started.

The impact to the Wayland core protocol still exists, but is
mitigated by the fact that frame callbacks are no longer queued,
and hence whether there is an attach or not does not affect the
processing of frame callbacks on commit.

Still, doing an immediate commit without a preceding
wl_surface.attach is defined to work differently than in the
core: the buffer state will not be applied without an attach.
IOW, you cannot change e.g. buffer_scale without attaching a
wl_buffer. In my opinion, the newly disabled actions did not make
sense in the first place, but it is still a change to the core

Kristian, patches 1-5 are clean-ups and refactoring to prepare
for the Presentation extension. If you like where this is going,
you could merge those already.

Patch 6 adds the protocol, patches 7 and 9-12 implement the
extension, patches 8 and 13 add clients to test the extensions,
and patch 14 serves as a reminder that I still intend to change
the wl_viewport interface.

Do we want things like patch 15 in Weston?

This whole patch set is available at
  git://git.collabora.co.uk/git/user/pq/weston.git presentation-RFCv3

Pekka Paalanen (15):
  compositor: refactor more into weston_surface_attach
  compositor: buffer can be non-NULL only if newly_attached
  compositor: refactor code into weston_surface_reset_pending_buffer()
  compositor: reorganize struct weston_buffer_viewport
  compositor: replace weston_buffer_viewport::viewport_set
  protocol: add presentation extension RFC v3
  compositor: add stub implementation of presentation interface
  weston-info: report presentation clock
  compositor: set and use the presentation clock everywhere
  compositor: implement presentation_feedback
  compositor-drm: deliver frame seq for feedback
  compositor: implement presentation.queue
  clients: add presentation-shm demo
  protocol: add scaler TODO
  compositor: add presentation debug functions

 .gitignore                       |   1 +
 Makefile.am                      |  16 +
 clients/presentation-shm.c       | 929 +++++++++++++++++++++++++++++++++++++++
 clients/weston-info.c            |  81 ++++
 desktop-shell/shell.c            |   6 +-
 protocol/presentation_timing.xml | 434 ++++++++++++++++++
 protocol/scaler.xml              |   4 +
 src/compositor-drm.c             |  58 ++-
 src/compositor-fbdev.c           |  12 +-
 src/compositor-headless.c        |  11 +-
 src/compositor-rdp.c             |  11 +-
 src/compositor-rpi.c             |  48 +-
 src/compositor-wayland.c         |  11 +-
 src/compositor-x11.c             |  11 +-
 src/compositor.c                 | 861 +++++++++++++++++++++++++++++++++---
 src/compositor.h                 |  70 ++-
 src/gl-renderer.c                |   2 +-
 src/pixman-renderer.c            |  26 +-
 18 files changed, 2431 insertions(+), 161 deletions(-)
 create mode 100644 clients/presentation-shm.c
 create mode 100644 protocol/presentation_timing.xml

Here are some examples of weston-presentation-shm statistics
output on Weston on DRM with gl-renderer. See patch 13 for more

Mode -f, feedback from frame callback driven immediate commit

     7: f2c  1 ms, c2p 32 ms, f2p 33 ms, p2p 16648 us, t2p 32670, seq 7741506
     8: f2c  0 ms, c2p 33 ms, f2p 33 ms, p2p 16650 us, t2p 32677, seq 7741507
     9: f2c  1 ms, c2p 33 ms, f2p 34 ms, p2p 16652 us, t2p 32671, seq 7741508
    10: f2c  1 ms, c2p 32 ms, f2p 33 ms, p2p 16648 us, t2p 32700, seq 7741509
    11: f2c  0 ms, c2p 33 ms, f2p 33 ms, p2p 16651 us, t2p 32680, seq 7741510

Mode -q, queueing with feedback for every frame, random
committing order:

   172: c2p   32 ms, p2p 16650 us, t2p   -30 us, seq 7742478
   130: c2p   50 ms, p2p 16652 us, t2p   -43 us, seq 7742479
   133: c2p   67 ms, p2p 16651 us, t2p   -56 us, seq 7742480
   151: c2p   83 ms, p2p 16656 us, t2p   -65 us, seq 7742481
   166: c2p   99 ms, p2p 16642 us, t2p   -88 us, seq 7742482
   177: c2p  115 ms, p2p 16652 us, t2p  -101 us, seq 7742483
   174: c2p  132 ms, p2p 16648 us, t2p  -117 us, seq 7742484
   159: c2p  150 ms, p2p 16651 us, t2p  -131 us, seq 7742485
   148: c2p  166 ms, p2p 16651 us, t2p  -145 us, seq 7742486

Note, that the refresh period is taken as 1/refresh_frequency,
which becomes 16666 us, but the actual measured period is
slightly less on my machine. Since weston-presentation-shm does
not continuously correct for the drift, you see that the
difference between the target timestamp and realized presentation
grows. Still, it would take quite a long time to start missing
the correct refresh cycle.

The chosen timing algorithm in the protocol aims to achieve
t2p = 0 by default and on "average", rather than t2p = half of
refresh period. An explanation of the timing algorithm and a
diagram can be found at

Some of the interactions between resizing, queueing, sub-surfaces,
and wl_viewport have been discussed in
but that still needs verification by a running demo program.

I think we should start dicussing, how do we want the protocol
interfaces to be designed. Do we want a global method with
wl_surface as an argument (as in this implementation), the
factory approach like wl_scaler/wl_viewport etc., or something


Btw. this will probably miss the April release of Weston since I
have other projects.


More information about the wayland-devel mailing list