This is a tracker bug for the Presentation extension development. If you want to work on it, contact me first. The Presentation extension contains two big pieces: feedback and queueing. Feedback is basically ready for upstream. Queueing OTOH depends on bugs #75303 and #78190. pq's Presentation series should be split into two consecutive series: the first one introduces feedback only, and the second one bumps the interface version and adds queueing. The end result should be identical code to the original. Then, take the feedback series, rebase it on Weston master branch, and send it to wayland-devel@ for review. You can find the Presentation series at http://cgit.collabora.com/git/user/pq/weston.git/log/?h=presentation-WIP4 The implementation patches are probably fairly well separated already, but you need to split the protocol XML file, stubs, and the presentation-shm demo client commits.
Louis-Francis is currently working to get the feedback part out.
Once the feedback part is merged with empty flags, we should re-think the feedback flags from RFCv3.1. flags=0 is something that the fbdev of x11 backend would use, i.e. "the worst case": no accurate timestamps, copies all over, everything composited, tearing, etc. so that if a backend or compositor does not implement flags, it can just send 0 and apps will know the presentation is not... erm... "good". Then think if each flags makes sense, and define them such that sending 0 when it actually should be 1 is not harmful or promising too much, while sending 1 when it should be 0 is a compositor bug. Need to make sure we have a flag for direct scanout. It is especially useful for automated video playing tests: we want to be sure the video in a very controlled setup will always go to an overlay. Such a test may catch regressions not only in the video player, but GStreamer, EGL, the compositor, gfx drivers both in user space and kernel, etc.
Louis-Francis sent the feedback series: http://lists.freedesktop.org/archives/wayland-devel/2014-September/017278.html I think we should remove the destructor protocol from presentation_feedback interface, and say that 'presented' and 'discarded' events destroy the protocol object. I seem to recall we also got some comments towards that in the past, too.
New version of the specification (v5) was submitted to the mailing list: http://lists.freedesktop.org/archives/wayland-devel/2014-September/017476.html Changes compared to last proposal are: * Remove the 'destroy' method from the feedback object. * Some grammatical corrections to the protocol specification. Thanks to Bryce Harrington.
v5 of feedback with some minor changes is now in master. The next step is to re-think the feedback flags.
Note: explicit fencing may affect the design of the queueing extension.
New feedback flags for review: http://lists.freedesktop.org/archives/wayland-devel/2014-December/019082.html
Presentation feedback flags have been merged and will be released with Weston 1.7.0. Presentation feedback is now done.
Correction: Presentation feedback may need a re-design: http://lists.freedesktop.org/archives/dri-devel/2015-July/086762.html
(In reply to Pekka Paalanen from comment #9) > Correction: Presentation feedback may need a re-design: > http://lists.freedesktop.org/archives/dri-devel/2015-July/086762.html Sorry, false alarm.
Stabilization of the Presentation feedback extension is tracked at https://phabricator.freedesktop.org/T43
Fixed with https://cgit.freedesktop.org/xorg/xserver/commit/?id=fee0827a9a695600765f3d04376fc9babe497401 and the preceding couple of commits.
Wrong bug ...
Presentation feedback has been released in wayland-protocols 1.2 as a stable extension. I suppose this report stays open until someone develops the queueing extension.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/wayland/weston/issues/41.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.