1<?xml version="1.0" encoding="UTF-8"?>
2<protocol name="presentation_time">
3<!-- wrap:70 -->
4
5 <copyright>
6 Copyright © 2013-2014 Collabora, Ltd.
7
8 Permission is hereby granted, free of charge, to any person obtaining a
9 copy of this software and associated documentation files (the "Software"),
10 to deal in the Software without restriction, including without limitation
11 the rights to use, copy, modify, merge, publish, distribute, sublicense,
12 and/or sell copies of the Software, and to permit persons to whom the
13 Software is furnished to do so, subject to the following conditions:
14
15 The above copyright notice and this permission notice (including the next
16 paragraph) shall be included in all copies or substantial portions of the
17 Software.
18
19 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
20 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
21 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
22 THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
23 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
24 FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
25 DEALINGS IN THE SOFTWARE.
26 </copyright>
27
28 <interface name="wp_presentation" version="2">
29 <description summary="timed presentation related wl_surface requests">
30
31<!-- Introduction -->
32
33 The main feature of this interface is accurate presentation
34 timing feedback to ensure smooth video playback while maintaining
35 audio/video synchronization. Some features use the concept of a
36 presentation clock, which is defined in the
37 presentation.clock_id event.
38
39 A content update for a wl_surface is submitted by a
40 wl_surface.commit request. Request 'feedback' associates with
41 the wl_surface.commit and provides feedback on the content
42 update, particularly the final realized presentation time.
43
44<!-- Completing presentation -->
45
46 When the final realized presentation time is available, e.g.
47 after a framebuffer flip completes, the requested
48 presentation_feedback.presented events are sent. The final
49 presentation time can differ from the compositor's predicted
50 display update time and the update's target time, especially
51 when the compositor misses its target vertical blanking period.
52 </description>
53
54 <enum name="error">
55 <description summary="fatal presentation errors">
56 These fatal protocol errors may be emitted in response to
57 illegal presentation requests.
58 </description>
59 <entry name="invalid_timestamp" value="0"
60 summary="invalid value in tv_nsec"/>
61 <entry name="invalid_flag" value="1"
62 summary="invalid flag"/>
63 </enum>
64
65 <request name="destroy" type="destructor">
66 <description summary="unbind from the presentation interface">
67 Informs the server that the client will no longer be using
68 this protocol object. Existing objects created by this object
69 are not affected.
70 </description>
71 </request>
72
73 <request name="feedback">
74 <description summary="request presentation feedback information">
75 Request presentation feedback for the current content submission
76 on the given surface. This creates a new presentation_feedback
77 object, which will deliver the feedback information once. If
78 multiple presentation_feedback objects are created for the same
79 submission, they will all deliver the same information.
80
81 For details on what information is returned, see the
82 presentation_feedback interface.
83 </description>
84 <arg name="surface" type="object" interface="wl_surface"
85 summary="target surface"/>
86 <arg name="callback" type="new_id" interface="wp_presentation_feedback"
87 summary="new feedback object"/>
88 </request>
89
90 <event name="clock_id">
91 <description summary="clock ID for timestamps">
92 This event tells the client in which clock domain the
93 compositor interprets the timestamps used by the presentation
94 extension. This clock is called the presentation clock.
95
96 The compositor sends this event when the client binds to the
97 presentation interface. The presentation clock does not change
98 during the lifetime of the client connection.
99
100 The clock identifier is platform dependent. On POSIX platforms, the
101 identifier value is one of the clockid_t values accepted by
102 clock_gettime(). clock_gettime() is defined by POSIX.1-2001.
103
104 Timestamps in this clock domain are expressed as tv_sec_hi,
105 tv_sec_lo, tv_nsec triples, each component being an unsigned
106 32-bit value. Whole seconds are in tv_sec which is a 64-bit
107 value combined from tv_sec_hi and tv_sec_lo, and the
108 additional fractional part in tv_nsec as nanoseconds. Hence,
109 for valid timestamps tv_nsec must be in [0, 999999999].
110
111 Note that clock_id applies only to the presentation clock,
112 and implies nothing about e.g. the timestamps used in the
113 Wayland core protocol input events.
114
115 Compositors should prefer a clock which does not jump and is
116 not slewed e.g. by NTP. The absolute value of the clock is
117 irrelevant. Precision of one millisecond or better is
118 recommended. Clients must be able to query the current clock
119 value directly, not by asking the compositor.
120 </description>
121 <arg name="clk_id" type="uint" summary="platform clock identifier"/>
122 </event>
123
124 </interface>
125
126 <interface name="wp_presentation_feedback" version="2">
127 <description summary="presentation time feedback event">
128 A presentation_feedback object returns an indication that a
129 wl_surface content update has become visible to the user.
130 One object corresponds to one content update submission
131 (wl_surface.commit). There are two possible outcomes: the
132 content update is presented to the user, and a presentation
133 timestamp delivered; or, the user did not see the content
134 update because it was superseded or its surface destroyed,
135 and the content update is discarded.
136
137 Once a presentation_feedback object has delivered a 'presented'
138 or 'discarded' event it is automatically destroyed.
139 </description>
140
141 <event name="sync_output">
142 <description summary="presentation synchronized to this output">
143 As presentation can be synchronized to only one output at a
144 time, this event tells which output it was. This event is only
145 sent prior to the presented event.
146
147 As clients may bind to the same global wl_output multiple
148 times, this event is sent for each bound instance that matches
149 the synchronized output. If a client has not bound to the
150 right wl_output global at all, this event is not sent.
151 </description>
152 <arg name="output" type="object" interface="wl_output"
153 summary="presentation output"/>
154 </event>
155
156 <enum name="kind" bitfield="true">
157 <description summary="bitmask of flags in presented event">
158 These flags provide information about how the presentation of
159 the related content update was done. The intent is to help
160 clients assess the reliability of the feedback and the visual
161 quality with respect to possible tearing and timings.
162 </description>
163 <entry name="vsync" value="0x1">
164 <description summary="presentation was vsync'd">
165 The presentation was synchronized to the "vertical retrace" by
166 the display hardware such that tearing does not happen.
167 Relying on software scheduling is not acceptable for this
168 flag. If presentation is done by a copy to the active
169 frontbuffer, then it must guarantee that tearing cannot
170 happen.
171 </description>
172 </entry>
173 <entry name="hw_clock" value="0x2">
174 <description summary="hardware provided the presentation timestamp">
175 The display hardware provided measurements that the hardware
176 driver converted into a presentation timestamp. Sampling a
177 clock in software is not acceptable for this flag.
178 </description>
179 </entry>
180 <entry name="hw_completion" value="0x4">
181 <description summary="hardware signalled the start of the presentation">
182 The display hardware signalled that it started using the new
183 image content. The opposite of this is e.g. a timer being used
184 to guess when the display hardware has switched to the new
185 image content.
186 </description>
187 </entry>
188 <entry name="zero_copy" value="0x8">
189 <description summary="presentation was done zero-copy">
190 The presentation of this update was done zero-copy. This means
191 the buffer from the client was given to display hardware as
192 is, without copying it. Compositing with OpenGL counts as
193 copying, even if textured directly from the client buffer.
194 Possible zero-copy cases include direct scanout of a
195 fullscreen surface and a surface on a hardware overlay.
196 </description>
197 </entry>
198 </enum>
199
200 <event name="presented" type="destructor">
201 <description summary="the content update was displayed">
202 The associated content update was displayed to the user at the
203 indicated time (tv_sec_hi/lo, tv_nsec). For the interpretation of
204 the timestamp, see presentation.clock_id event.
205
206 The timestamp corresponds to the time when the content update
207 turned into light the first time on the surface's main output.
208 Compositors may approximate this from the framebuffer flip
209 completion events from the system, and the latency of the
210 physical display path if known.
211
212 This event is preceded by all related sync_output events
213 telling which output's refresh cycle the feedback corresponds
214 to, i.e. the main output for the surface. Compositors are
215 recommended to choose the output containing the largest part
216 of the wl_surface, or keeping the output they previously
217 chose. Having a stable presentation output association helps
218 clients predict future output refreshes (vblank).
219
220 The 'refresh' argument gives the compositor's prediction of how
221 many nanoseconds after tv_sec, tv_nsec the very next output
222 refresh may occur. This is to further aid clients in
223 predicting future refreshes, i.e., estimating the timestamps
224 targeting the next few vblanks. If such prediction cannot
225 usefully be done, the argument is zero.
226
227 For version 2 and later, if the output does not have a constant
228 refresh rate, explicit video mode switches excluded, then the
229 refresh argument must be either an appropriate rate picked by the
230 compositor (e.g. fastest rate), or 0 if no such rate exists.
231 For version 1, if the output does not have a constant refresh rate,
232 the refresh argument must be zero.
233
234 The 64-bit value combined from seq_hi and seq_lo is the value
235 of the output's vertical retrace counter when the content
236 update was first scanned out to the display. This value must
237 be compatible with the definition of MSC in
238 GLX_OML_sync_control specification. Note, that if the display
239 path has a non-zero latency, the time instant specified by
240 this counter may differ from the timestamp's.
241
242 If the output does not have a concept of vertical retrace or a
243 refresh cycle, or the output device is self-refreshing without
244 a way to query the refresh count, then the arguments seq_hi
245 and seq_lo must be zero.
246 </description>
247 <arg name="tv_sec_hi" type="uint"
248 summary="high 32 bits of the seconds part of the presentation timestamp"/>
249 <arg name="tv_sec_lo" type="uint"
250 summary="low 32 bits of the seconds part of the presentation timestamp"/>
251 <arg name="tv_nsec" type="uint"
252 summary="nanoseconds part of the presentation timestamp"/>
253 <arg name="refresh" type="uint" summary="nanoseconds till next refresh"/>
254 <arg name="seq_hi" type="uint"
255 summary="high 32 bits of refresh counter"/>
256 <arg name="seq_lo" type="uint"
257 summary="low 32 bits of refresh counter"/>
258 <arg name="flags" type="uint" enum="kind" summary="combination of 'kind' values"/>
259 </event>
260
261 <event name="discarded" type="destructor">
262 <description summary="the content update was not displayed">
263 The content update was never displayed to the user.
264 </description>
265 </event>
266 </interface>
267
268</protocol>