From: Pekka Paalanen <[email protected]> Hi all,
here is the third RFC of the Wayland Presentation protocol, now with a complete implementation! RFCv2 can be found at http://lists.freedesktop.org/archives/wayland-devel/2014-January/012988.html and the email thread contains extensive discussion, from which the conclusions have been implemented. Let me know, if I missed something. The changes to the protocol itself are listed in patch 6/15. I have not forgot about the new features listed in http://cgit.collabora.com/git/user/pq/weston.git/tree/buffer-queue3.txt?h=buffer-queue-spec 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 protocol. 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 http://cgit.collabora.com/git/user/pq/weston.git/log/?h=presentation-RFCv3 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 details. Mode -f, feedback from frame callback driven immediate commit loop: 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 http://lists.freedesktop.org/archives/wayland-devel/2014-February/013182.html Some of the interactions between resizing, queueing, sub-surfaces, and wl_viewport have been discussed in http://lists.freedesktop.org/archives/wayland-devel/2014-February/013293.html 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 else? Thanks, pq Btw. this will probably miss the April release of Weston since I have other projects. -- 1.8.3.2 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
