[PATCH weston 2/6] protocol: add Presentation feedback flags
ppaalanen at gmail.com
Wed Dec 17 06:20:39 PST 2014
From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
Add the missing feedback flags to the Presentation extension protocol
These flags are slightly different from the previous RFCv3.1 definition:
Now, all compositors are safe to use 0 as the flags if they don't bother
setting them properly. 0 is the "worst case" with the least guarantees.
The meaning of ZERO_COPY is not exactly the opposite of the old COPY
flag. ZERO_COPY is more strict, but applies only to that one surface.
Therefore it can be used to verify a zero-copy video playback pipeline,
also to a hardware overlay.
There is no longer a flag to clearly indicate if the final presentation
was done by a copy or a page flip. ZERO_COPY forbids the copy, but VSYNC
alone does allow copy in case it cannot tear. It is possible to have
first a compositing pass, and then another copy into the frontbuffer,
and still set VSYNC if it cannot tear. Usually "cannot tear" is too
hard to guarantee with a copy, so it often implies a page flip.
Signed-off-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
Cc: Mario Kleiner <mario.kleiner.de at gmail.com>
protocol/presentation_timing.xml | 42 +++++++++++++++++++++++++++++++++++++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/protocol/presentation_timing.xml b/protocol/presentation_timing.xml
index 5752c13..4058d47 100644
@@ -164,11 +164,47 @@
<description summary="bitmask of flags in presented event">
- Currently no flags are defined. Some flags will be added
- into presentation_feedback version 1 before it is released.
+ These flags provide information about how the presentation of
+ the related content update was done. The intent is to help
+ clients assess the reliability of the feedback and the visual
+ quality with respect to possible tearing and timings. The
+ flags are:
+ The presentation was synchronized to the "vertical retrace" by
+ the display hardware such that tearing does not happen.
+ Relying on user space scheduling is not acceptable for this
+ flag. If presentation is done by a copy to the active
+ frontbuffer, then it must guarantee that tearing cannot
+ The display hardware provided measurements that the hardware
+ driver converted into a presentation timestamp. Sampling a
+ clock in user space is not acceptable for this flag.
+ The display hardware signalled that it started using the new
+ image content. The opposite of this is e.g. a timer being used
+ to guess when the display hardware has switched to the new
+ image content.
+ The presentation of this update was done zero-copy. This means
+ the buffer from the client was given to display hardware as
+ is, without copying it. Compositing with OpenGL counts as
+ copying, even if textured directly from the client buffer.
+ Possible zero-copy cases include direct scanout of a
+ fullscreen surface and a surface on a hardware overlay.
- <entry name="dummy" value="0"/>
+ <entry name="vsync" value="0x1" summary="presentation was vsync'd"/>
+ <entry name="hw_clock" value="0x2"
+ summary="hardware provided the presentation timestamp"/>
+ <entry name="hw_completion" value="0x4"
+ summary="hardware signalled the start of the presentation"/>
+ <entry name="zero_copy" value="0x8"
+ summary="presentation was done zero-copy"/>
More information about the wayland-devel