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="1"> 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 Linux/glibc, 101 the identifier value is one of the clockid_t values accepted 102 by clock_gettime(). clock_gettime() is defined by 103 POSIX.1-2001. 104 105 Timestamps in this clock domain are expressed as tv_sec_hi, 106 tv_sec_lo, tv_nsec triples, each component being an unsigned 107 32-bit value. Whole seconds are in tv_sec which is a 64-bit 108 value combined from tv_sec_hi and tv_sec_lo, and the 109 additional fractional part in tv_nsec as nanoseconds. Hence, 110 for valid timestamps tv_nsec must be in [0, 999999999]. 111 112 Note that clock_id applies only to the presentation clock, 113 and implies nothing about e.g. the timestamps used in the 114 Wayland core protocol input events. 115 116 Compositors should prefer a clock which does not jump and is 117 not slewed e.g. by NTP. The absolute value of the clock is 118 irrelevant. Precision of one millisecond or better is 119 recommended. Clients must be able to query the current clock 120 value directly, not by asking the compositor. 121 </description> 122 <arg name="clk_id" type="uint" summary="platform clock identifier"/> 123 </event> 124 125 </interface> 126 127 <interface name="wp_presentation_feedback" version="1"> 128 <description summary="presentation time feedback event"> 129 A presentation_feedback object returns an indication that a 130 wl_surface content update has become visible to the user. 131 One object corresponds to one content update submission 132 (wl_surface.commit). There are two possible outcomes: the 133 content update is presented to the user, and a presentation 134 timestamp delivered; or, the user did not see the content 135 update because it was superseded or its surface destroyed, 136 and the content update is discarded. 137 138 Once a presentation_feedback object has delivered a 'presented' 139 or 'discarded' event it is automatically destroyed. 140 </description> 141 142 <event name="sync_output"> 143 <description summary="presentation synchronized to this output"> 144 As presentation can be synchronized to only one output at a 145 time, this event tells which output it was. This event is only 146 sent prior to the presented event. 147 148 As clients may bind to the same global wl_output multiple 149 times, this event is sent for each bound instance that matches 150 the synchronized output. If a client has not bound to the 151 right wl_output global at all, this event is not sent. 152 </description> 153 <arg name="output" type="object" interface="wl_output" 154 summary="presentation output"/> 155 </event> 156 157 <enum name="kind"> 158 <description summary="bitmask of flags in presented event"> 159 These flags provide information about how the presentation of 160 the related content update was done. The intent is to help 161 clients assess the reliability of the feedback and the visual 162 quality with respect to possible tearing and timings. The 163 flags are: 164 165 VSYNC: 166 The presentation was synchronized to the "vertical retrace" by 167 the display hardware such that tearing does not happen. 168 Relying on user space scheduling is not acceptable for this 169 flag. If presentation is done by a copy to the active 170 frontbuffer, then it must guarantee that tearing cannot 171 happen. 172 173 HW_CLOCK: 174 The display hardware provided measurements that the hardware 175 driver converted into a presentation timestamp. Sampling a 176 clock in user space is not acceptable for this flag. 177 178 HW_COMPLETION: 179 The display hardware signalled that it started using the new 180 image content. The opposite of this is e.g. a timer being used 181 to guess when the display hardware has switched to the new 182 image content. 183 184 ZERO_COPY: 185 The presentation of this update was done zero-copy. This means 186 the buffer from the client was given to display hardware as 187 is, without copying it. Compositing with OpenGL counts as 188 copying, even if textured directly from the client buffer. 189 Possible zero-copy cases include direct scanout of a 190 fullscreen surface and a surface on a hardware overlay. 191 </description> 192 <entry name="vsync" value="0x1" summary="presentation was vsync'd"/> 193 <entry name="hw_clock" value="0x2" 194 summary="hardware provided the presentation timestamp"/> 195 <entry name="hw_completion" value="0x4" 196 summary="hardware signalled the start of the presentation"/> 197 <entry name="zero_copy" value="0x8" 198 summary="presentation was done zero-copy"/> 199 </enum> 200 201 <event name="presented"> 202 <description summary="the content update was displayed"> 203 The associated content update was displayed to the user at the 204 indicated time (tv_sec_hi/lo, tv_nsec). For the interpretation of 205 the timestamp, see presentation.clock_id event. 206 207 The timestamp corresponds to the time when the content update 208 turned into light the first time on the surface's main output. 209 Compositors may approximate this from the framebuffer flip 210 completion events from the system, and the latency of the 211 physical display path if known. 212 213 This event is preceded by all related sync_output events 214 telling which output's refresh cycle the feedback corresponds 215 to, i.e. the main output for the surface. Compositors are 216 recommended to choose the output containing the largest part 217 of the wl_surface, or keeping the output they previously 218 chose. Having a stable presentation output association helps 219 clients predict future output refreshes (vblank). 220 221 The 'refresh' argument gives the compositor's prediction of how 222 many nanoseconds after tv_sec, tv_nsec the very next output 223 refresh may occur. This is to further aid clients in 224 predicting future refreshes, i.e., estimating the timestamps 225 targeting the next few vblanks. If such prediction cannot 226 usefully be done, the argument is zero. 227 228 If the output does not have a constant refresh rate, explicit 229 video mode switches excluded, then the refresh argument must 230 be zero. 231 232 The 64-bit value combined from seq_hi and seq_lo is the value 233 of the output's vertical retrace counter when the content 234 update was first scanned out to the display. This value must 235 be compatible with the definition of MSC in 236 GLX_OML_sync_control specification. Note, that if the display 237 path has a non-zero latency, the time instant specified by 238 this counter may differ from the timestamp's. 239 240 If the output does not have a concept of vertical retrace or a 241 refresh cycle, or the output device is self-refreshing without 242 a way to query the refresh count, then the arguments seq_hi 243 and seq_lo must be zero. 244 </description> 245 <arg name="tv_sec_hi" type="uint" 246 summary="high 32 bits of the seconds part of the presentation timestamp"/> 247 <arg name="tv_sec_lo" type="uint" 248 summary="low 32 bits of the seconds part of the presentation timestamp"/> 249 <arg name="tv_nsec" type="uint" 250 summary="nanoseconds part of the presentation timestamp"/> 251 <arg name="refresh" type="uint" summary="nanoseconds till next refresh"/> 252 <arg name="seq_hi" type="uint" 253 summary="high 32 bits of refresh counter"/> 254 <arg name="seq_lo" type="uint" 255 summary="low 32 bits of refresh counter"/> 256 <arg name="flags" type="uint" summary="combination of 'kind' values"/> 257 </event> 258 259 <event name="discarded"> 260 <description summary="the content update was not displayed"> 261 The content update was never displayed to the user. 262 </description> 263 </event> 264 </interface> 265 266 </protocol> 267
