1<?xml version="1.0" encoding="UTF-8"?> 2<protocol name="linux_dmabuf_v1"> 3 4 <copyright> 5 Copyright © 2014, 2015 Collabora, Ltd. 6 7 Permission is hereby granted, free of charge, to any person obtaining a 8 copy of this software and associated documentation files (the "Software"), 9 to deal in the Software without restriction, including without limitation 10 the rights to use, copy, modify, merge, publish, distribute, sublicense, 11 and/or sell copies of the Software, and to permit persons to whom the 12 Software is furnished to do so, subject to the following conditions: 13 14 The above copyright notice and this permission notice (including the next 15 paragraph) shall be included in all copies or substantial portions of the 16 Software. 17 18 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 19 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 20 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 21 THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 22 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 23 FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 24 DEALINGS IN THE SOFTWARE. 25 </copyright> 26 27 <interface name="zwp_linux_dmabuf_v1" version="5"> 28 <description summary="factory for creating dmabuf-based wl_buffers"> 29 Following the interfaces from: 30 https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt 31 https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt 32 and the Linux DRM sub-system's AddFb2 ioctl. 33 34 This interface offers ways to create generic dmabuf-based wl_buffers. 35 36 Clients can use the get_surface_feedback request to get dmabuf feedback 37 for a particular surface. If the client wants to retrieve feedback not 38 tied to a surface, they can use the get_default_feedback request. 39 40 The following are required from clients: 41 42 - Clients must ensure that either all data in the dma-buf is 43 coherent for all subsequent read access or that coherency is 44 correctly handled by the underlying kernel-side dma-buf 45 implementation. 46 47 - Don't make any more attachments after sending the buffer to the 48 compositor. Making more attachments later increases the risk of 49 the compositor not being able to use (re-import) an existing 50 dmabuf-based wl_buffer. 51 52 The underlying graphics stack must ensure the following: 53 54 - The dmabuf file descriptors relayed to the server will stay valid 55 for the whole lifetime of the wl_buffer. This means the server may 56 at any time use those fds to import the dmabuf into any kernel 57 sub-system that might accept it. 58 59 However, when the underlying graphics stack fails to deliver the 60 promise, because of e.g. a device hot-unplug which raises internal 61 errors, after the wl_buffer has been successfully created the 62 compositor must not raise protocol errors to the client when dmabuf 63 import later fails. 64 65 To create a wl_buffer from one or more dmabufs, a client creates a 66 zwp_linux_dmabuf_params_v1 object with a zwp_linux_dmabuf_v1.create_params 67 request. All planes required by the intended format are added with 68 the 'add' request. Finally, a 'create' or 'create_immed' request is 69 issued, which has the following outcome depending on the import success. 70 71 The 'create' request, 72 - on success, triggers a 'created' event which provides the final 73 wl_buffer to the client. 74 - on failure, triggers a 'failed' event to convey that the server 75 cannot use the dmabufs received from the client. 76 77 For the 'create_immed' request, 78 - on success, the server immediately imports the added dmabufs to 79 create a wl_buffer. No event is sent from the server in this case. 80 - on failure, the server can choose to either: 81 - terminate the client by raising a fatal error. 82 - mark the wl_buffer as failed, and send a 'failed' event to the 83 client. If the client uses a failed wl_buffer as an argument to any 84 request, the behaviour is compositor implementation-defined. 85 86 For all DRM formats and unless specified in another protocol extension, 87 pre-multiplied alpha is used for pixel values. 88 89 Unless specified otherwise in another protocol extension, implicit 90 synchronization is used. In other words, compositors and clients must 91 wait and signal fences implicitly passed via the DMA-BUF's reservation 92 mechanism. 93 </description> 94 95 <request name="destroy" type="destructor"> 96 <description summary="unbind the factory"> 97 Objects created through this interface, especially wl_buffers, will 98 remain valid. 99 </description> 100 </request> 101 102 <request name="create_params"> 103 <description summary="create a temporary object for buffer parameters"> 104 This temporary object is used to collect multiple dmabuf handles into 105 a single batch to create a wl_buffer. It can only be used once and 106 should be destroyed after a 'created' or 'failed' event has been 107 received. 108 </description> 109 <arg name="params_id" type="new_id" interface="zwp_linux_buffer_params_v1" 110 summary="the new temporary"/> 111 </request> 112 113 <event name="format"> 114 <description summary="supported buffer format"> 115 This event advertises one buffer format that the server supports. 116 All the supported formats are advertised once when the client 117 binds to this interface. A roundtrip after binding guarantees 118 that the client has received all supported formats. 119 120 For the definition of the format codes, see the 121 zwp_linux_buffer_params_v1::create request. 122 123 Starting version 4, the format event is deprecated and must not be 124 sent by compositors. Instead, use get_default_feedback or 125 get_surface_feedback. 126 </description> 127 <arg name="format" type="uint" summary="DRM_FORMAT code"/> 128 </event> 129 130 <event name="modifier" since="3"> 131 <description summary="supported buffer format modifier"> 132 This event advertises the formats that the server supports, along with 133 the modifiers supported for each format. All the supported modifiers 134 for all the supported formats are advertised once when the client 135 binds to this interface. A roundtrip after binding guarantees that 136 the client has received all supported format-modifier pairs. 137 138 For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi == 139 0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event. 140 It indicates that the server can support the format with an implicit 141 modifier. When a plane has DRM_FORMAT_MOD_INVALID as its modifier, it 142 is as if no explicit modifier is specified. The effective modifier 143 will be derived from the dmabuf. 144 145 A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for 146 a given format supports both explicit modifiers and implicit modifiers. 147 148 For the definition of the format and modifier codes, see the 149 zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add 150 requests. 151 152 Starting version 4, the modifier event is deprecated and must not be 153 sent by compositors. Instead, use get_default_feedback or 154 get_surface_feedback. 155 </description> 156 <arg name="format" type="uint" summary="DRM_FORMAT code"/> 157 <arg name="modifier_hi" type="uint" 158 summary="high 32 bits of layout modifier"/> 159 <arg name="modifier_lo" type="uint" 160 summary="low 32 bits of layout modifier"/> 161 </event> 162 163 <!-- Version 4 additions --> 164 165 <request name="get_default_feedback" since="4"> 166 <description summary="get default feedback"> 167 This request creates a new wp_linux_dmabuf_feedback object not bound 168 to a particular surface. This object will deliver feedback about dmabuf 169 parameters to use if the client doesn't support per-surface feedback 170 (see get_surface_feedback). 171 </description> 172 <arg name="id" type="new_id" interface="zwp_linux_dmabuf_feedback_v1"/> 173 </request> 174 175 <request name="get_surface_feedback" since="4"> 176 <description summary="get feedback for a surface"> 177 This request creates a new wp_linux_dmabuf_feedback object for the 178 specified wl_surface. This object will deliver feedback about dmabuf 179 parameters to use for buffers attached to this surface. 180 181 If the surface is destroyed before the wp_linux_dmabuf_feedback object, 182 the feedback object becomes inert. 183 </description> 184 <arg name="id" type="new_id" interface="zwp_linux_dmabuf_feedback_v1"/> 185 <arg name="surface" type="object" interface="wl_surface"/> 186 </request> 187 </interface> 188 189 <interface name="zwp_linux_buffer_params_v1" version="5"> 190 <description summary="parameters for creating a dmabuf-based wl_buffer"> 191 This temporary object is a collection of dmabufs and other 192 parameters that together form a single logical buffer. The temporary 193 object may eventually create one wl_buffer unless cancelled by 194 destroying it before requesting 'create'. 195 196 Single-planar formats only require one dmabuf, however 197 multi-planar formats may require more than one dmabuf. For all 198 formats, an 'add' request must be called once per plane (even if the 199 underlying dmabuf fd is identical). 200 201 You must use consecutive plane indices ('plane_idx' argument for 'add') 202 from zero to the number of planes used by the drm_fourcc format code. 203 All planes required by the format must be given exactly once, but can 204 be given in any order. Each plane index can be set only once. 205 </description> 206 207 <enum name="error"> 208 <entry name="already_used" value="0" 209 summary="the dmabuf_batch object has already been used to create a wl_buffer"/> 210 <entry name="plane_idx" value="1" 211 summary="plane index out of bounds"/> 212 <entry name="plane_set" value="2" 213 summary="the plane index was already set"/> 214 <entry name="incomplete" value="3" 215 summary="missing or too many planes to create a buffer"/> 216 <entry name="invalid_format" value="4" 217 summary="format not supported"/> 218 <entry name="invalid_dimensions" value="5" 219 summary="invalid width or height"/> 220 <entry name="out_of_bounds" value="6" 221 summary="offset + stride * height goes out of dmabuf bounds"/> 222 <entry name="invalid_wl_buffer" value="7" 223 summary="invalid wl_buffer resulted from importing dmabufs via 224 the create_immed request on given buffer_params"/> 225 </enum> 226 227 <request name="destroy" type="destructor"> 228 <description summary="delete this object, used or not"> 229 Cleans up the temporary data sent to the server for dmabuf-based 230 wl_buffer creation. 231 </description> 232 </request> 233 234 <request name="add"> 235 <description summary="add a dmabuf to the temporary set"> 236 This request adds one dmabuf to the set in this 237 zwp_linux_buffer_params_v1. 238 239 The 64-bit unsigned value combined from modifier_hi and modifier_lo 240 is the dmabuf layout modifier. DRM AddFB2 ioctl calls this the 241 fb modifier, which is defined in drm_mode.h of Linux UAPI. 242 This is an opaque token. Drivers use this token to express tiling, 243 compression, etc. driver-specific modifications to the base format 244 defined by the DRM fourcc code. 245 246 Starting from version 4, the invalid_format protocol error is sent if 247 the format + modifier pair was not advertised as supported. 248 249 Starting from version 5, the invalid_format protocol error is sent if 250 all planes don't use the same modifier. 251 252 This request raises the PLANE_IDX error if plane_idx is too large. 253 The error PLANE_SET is raised if attempting to set a plane that 254 was already set. 255 </description> 256 <arg name="fd" type="fd" summary="dmabuf fd"/> 257 <arg name="plane_idx" type="uint" summary="plane index"/> 258 <arg name="offset" type="uint" summary="offset in bytes"/> 259 <arg name="stride" type="uint" summary="stride in bytes"/> 260 <arg name="modifier_hi" type="uint" 261 summary="high 32 bits of layout modifier"/> 262 <arg name="modifier_lo" type="uint" 263 summary="low 32 bits of layout modifier"/> 264 </request> 265 266 <enum name="flags" bitfield="true"> 267 <entry name="y_invert" value="1" summary="contents are y-inverted"/> 268 <entry name="interlaced" value="2" summary="content is interlaced"/> 269 <entry name="bottom_first" value="4" summary="bottom field first"/> 270 </enum> 271 272 <request name="create"> 273 <description summary="create a wl_buffer from the given dmabufs"> 274 This asks for creation of a wl_buffer from the added dmabuf 275 buffers. The wl_buffer is not created immediately but returned via 276 the 'created' event if the dmabuf sharing succeeds. The sharing 277 may fail at runtime for reasons a client cannot predict, in 278 which case the 'failed' event is triggered. 279 280 The 'format' argument is a DRM_FORMAT code, as defined by the 281 libdrm's drm_fourcc.h. The Linux kernel's DRM sub-system is the 282 authoritative source on how the format codes should work. 283 284 The 'flags' is a bitfield of the flags defined in enum "flags". 285 'y_invert' means the that the image needs to be y-flipped. 286 287 Flag 'interlaced' means that the frame in the buffer is not 288 progressive as usual, but interlaced. An interlaced buffer as 289 supported here must always contain both top and bottom fields. 290 The top field always begins on the first pixel row. The temporal 291 ordering between the two fields is top field first, unless 292 'bottom_first' is specified. It is undefined whether 'bottom_first' 293 is ignored if 'interlaced' is not set. 294 295 This protocol does not convey any information about field rate, 296 duration, or timing, other than the relative ordering between the 297 two fields in one buffer. A compositor may have to estimate the 298 intended field rate from the incoming buffer rate. It is undefined 299 whether the time of receiving wl_surface.commit with a new buffer 300 attached, applying the wl_surface state, wl_surface.frame callback 301 trigger, presentation, or any other point in the compositor cycle 302 is used to measure the frame or field times. There is no support 303 for detecting missed or late frames/fields/buffers either, and 304 there is no support whatsoever for cooperating with interlaced 305 compositor output. 306 307 The composited image quality resulting from the use of interlaced 308 buffers is explicitly undefined. A compositor may use elaborate 309 hardware features or software to deinterlace and create progressive 310 output frames from a sequence of interlaced input buffers, or it 311 may produce substandard image quality. However, compositors that 312 cannot guarantee reasonable image quality in all cases are recommended 313 to just reject all interlaced buffers. 314 315 Any argument errors, including non-positive width or height, 316 mismatch between the number of planes and the format, bad 317 format, bad offset or stride, may be indicated by fatal protocol 318 errors: INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS, 319 OUT_OF_BOUNDS. 320 321 Dmabuf import errors in the server that are not obvious client 322 bugs are returned via the 'failed' event as non-fatal. This 323 allows attempting dmabuf sharing and falling back in the client 324 if it fails. 325 326 This request can be sent only once in the object's lifetime, after 327 which the only legal request is destroy. This object should be 328 destroyed after issuing a 'create' request. Attempting to use this 329 object after issuing 'create' raises ALREADY_USED protocol error. 330 331 It is not mandatory to issue 'create'. If a client wants to 332 cancel the buffer creation, it can just destroy this object. 333 </description> 334 <arg name="width" type="int" summary="base plane width in pixels"/> 335 <arg name="height" type="int" summary="base plane height in pixels"/> 336 <arg name="format" type="uint" summary="DRM_FORMAT code"/> 337 <arg name="flags" type="uint" enum="flags" summary="see enum flags"/> 338 </request> 339 340 <event name="created"> 341 <description summary="buffer creation succeeded"> 342 This event indicates that the attempted buffer creation was 343 successful. It provides the new wl_buffer referencing the dmabuf(s). 344 345 Upon receiving this event, the client should destroy the 346 zwp_linux_buffer_params_v1 object. 347 </description> 348 <arg name="buffer" type="new_id" interface="wl_buffer" 349 summary="the newly created wl_buffer"/> 350 </event> 351 352 <event name="failed"> 353 <description summary="buffer creation failed"> 354 This event indicates that the attempted buffer creation has 355 failed. It usually means that one of the dmabuf constraints 356 has not been fulfilled. 357 358 Upon receiving this event, the client should destroy the 359 zwp_linux_buffer_params_v1 object. 360 </description> 361 </event> 362 363 <request name="create_immed" since="2"> 364 <description summary="immediately create a wl_buffer from the given 365 dmabufs"> 366 This asks for immediate creation of a wl_buffer by importing the 367 added dmabufs. 368 369 In case of import success, no event is sent from the server, and the 370 wl_buffer is ready to be used by the client. 371 372 Upon import failure, either of the following may happen, as seen fit 373 by the implementation: 374 - the client is terminated with one of the following fatal protocol 375 errors: 376 - INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS, OUT_OF_BOUNDS, 377 in case of argument errors such as mismatch between the number 378 of planes and the format, bad format, non-positive width or 379 height, or bad offset or stride. 380 - INVALID_WL_BUFFER, in case the cause for failure is unknown or 381 plaform specific. 382 - the server creates an invalid wl_buffer, marks it as failed and 383 sends a 'failed' event to the client. The result of using this 384 invalid wl_buffer as an argument in any request by the client is 385 defined by the compositor implementation. 386 387 This takes the same arguments as a 'create' request, and obeys the 388 same restrictions. 389 </description> 390 <arg name="buffer_id" type="new_id" interface="wl_buffer" 391 summary="id for the newly created wl_buffer"/> 392 <arg name="width" type="int" summary="base plane width in pixels"/> 393 <arg name="height" type="int" summary="base plane height in pixels"/> 394 <arg name="format" type="uint" summary="DRM_FORMAT code"/> 395 <arg name="flags" type="uint" enum="flags" summary="see enum flags"/> 396 </request> 397 </interface> 398 399 <interface name="zwp_linux_dmabuf_feedback_v1" version="5"> 400 <description summary="dmabuf feedback"> 401 This object advertises dmabuf parameters feedback. This includes the 402 preferred devices and the supported formats/modifiers. 403 404 The parameters are sent once when this object is created and whenever they 405 change. The done event is always sent once after all parameters have been 406 sent. When a single parameter changes, all parameters are re-sent by the 407 compositor. 408 409 Compositors can re-send the parameters when the current client buffer 410 allocations are sub-optimal. Compositors should not re-send the 411 parameters if re-allocating the buffers would not result in a more optimal 412 configuration. In particular, compositors should avoid sending the exact 413 same parameters multiple times in a row. 414 415 The tranche_target_device and tranche_formats events are grouped by 416 tranches of preference. For each tranche, a tranche_target_device, one 417 tranche_flags and one or more tranche_formats events are sent, followed 418 by a tranche_done event finishing the list. The tranches are sent in 419 descending order of preference. All formats and modifiers in the same 420 tranche have the same preference. 421 422 To send parameters, the compositor sends one main_device event, tranches 423 (each consisting of one tranche_target_device event, one tranche_flags 424 event, tranche_formats events and then a tranche_done event), then one 425 done event. 426 </description> 427 428 <request name="destroy" type="destructor"> 429 <description summary="destroy the feedback object"> 430 Using this request a client can tell the server that it is not going to 431 use the wp_linux_dmabuf_feedback object anymore. 432 </description> 433 </request> 434 435 <event name="done"> 436 <description summary="all feedback has been sent"> 437 This event is sent after all parameters of a wp_linux_dmabuf_feedback 438 object have been sent. 439 440 This allows changes to the wp_linux_dmabuf_feedback parameters to be 441 seen as atomic, even if they happen via multiple events. 442 </description> 443 </event> 444 445 <event name="format_table"> 446 <description summary="format and modifier table"> 447 This event provides a file descriptor which can be memory-mapped to 448 access the format and modifier table. 449 450 The table contains a tightly packed array of consecutive format + 451 modifier pairs. Each pair is 16 bytes wide. It contains a format as a 452 32-bit unsigned integer, followed by 4 bytes of unused padding, and a 453 modifier as a 64-bit unsigned integer. The native endianness is used. 454 455 The client must map the file descriptor in read-only private mode. 456 457 Compositors are not allowed to mutate the table file contents once this 458 event has been sent. Instead, compositors must create a new, separate 459 table file and re-send feedback parameters. Compositors are allowed to 460 store duplicate format + modifier pairs in the table. 461 </description> 462 <arg name="fd" type="fd" summary="table file descriptor"/> 463 <arg name="size" type="uint" summary="table size, in bytes"/> 464 </event> 465 466 <event name="main_device"> 467 <description summary="preferred main device"> 468 This event advertises the main device that the server prefers to use 469 when direct scan-out to the target device isn't possible. The 470 advertised main device may be different for each 471 wp_linux_dmabuf_feedback object, and may change over time. 472 473 There is exactly one main device. The compositor must send at least 474 one preference tranche with tranche_target_device equal to main_device. 475 476 Clients need to create buffers that the main device can import and 477 read from, otherwise creating the dmabuf wl_buffer will fail (see the 478 wp_linux_buffer_params.create and create_immed requests for details). 479 The main device will also likely be kept active by the compositor, 480 so clients can use it instead of waking up another device for power 481 savings. 482 483 In general the device is a DRM node. The DRM node type (primary vs. 484 render) is unspecified. Clients must not rely on the compositor sending 485 a particular node type. Clients cannot check two devices for equality 486 by comparing the dev_t value. 487 488 If explicit modifiers are not supported and the client performs buffer 489 allocations on a different device than the main device, then the client 490 must force the buffer to have a linear layout. 491 </description> 492 <arg name="device" type="array" summary="device dev_t value"/> 493 </event> 494 495 <event name="tranche_done"> 496 <description summary="a preference tranche has been sent"> 497 This event splits tranche_target_device and tranche_formats events in 498 preference tranches. It is sent after a set of tranche_target_device 499 and tranche_formats events; it represents the end of a tranche. The 500 next tranche will have a lower preference. 501 </description> 502 </event> 503 504 <event name="tranche_target_device"> 505 <description summary="target device"> 506 This event advertises the target device that the server prefers to use 507 for a buffer created given this tranche. The advertised target device 508 may be different for each preference tranche, and may change over time. 509 510 There is exactly one target device per tranche. 511 512 The target device may be a scan-out device, for example if the 513 compositor prefers to directly scan-out a buffer created given this 514 tranche. The target device may be a rendering device, for example if 515 the compositor prefers to texture from said buffer. 516 517 The client can use this hint to allocate the buffer in a way that makes 518 it accessible from the target device, ideally directly. The buffer must 519 still be accessible from the main device, either through direct import 520 or through a potentially more expensive fallback path. If the buffer 521 can't be directly imported from the main device then clients must be 522 prepared for the compositor changing the tranche priority or making 523 wl_buffer creation fail (see the wp_linux_buffer_params.create and 524 create_immed requests for details). 525 526 If the device is a DRM node, the DRM node type (primary vs. render) is 527 unspecified. Clients must not rely on the compositor sending a 528 particular node type. Clients cannot check two devices for equality by 529 comparing the dev_t value. 530 531 This event is tied to a preference tranche, see the tranche_done event. 532 </description> 533 <arg name="device" type="array" summary="device dev_t value"/> 534 </event> 535 536 <event name="tranche_formats"> 537 <description summary="supported buffer format modifier"> 538 This event advertises the format + modifier combinations that the 539 compositor supports. 540 541 It carries an array of indices, each referring to a format + modifier 542 pair in the last received format table (see the format_table event). 543 Each index is a 16-bit unsigned integer in native endianness. 544 545 For legacy support, DRM_FORMAT_MOD_INVALID is an allowed modifier. 546 It indicates that the server can support the format with an implicit 547 modifier. When a buffer has DRM_FORMAT_MOD_INVALID as its modifier, it 548 is as if no explicit modifier is specified. The effective modifier 549 will be derived from the dmabuf. 550 551 A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for 552 a given format supports both explicit modifiers and implicit modifiers. 553 554 Compositors must not send duplicate format + modifier pairs within the 555 same tranche or across two different tranches with the same target 556 device and flags. 557 558 This event is tied to a preference tranche, see the tranche_done event. 559 560 For the definition of the format and modifier codes, see the 561 wp_linux_buffer_params.create request. 562 </description> 563 <arg name="indices" type="array" summary="array of 16-bit indexes"/> 564 </event> 565 566 <enum name="tranche_flags" bitfield="true"> 567 <entry name="scanout" value="1" summary="direct scan-out tranche"/> 568 </enum> 569 570 <event name="tranche_flags"> 571 <description summary="tranche flags"> 572 This event sets tranche-specific flags. 573 574 The scanout flag is a hint that direct scan-out may be attempted by the 575 compositor on the target device if the client appropriately allocates a 576 buffer. How to allocate a buffer that can be scanned out on the target 577 device is implementation-defined. 578 579 This event is tied to a preference tranche, see the tranche_done event. 580 </description> 581 <arg name="flags" type="uint" enum="tranche_flags" summary="tranche flags"/> 582 </event> 583 </interface> 584 585</protocol> 586