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