From 401f295de2c0747b2e0b2a9488e02e28db3538d4 Mon Sep 17 00:00:00 2001 From: "duna.oh" Date: Tue, 22 Aug 2023 17:15:03 +0900 Subject: [PATCH 01/16] tizen_input_device_manager: add requests of keyboard_grab/ungrab Change-Id: I260e2f0dcf5109dbaf2886c78b35af767faa4320 --- protocol/tizen/tizen-extension.xml | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/protocol/tizen/tizen-extension.xml b/protocol/tizen/tizen-extension.xml index 417cd60..f4ace49 100644 --- a/protocol/tizen/tizen-extension.xml +++ b/protocol/tizen/tizen-extension.xml @@ -1646,7 +1646,7 @@ - + Tizen input device manager is a global interface. This object has device add/remove events to provide tizen input device object to a client. This allows for a client to get the con @@ -1863,6 +1863,28 @@ + + + + + + + + + + + + + + + + + + + + + + -- 2.7.4 From f98247ed2f6f7f4e0b14c368c4d4dd4da3f4075f Mon Sep 17 00:00:00 2001 From: "duna.oh" Date: Tue, 22 Aug 2023 17:17:39 +0900 Subject: [PATCH 02/16] Package version up to 1.3.45 Change-Id: I404bf02a84681e7f42406694b92362c6a6b7e363 --- packaging/wayland-extension.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packaging/wayland-extension.spec b/packaging/wayland-extension.spec index 3ee215d..c110553 100644 --- a/packaging/wayland-extension.spec +++ b/packaging/wayland-extension.spec @@ -2,7 +2,7 @@ %define enable_examples 0 Name: wayland-extension -Version: 1.3.44 +Version: 1.3.45 Release: 0 Summary: Wayland extenstion protocols that add functionality not available in the Wayland core protocol License: MIT -- 2.7.4 From 0c15840eadc633e8b8bc54648f2a1a0e0593cc55 Mon Sep 17 00:00:00 2001 From: Inhong Han Date: Thu, 25 Jan 2024 15:52:32 +0900 Subject: [PATCH 03/16] text: Allow setting the seat to null for AoT Change-Id: Ie467afa9211a32e871d1cf797f4aba9261160639 --- protocol/tizen/text.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/tizen/text.xml b/protocol/tizen/text.xml index 2e8780e..0c4f1f6 100644 --- a/protocol/tizen/text.xml +++ b/protocol/tizen/text.xml @@ -59,7 +59,7 @@ text_input object and tracked for focus lost. The enter event is emitted on successful activation. - + -- 2.7.4 From 5a912c02067b6ccf02a2843da451819ce1f27748 Mon Sep 17 00:00:00 2001 From: Inhong Han Date: Thu, 25 Jan 2024 16:37:22 +0900 Subject: [PATCH 04/16] Package version up to 1.3.46 Change-Id: Ibe2ce0649619f2b207fc9e85cad96c494a2eb48e --- packaging/wayland-extension.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packaging/wayland-extension.spec b/packaging/wayland-extension.spec index c110553..0b2a159 100644 --- a/packaging/wayland-extension.spec +++ b/packaging/wayland-extension.spec @@ -2,7 +2,7 @@ %define enable_examples 0 Name: wayland-extension -Version: 1.3.45 +Version: 1.3.46 Release: 0 Summary: Wayland extenstion protocols that add functionality not available in the Wayland core protocol License: MIT -- 2.7.4 From b1b787915798966070dc30218321b0952790d373 Mon Sep 17 00:00:00 2001 From: Changyeon Lee Date: Thu, 9 Nov 2023 15:11:11 +0900 Subject: [PATCH 05/16] add wtz-blur tizen protocol This protocol allows clients to have more control over blurring background of surface. Change-Id: I1a2b8f6f4794b51a6a03489c8628ca8f3130f4ff --- Makefile.am | 18 +++++++ protocol/tizen/wtz-blur.xml | 115 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 133 insertions(+) create mode 100644 protocol/tizen/wtz-blur.xml diff --git a/Makefile.am b/Makefile.am index b6d6c9b..1ed2be0 100644 --- a/Makefile.am +++ b/Makefile.am @@ -425,6 +425,23 @@ libwtz_blender_client_la_SOURCES = protocol/tizen/wtz-blender-protocol.c libwtz_blender_client_la_CFLAGS = @WAYLAND_CLIENT_CFLAGS@ libwtz_blender_client_la_LIBADD = @WAYLAND_CLIENT_LIBS@ +### wtz_blur +protocol_LTLIBRARIES += \ + libwtz-blur-server.la \ + libwtz-blur-client.la +pkgconfig_DATA += \ + src/wtz-blur-server.pc \ + src/wtz-blur-client.pc +protocolinclude_HEADERS += \ + protocol/tizen/wtz-blur-server-protocol.h \ + protocol/tizen/wtz-blur-client-protocol.h +libwtz_blur_server_la_SOURCES = protocol/tizen/wtz-blur-protocol.c +libwtz_blur_server_la_CFLAGS = @WAYLAND_SERVER_CFLAGS@ +libwtz_blur_server_la_LIBADD = @WAYLAND_SERVER_LIBS@ +libwtz_blur_client_la_SOURCES = protocol/tizen/wtz-blur-protocol.c +libwtz_blur_client_la_CFLAGS = @WAYLAND_CLIENT_CFLAGS@ +libwtz_blur_client_la_LIBADD = @WAYLAND_CLIENT_LIBS@ + ### wtz_foreign protocol_LTLIBRARIES += \ libwtz-foreign-server.la \ @@ -548,6 +565,7 @@ tizen_protocols = \ protocol/tizen/wtz-screen.xml \ protocol/tizen/wtz-shell.xml \ protocol/tizen/wtz-blender.xml \ + protocol/tizen/wtz-blur.xml \ $(NULL) nobase_dist_pkgdata_DATA = \ diff --git a/protocol/tizen/wtz-blur.xml b/protocol/tizen/wtz-blur.xml new file mode 100644 index 0000000..f8f7580 --- /dev/null +++ b/protocol/tizen/wtz-blur.xml @@ -0,0 +1,115 @@ + + + + + Copyright © 2023 Samsung Electronics Co., Ltd. + + Permission is hereby granted, free of charge, to any person obtaining a + copy of this software and associated documentation files (the "Software"), + to deal in the Software without restriction, including without limitation + the rights to use, copy, modify, merge, publish, distribute, sublicense, + and/or sell copies of the Software, and to permit persons to whom the + Software is furnished to do so, subject to the following conditions: + + The above copyright notice and this permission notice (including the next + paragraph) shall be included in all copies or substantial portions of the + Software. + + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + DEALINGS IN THE SOFTWARE. + + + + This protocol allows clients to have more control over blurring background + of surface. + + + + + A global allows clients to create wtz_blur_manager objects. + + + + + + + + + Destroy the blur object. + + + + + + Create a blur object for a surface. + + If the wl_surface already has a blur object associated, the + blur_exists protocol error is raised. + + + + + + + + + A surface extension interface for setting a blurring background + to the surface. + + Use of this interface has no effect on the surface's opaque region + as set by wl_surface.set_opaque_region. + + If the wl_surface associated with the wtz_blur is destroyed, + the wtz_blur object becomes inert. + + + + + Destroy the blur object. + + On the next wl_surface.commit, the blur object state is withdrawn. + + + + + + Set the blur region applied to the surface for compositing. + + The blur region is specified in the surface-local coordinates. + + The blur region is double-buffered state, and will be applied on the + next wl_surface.commit. + + The initial value for an blur region is infinite. That means the + whole surface background will be blurred. Setting the pending blur region + has copy semantics, and the wl_region object can be destroyed + immediately. A NULL wl_region causes the blur region to be set + to infinite. + + + + + + + Set the blur radius for compositing the surface. + + The blur radius is double-buffered state, and will be applied on + the next wl_surface.commit. + + The initial value for an blur radius is zero. That means a blurring + background will be disabled. + + + + + + -- 2.7.4 From 70b3587a22df59d1eaab595e374d7a507bd09918 Mon Sep 17 00:00:00 2001 From: Changyeon Lee Date: Mon, 29 Jan 2024 14:28:25 +0900 Subject: [PATCH 06/16] Package version up to 1.3.47 Change-Id: I663ed54cf0226cfa8e6853178e2a5caad8b86ee9 --- packaging/wayland-extension.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packaging/wayland-extension.spec b/packaging/wayland-extension.spec index 0b2a159..7fc2224 100644 --- a/packaging/wayland-extension.spec +++ b/packaging/wayland-extension.spec @@ -2,7 +2,7 @@ %define enable_examples 0 Name: wayland-extension -Version: 1.3.46 +Version: 1.3.47 Release: 0 Summary: Wayland extenstion protocols that add functionality not available in the Wayland core protocol License: MIT -- 2.7.4 From 0b1153fb8250dbdc6971967a7a3fe28f961afd8e Mon Sep 17 00:00:00 2001 From: Changyeon Lee Date: Wed, 21 Feb 2024 10:51:27 +0900 Subject: [PATCH 07/16] linux-dmabuf: update the linux-dmabuf-v1 protocol to a stable version Change-Id: Ib4f2f30a854137bb61ea61103595698ae61a5087 --- Makefile.am | 19 +- protocol/{unstable => stable}/linux-dmabuf/README | 0 protocol/stable/linux-dmabuf/feedback.rst | 218 ++++++++++++++++ .../linux-dmabuf/linux-dmabuf-v1.xml} | 279 ++++++++++++++++++--- 4 files changed, 487 insertions(+), 29 deletions(-) rename protocol/{unstable => stable}/linux-dmabuf/README (100%) create mode 100644 protocol/stable/linux-dmabuf/feedback.rst rename protocol/{unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml => stable/linux-dmabuf/linux-dmabuf-v1.xml} (56%) diff --git a/Makefile.am b/Makefile.am index 1ed2be0..3fc4044 100644 --- a/Makefile.am +++ b/Makefile.am @@ -510,11 +510,27 @@ libsingle_pixel_buffer_v1_client_la_SOURCES = protocol/staging/single-pixel-buff libsingle_pixel_buffer_v1_client_la_CFLAGS = @WAYLAND_CLIENT_CFLAGS@ libsingle_pixel_buffer_v1_client_la_LIBADD = @WAYLAND_CLIENT_LIBS@ +### linux-dmabuf-v1 +protocol_LTLIBRARIES += \ + liblinux-dmabuf-v1-server.la \ + liblinux-dmabuf-v1-client.la +pkgconfig_DATA += \ + src/liblinux-dmabuf-v1-server.pc \ + src/liblinux-dmabuf-v1-client.pc +protocolinclude_HEADERS += \ + protocol/stable/linux-dmabuf-v1-server-protocol.h \ + protocol/stable/linux-dmabuf-v1-client-protocol.h +liblinux_dmabuf_v1_server_la_SOURCES = protocol/stable/linux-dmabuf-v1-protocol.c +liblinux_dmabuf_v1_server_la_CFLAGS = @WAYLAND_SERVER_CFLAGS@ +liblinux_dmabuf_v1_server_la_LIBADD = @WAYLAND_SERVER_LIBS@ +liblinux_dmabuf_v1_client_la_SOURCES = protocol/stable/linux-dmabuf-v1-protocol.c +liblinux_dmabuf_v1_client_la_CFLAGS = @WAYLAND_CLIENT_CFLAGS@ +liblinux_dmabuf_v1_client_la_LIBADD = @WAYLAND_CLIENT_LIBS@ + ### wayland-protocols unstable_protocols = \ protocol/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml \ protocol/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml \ - protocol/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml \ protocol/unstable/text-input/text-input-unstable-v1.xml \ protocol/unstable/text-input/text-input-unstable-v3.xml \ protocol/unstable/input-method/input-method-unstable-v1.xml \ @@ -544,6 +560,7 @@ stable_protocols = \ protocol/stable/presentation-time/presentation-time.xml \ protocol/stable/viewporter/viewporter.xml \ protocol/stable/xdg-shell/xdg-shell.xml \ + protocol/stable/linux-dmabuf/linux-dmabuf-v1.xml \ $(NULL) tizen_protocols = \ diff --git a/protocol/unstable/linux-dmabuf/README b/protocol/stable/linux-dmabuf/README similarity index 100% rename from protocol/unstable/linux-dmabuf/README rename to protocol/stable/linux-dmabuf/README diff --git a/protocol/stable/linux-dmabuf/feedback.rst b/protocol/stable/linux-dmabuf/feedback.rst new file mode 100644 index 0000000..a3f94ed --- /dev/null +++ b/protocol/stable/linux-dmabuf/feedback.rst @@ -0,0 +1,218 @@ +.. Copyright 2021 Simon Ser + +.. contents:: + + +linux-dmabuf feedback introduction +================================== + +linux-dmabuf feedback allows compositors and clients to negotiate optimal buffer +allocation parameters. This document will assume that the compositor is using a +rendering API such as OpenGL or Vulkan and KMS as the presentation API: even if +linux-dmabuf feedback isn't restricted to this use-case, it's the most common. + +linux-dmabuf feedback introduces the following concepts: + +1. A main device. This is the render device that the compositor is using to + perform composition. Compositors should always be able to display a buffer + submitted by a client, so this device can be used as a fallback in case none + of the more optimized code-paths work. Clients should allocate buffers such + that they can be imported and textured from the main device. + +2. One or more tranches. Each tranche consists of a target device, allocation + flags and a set of format/modifier pairs. A tranche can be seen as a set of + formats/modifier pairs that are compatible with the target device. + + A tranche can have the ``scanout`` flag. It means that the target device is + a KMS device, and that buffers allocated with one of the format/modifier + pairs in the tranche are eligible for direct scanout. + + Clients should use the tranches in order to allocate buffers with the most + appropriate format/modifier and also to avoid allocating in private device + memory when cross-device operations are going to happen. + +linux-dmabuf feedback implementation notes +========================================== + +This section contains recommendations for client and compositor implementations. + +For clients +----------- + +Clients are expected to either pick a fixed DRM format beforehand, or +perform the following steps repeatedly until they find a suitable format. + +Basic clients may only support static buffer allocation on startup. These +clients should do the following: + +1. Send a ``get_default_feedback`` request to get global feedback. +2. Select the device indicated by ``main_device`` for allocation. +3. For each tranche: + + 1. If ``tranche_target_device`` doesn't match the allocation device, ignore + the tranche. + 2. Accumulate allocation flags from ``tranche_flags``. + 3. Accumulate format/modifier pairs received via ``tranche_formats`` in a + list. + 4. When the ``tranche_done`` event is received, try to allocate the buffer + with the accumulated list of modifiers and allocation flags. If that + fails, proceed with the next tranche. If that succeeds, stop the loop. + +4. Destroy the feedback object. + +Tranches are ordered by preference: the more optimized tranches come first. As +such, clients should use the first tranche that happens to work. + +Some clients may have already selected the device they want to use beforehand. +These clients can ignore the ``main_device`` event, and ignore tranches whose +``tranche_target_device`` doesn't match the selected device. Such clients need +to be prepared for the ``wp_linux_buffer_params.create`` request to potentially +fail. + +If the client allocates a buffer without specifying explicit modifiers on a +device different from the one indicated by ``main_device``, then the client +must force a linear layout. + +Some clients might support re-negotiating the buffer format/modifier on the +fly. These clients should send a ``get_surface_feedback`` request and keep the +feedback object alive after the initial allocation. Each time a new set of +feedback parameters is received (ended by the ``done`` event), they should +perform the same steps as basic clients described above. They should detect +when the optimal allocation parameters didn't change (same +format/modifier/flags) to avoid needlessly re-allocating their buffers. + +Some clients might additionally support switching the device used for +allocations on the fly. Such clients should send a ``get_surface_feedback`` +request. For each tranche, select the device indicated by +``tranche_target_device`` for allocation. Accumulate allocation flags (received +via ``tranche_flags``) and format/modifier pairs (received via +``tranche_formats``) as usual. When the ``tranche_done`` event is received, try +to allocate the buffer with the accumulated list of modifiers and the +allocation flags. Try to import the resulting buffer by sending a +``wp_linux_buffer_params.create`` request (this might fail). Repeat with each +tranche until an allocation and import succeeds. Each time a new set of +feedback parameters is received, they should perform these steps again. They +should detect when the optimal allocation parameters didn't change (same +device/format/modifier/flags) to avoid needlessly re-allocating their buffers. + +For compositors +--------------- + +Basic compositors may only support texturing the DMA-BUFs via a rendering API +such as OpenGL or Vulkan. Such compositors can send a single tranche as a reply +to both ``get_default_feedback`` and ``get_surface_feedback``. Set the +``main_device`` to the rendering device. Send the tranche with +``tranche_target_device`` set to the rendering device and all of the DRM +format/modifier pairs supported by the rendering API. Do not set the +``scanout`` flag in the ``tranche_flags`` event. + +Some compositors may support direct scan-out for full-screen surfaces. These +compositors can re-send the feedback parameters when a surface becomes +full-screen or leaves full-screen mode if the client has used the +``get_surface_feedback`` request. The non-full-screen feedback parameters are +the same as basic compositors described above. The full-screen feedback +parameters have two tranches: one with the format/modifier pairs supported by +the KMS plane, with the ``scanout`` flag set in the ``tranche_flags`` event and +with ``tranche_target_device`` set to the KMS scan-out device; the other with +the rest of the format/modifier pairs (supported for texturing, but not for +scan-out), without the ``scanout`` flag set in the ``tranche_flags`` event, and +with the ``tranche_target_device`` set to the rendering device. + +Some compositors may support direct scan-out for all surfaces. These +compositors can send two tranches for surfaces that become candidates for +direct scan-out, similarly to compositors supporting direct scan-out for +fullscreen surfaces. When a surface stops being a candidate for direct +scan-out, compositors should re-send the feedback parameters optimized for +texturing only. The way candidates for direct scan-out are selected is +compositor policy, a possible implementation is to select as many surfaces as +there are available hardware planes, starting from surfaces closer to the eye. + +Some compositors may support multiple devices at the same time. If the +compositor supports rendering with a fixed device and direct scan-out on a +secondary device, it may send a separate tranche for surfaces displayed on +the secondary device that are candidates for direct scan-out. The +``tranche_target_device`` for this tranche will be the secondary device and +will not match the ``main_device``. + +Some compositors may support switching their rendering device at runtime or +changing their rendering device depending on the surface. When the rendering +device changes for a surface, such compositors may re-send the feedback +parameters with a different ``main_device``. However there is a risk that +clients don't support switching their device at runtime and continue using the +previous device. For this reason, compositors should always have a fallback +rendering device that they initially send as ``main_device``, such that these +clients use said fallback device. + +Compositors should not change the ``main_device`` on-the-fly when explicit +modifiers are not supported, because there's a risk of importing buffers +with an implicit non-linear modifier as a linear buffer, resulting in +misinterpreted buffer contents. + +Compositors should not send feedback parameters if they don't have a fallback +path. For instance, compositors shouldn't send a format/modifier supported for +direct scan-out but not supported by the rendering API for texturing. + +Compositors can decide to use multiple tranches to describe the allocation +parameters optimized for texturing. For example, if there are formats which +have a fast texturing path and formats which have a slower texturing path, the +compositor can decide to expose two separate tranches. + +Compositors can decide to use intermediate tranches to describe code-paths +slower than direct scan-out but faster than texturing. For instance, a +compositor could insert an intermediate tranche if it's possible to use a +mem2mem device to convert buffers to be able to use scan-out. + +``dev_t`` encoding +================== + +The protocol carries ``dev_t`` values on the wire using arrays. A compositor +written in C can encode the values as follows: + +.. code-block:: c + + struct stat drm_node_stat; + struct wl_array dev_array = { + .size = sizeof(drm_node_stat.st_rdev), + .data = &drm_node_stat.st_rdev, + }; + +A client can decode the values as follows: + +.. code-block:: c + + dev_t dev; + assert(dev_array->size == sizeof(dev)); + memcpy(&dev, dev_array->data, sizeof(dev)); + +Because two DRM nodes can refer to the same DRM device while having different +``dev_t`` values, clients should use ``drmDevicesEqual`` to compare two +devices. + +``format_table`` encoding +========================= + +The ``format_table`` event carries a file descriptor containing a list of +format + modifier pairs. The list is an array of pairs which can be accessed +with this C structure definition: + +.. code-block:: c + + struct dmabuf_format_modifier { + uint32_t format; + uint32_t pad; /* unused */ + uint64_t modifier; + }; + +Integration with other APIs +=========================== + +- libdrm: ``drmGetDeviceFromDevId`` returns a ``drmDevice`` from a device ID. +- EGL: the `EGL_EXT_device_drm_render_node`_ extension may be used to query the + DRM device render node used by a given EGL display. When unavailable, the + older `EGL_EXT_device_drm`_ extension may be used as a fallback. +- Vulkan: the `VK_EXT_physical_device_drm`_ extension may be used to query the + DRM device used by a given ``VkPhysicalDevice``. + +.. _EGL_EXT_device_drm: https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_device_drm.txt +.. _EGL_EXT_device_drm_render_node: https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_device_drm_render_node.txt +.. _VK_EXT_physical_device_drm: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_physical_device_drm.html diff --git a/protocol/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml b/protocol/stable/linux-dmabuf/linux-dmabuf-v1.xml similarity index 56% rename from protocol/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml rename to protocol/stable/linux-dmabuf/linux-dmabuf-v1.xml index b43e81c..38e06f5 100644 --- a/protocol/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml +++ b/protocol/stable/linux-dmabuf/linux-dmabuf-v1.xml @@ -1,5 +1,5 @@ - + Copyright © 2014, 2015 Collabora, Ltd. @@ -24,17 +24,18 @@ DEALINGS IN THE SOFTWARE. - + Following the interfaces from: https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt and the Linux DRM sub-system's AddFb2 ioctl. - This interface offers ways to create generic dmabuf-based - wl_buffers. Immediately after a client binds to this interface, - the set of supported formats and format modifiers is sent with - 'format' and 'modifier' events. + This interface offers ways to create generic dmabuf-based wl_buffers. + + Clients can use the get_surface_feedback request to get dmabuf feedback + for a particular surface. If the client wants to retrieve feedback not + tied to a surface, they can use the get_default_feedback request. The following are required from clients: @@ -55,6 +56,12 @@ at any time use those fds to import the dmabuf into any kernel sub-system that might accept it. + However, when the underlying graphics stack fails to deliver the + promise, because of e.g. a device hot-unplug which raises internal + errors, after the wl_buffer has been successfully created the + compositor must not raise protocol errors to the client when dmabuf + import later fails. + To create a wl_buffer from one or more dmabufs, a client creates a zwp_linux_dmabuf_params_v1 object with a zwp_linux_dmabuf_v1.create_params request. All planes required by the intended format are added with @@ -76,14 +83,13 @@ client. If the client uses a failed wl_buffer as an argument to any request, the behaviour is compositor implementation-defined. - Warning! The protocol described in this file is experimental and - backward incompatible changes may be made. Backward compatible changes - may be added together with the corresponding interface version bump. - Backward incompatible changes are done by bumping the version number in - the protocol and interface names and resetting the interface version. - Once the protocol is to be declared stable, the 'z' prefix and the - version number in the protocol and interface names are removed and the - interface version number is reset. + For all DRM formats and unless specified in another protocol extension, + pre-multiplied alpha is used for pixel values. + + Unless specified otherwise in another protocol extension, implicit + synchronization is used. In other words, compositors and clients must + wait and signal fences implicitly passed via the DMA-BUF's reservation + mechanism. @@ -114,10 +120,9 @@ For the definition of the format codes, see the zwp_linux_buffer_params_v1::create request. - Warning: the 'format' event is likely to be deprecated and replaced - with the 'modifier' event introduced in zwp_linux_dmabuf_v1 - version 3, described below. Please refrain from using the information - received from this event. + Starting version 4, the format event is deprecated and must not be + sent by compositors. Instead, use get_default_feedback or + get_surface_feedback. @@ -137,9 +142,16 @@ is as if no explicit modifier is specified. The effective modifier will be derived from the dmabuf. + A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for + a given format supports both explicit modifiers and implicit modifiers. + For the definition of the format and modifier codes, see the zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add requests. + + Starting version 4, the modifier event is deprecated and must not be + sent by compositors. Instead, use get_default_feedback or + get_surface_feedback. + + + + + + This request creates a new wp_linux_dmabuf_feedback object not bound + to a particular surface. This object will deliver feedback about dmabuf + parameters to use if the client doesn't support per-surface feedback + (see get_surface_feedback). + + + + + + + This request creates a new wp_linux_dmabuf_feedback object for the + specified wl_surface. This object will deliver feedback about dmabuf + parameters to use for buffers attached to this surface. + + If the surface is destroyed before the wp_linux_dmabuf_feedback object, + the feedback object becomes inert. + + + + - + This temporary object is a collection of dmabufs and other parameters that together form a single logical buffer. The temporary @@ -206,10 +243,11 @@ compression, etc. driver-specific modifications to the base format defined by the DRM fourcc code. - Warning: It should be an error if the format/modifier pair was not - advertised with the modifier event. This is not enforced yet because - some implementations always accept DRM_FORMAT_MOD_INVALID. Also - version 2 of this protocol does not have the modifier event. + Starting from version 4, the invalid_format protocol error is sent if + the format + modifier pair was not advertised as supported. + + Starting from version 5, the invalid_format protocol error is sent if + all planes don't use the same modifier. This request raises the PLANE_IDX error if plane_idx is too large. The error PLANE_SET is raised if attempting to set a plane that @@ -225,7 +263,7 @@ summary="low 32 bits of layout modifier"/> - + @@ -296,7 +334,7 @@ - + @@ -305,7 +343,7 @@ successful. It provides the new wl_buffer referencing the dmabuf(s). Upon receiving this event, the client should destroy the - zlinux_dmabuf_params object. + zwp_linux_buffer_params_v1 object. @@ -318,7 +356,7 @@ has not been fulfilled. Upon receiving this event, the client should destroy the - zlinux_buffer_params object. + zwp_linux_buffer_params_v1 object. @@ -354,9 +392,194 @@ - + + + + + + + This object advertises dmabuf parameters feedback. This includes the + preferred devices and the supported formats/modifiers. + + The parameters are sent once when this object is created and whenever they + change. The done event is always sent once after all parameters have been + sent. When a single parameter changes, all parameters are re-sent by the + compositor. + + Compositors can re-send the parameters when the current client buffer + allocations are sub-optimal. Compositors should not re-send the + parameters if re-allocating the buffers would not result in a more optimal + configuration. In particular, compositors should avoid sending the exact + same parameters multiple times in a row. + + The tranche_target_device and tranche_formats events are grouped by + tranches of preference. For each tranche, a tranche_target_device, one + tranche_flags and one or more tranche_formats events are sent, followed + by a tranche_done event finishing the list. The tranches are sent in + descending order of preference. All formats and modifiers in the same + tranche have the same preference. + + To send parameters, the compositor sends one main_device event, tranches + (each consisting of one tranche_target_device event, one tranche_flags + event, tranche_formats events and then a tranche_done event), then one + done event. + + + + + Using this request a client can tell the server that it is not going to + use the wp_linux_dmabuf_feedback object anymore. + + + + This event is sent after all parameters of a wp_linux_dmabuf_feedback + object have been sent. + + This allows changes to the wp_linux_dmabuf_feedback parameters to be + seen as atomic, even if they happen via multiple events. + + + + + + This event provides a file descriptor which can be memory-mapped to + access the format and modifier table. + + The table contains a tightly packed array of consecutive format + + modifier pairs. Each pair is 16 bytes wide. It contains a format as a + 32-bit unsigned integer, followed by 4 bytes of unused padding, and a + modifier as a 64-bit unsigned integer. The native endianness is used. + + The client must map the file descriptor in read-only private mode. + + Compositors are not allowed to mutate the table file contents once this + event has been sent. Instead, compositors must create a new, separate + table file and re-send feedback parameters. Compositors are allowed to + store duplicate format + modifier pairs in the table. + + + + + + + + This event advertises the main device that the server prefers to use + when direct scan-out to the target device isn't possible. The + advertised main device may be different for each + wp_linux_dmabuf_feedback object, and may change over time. + + There is exactly one main device. The compositor must send at least + one preference tranche with tranche_target_device equal to main_device. + + Clients need to create buffers that the main device can import and + read from, otherwise creating the dmabuf wl_buffer will fail (see the + wp_linux_buffer_params.create and create_immed requests for details). + The main device will also likely be kept active by the compositor, + so clients can use it instead of waking up another device for power + savings. + + In general the device is a DRM node. The DRM node type (primary vs. + render) is unspecified. Clients must not rely on the compositor sending + a particular node type. Clients cannot check two devices for equality + by comparing the dev_t value. + + If explicit modifiers are not supported and the client performs buffer + allocations on a different device than the main device, then the client + must force the buffer to have a linear layout. + + + + + + + This event splits tranche_target_device and tranche_formats events in + preference tranches. It is sent after a set of tranche_target_device + and tranche_formats events; it represents the end of a tranche. The + next tranche will have a lower preference. + + + + + + This event advertises the target device that the server prefers to use + for a buffer created given this tranche. The advertised target device + may be different for each preference tranche, and may change over time. + + There is exactly one target device per tranche. + + The target device may be a scan-out device, for example if the + compositor prefers to directly scan-out a buffer created given this + tranche. The target device may be a rendering device, for example if + the compositor prefers to texture from said buffer. + + The client can use this hint to allocate the buffer in a way that makes + it accessible from the target device, ideally directly. The buffer must + still be accessible from the main device, either through direct import + or through a potentially more expensive fallback path. If the buffer + can't be directly imported from the main device then clients must be + prepared for the compositor changing the tranche priority or making + wl_buffer creation fail (see the wp_linux_buffer_params.create and + create_immed requests for details). + + If the device is a DRM node, the DRM node type (primary vs. render) is + unspecified. Clients must not rely on the compositor sending a + particular node type. Clients cannot check two devices for equality by + comparing the dev_t value. + + This event is tied to a preference tranche, see the tranche_done event. + + + + + + + This event advertises the format + modifier combinations that the + compositor supports. + + It carries an array of indices, each referring to a format + modifier + pair in the last received format table (see the format_table event). + Each index is a 16-bit unsigned integer in native endianness. + + For legacy support, DRM_FORMAT_MOD_INVALID is an allowed modifier. + It indicates that the server can support the format with an implicit + modifier. When a buffer has DRM_FORMAT_MOD_INVALID as its modifier, it + is as if no explicit modifier is specified. The effective modifier + will be derived from the dmabuf. + + A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for + a given format supports both explicit modifiers and implicit modifiers. + + Compositors must not send duplicate format + modifier pairs within the + same tranche or across two different tranches with the same target + device and flags. + + This event is tied to a preference tranche, see the tranche_done event. + + For the definition of the format and modifier codes, see the + wp_linux_buffer_params.create request. + + + + + + + + + + + This event sets tranche-specific flags. + + The scanout flag is a hint that direct scan-out may be attempted by the + compositor on the target device if the client appropriately allocates a + buffer. How to allocate a buffer that can be scanned out on the target + device is implementation-defined. + + This event is tied to a preference tranche, see the tranche_done event. + + + -- 2.7.4 From 0b14a75ce4565f9835cb0b08ef1cc8d028c90fad Mon Sep 17 00:00:00 2001 From: Changyeon Lee Date: Wed, 21 Feb 2024 11:00:06 +0900 Subject: [PATCH 08/16] Package version up to 1.3.48 Change-Id: I7cdf5ea89a0052a42fe11a86f8332e1cc111e6c8 --- packaging/wayland-extension.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packaging/wayland-extension.spec b/packaging/wayland-extension.spec index 7fc2224..16f6496 100644 --- a/packaging/wayland-extension.spec +++ b/packaging/wayland-extension.spec @@ -2,7 +2,7 @@ %define enable_examples 0 Name: wayland-extension -Version: 1.3.47 +Version: 1.3.48 Release: 0 Summary: Wayland extenstion protocols that add functionality not available in the Wayland core protocol License: MIT -- 2.7.4 From bd74ca2e0e44bd735029b058bfb017193c7b0d11 Mon Sep 17 00:00:00 2001 From: Changyeon Lee Date: Wed, 21 Feb 2024 15:43:18 +0900 Subject: [PATCH 09/16] Revert "linux-dmabuf: update the linux-dmabuf-v1 protocol to a stable version" This reverts commit 0b1153fb8250dbdc6971967a7a3fe28f961afd8e. Change-Id: I35e2d73af4a578192a641a4c2f3ef67e8b227c80 --- Makefile.am | 19 +- protocol/stable/linux-dmabuf/feedback.rst | 218 ---------------- protocol/{stable => unstable}/linux-dmabuf/README | 0 .../linux-dmabuf/linux-dmabuf-unstable-v1.xml} | 279 +++------------------ 4 files changed, 29 insertions(+), 487 deletions(-) delete mode 100644 protocol/stable/linux-dmabuf/feedback.rst rename protocol/{stable => unstable}/linux-dmabuf/README (100%) rename protocol/{stable/linux-dmabuf/linux-dmabuf-v1.xml => unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml} (56%) diff --git a/Makefile.am b/Makefile.am index 3fc4044..1ed2be0 100644 --- a/Makefile.am +++ b/Makefile.am @@ -510,27 +510,11 @@ libsingle_pixel_buffer_v1_client_la_SOURCES = protocol/staging/single-pixel-buff libsingle_pixel_buffer_v1_client_la_CFLAGS = @WAYLAND_CLIENT_CFLAGS@ libsingle_pixel_buffer_v1_client_la_LIBADD = @WAYLAND_CLIENT_LIBS@ -### linux-dmabuf-v1 -protocol_LTLIBRARIES += \ - liblinux-dmabuf-v1-server.la \ - liblinux-dmabuf-v1-client.la -pkgconfig_DATA += \ - src/liblinux-dmabuf-v1-server.pc \ - src/liblinux-dmabuf-v1-client.pc -protocolinclude_HEADERS += \ - protocol/stable/linux-dmabuf-v1-server-protocol.h \ - protocol/stable/linux-dmabuf-v1-client-protocol.h -liblinux_dmabuf_v1_server_la_SOURCES = protocol/stable/linux-dmabuf-v1-protocol.c -liblinux_dmabuf_v1_server_la_CFLAGS = @WAYLAND_SERVER_CFLAGS@ -liblinux_dmabuf_v1_server_la_LIBADD = @WAYLAND_SERVER_LIBS@ -liblinux_dmabuf_v1_client_la_SOURCES = protocol/stable/linux-dmabuf-v1-protocol.c -liblinux_dmabuf_v1_client_la_CFLAGS = @WAYLAND_CLIENT_CFLAGS@ -liblinux_dmabuf_v1_client_la_LIBADD = @WAYLAND_CLIENT_LIBS@ - ### wayland-protocols unstable_protocols = \ protocol/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml \ protocol/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml \ + protocol/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml \ protocol/unstable/text-input/text-input-unstable-v1.xml \ protocol/unstable/text-input/text-input-unstable-v3.xml \ protocol/unstable/input-method/input-method-unstable-v1.xml \ @@ -560,7 +544,6 @@ stable_protocols = \ protocol/stable/presentation-time/presentation-time.xml \ protocol/stable/viewporter/viewporter.xml \ protocol/stable/xdg-shell/xdg-shell.xml \ - protocol/stable/linux-dmabuf/linux-dmabuf-v1.xml \ $(NULL) tizen_protocols = \ diff --git a/protocol/stable/linux-dmabuf/feedback.rst b/protocol/stable/linux-dmabuf/feedback.rst deleted file mode 100644 index a3f94ed..0000000 --- a/protocol/stable/linux-dmabuf/feedback.rst +++ /dev/null @@ -1,218 +0,0 @@ -.. Copyright 2021 Simon Ser - -.. contents:: - - -linux-dmabuf feedback introduction -================================== - -linux-dmabuf feedback allows compositors and clients to negotiate optimal buffer -allocation parameters. This document will assume that the compositor is using a -rendering API such as OpenGL or Vulkan and KMS as the presentation API: even if -linux-dmabuf feedback isn't restricted to this use-case, it's the most common. - -linux-dmabuf feedback introduces the following concepts: - -1. A main device. This is the render device that the compositor is using to - perform composition. Compositors should always be able to display a buffer - submitted by a client, so this device can be used as a fallback in case none - of the more optimized code-paths work. Clients should allocate buffers such - that they can be imported and textured from the main device. - -2. One or more tranches. Each tranche consists of a target device, allocation - flags and a set of format/modifier pairs. A tranche can be seen as a set of - formats/modifier pairs that are compatible with the target device. - - A tranche can have the ``scanout`` flag. It means that the target device is - a KMS device, and that buffers allocated with one of the format/modifier - pairs in the tranche are eligible for direct scanout. - - Clients should use the tranches in order to allocate buffers with the most - appropriate format/modifier and also to avoid allocating in private device - memory when cross-device operations are going to happen. - -linux-dmabuf feedback implementation notes -========================================== - -This section contains recommendations for client and compositor implementations. - -For clients ------------ - -Clients are expected to either pick a fixed DRM format beforehand, or -perform the following steps repeatedly until they find a suitable format. - -Basic clients may only support static buffer allocation on startup. These -clients should do the following: - -1. Send a ``get_default_feedback`` request to get global feedback. -2. Select the device indicated by ``main_device`` for allocation. -3. For each tranche: - - 1. If ``tranche_target_device`` doesn't match the allocation device, ignore - the tranche. - 2. Accumulate allocation flags from ``tranche_flags``. - 3. Accumulate format/modifier pairs received via ``tranche_formats`` in a - list. - 4. When the ``tranche_done`` event is received, try to allocate the buffer - with the accumulated list of modifiers and allocation flags. If that - fails, proceed with the next tranche. If that succeeds, stop the loop. - -4. Destroy the feedback object. - -Tranches are ordered by preference: the more optimized tranches come first. As -such, clients should use the first tranche that happens to work. - -Some clients may have already selected the device they want to use beforehand. -These clients can ignore the ``main_device`` event, and ignore tranches whose -``tranche_target_device`` doesn't match the selected device. Such clients need -to be prepared for the ``wp_linux_buffer_params.create`` request to potentially -fail. - -If the client allocates a buffer without specifying explicit modifiers on a -device different from the one indicated by ``main_device``, then the client -must force a linear layout. - -Some clients might support re-negotiating the buffer format/modifier on the -fly. These clients should send a ``get_surface_feedback`` request and keep the -feedback object alive after the initial allocation. Each time a new set of -feedback parameters is received (ended by the ``done`` event), they should -perform the same steps as basic clients described above. They should detect -when the optimal allocation parameters didn't change (same -format/modifier/flags) to avoid needlessly re-allocating their buffers. - -Some clients might additionally support switching the device used for -allocations on the fly. Such clients should send a ``get_surface_feedback`` -request. For each tranche, select the device indicated by -``tranche_target_device`` for allocation. Accumulate allocation flags (received -via ``tranche_flags``) and format/modifier pairs (received via -``tranche_formats``) as usual. When the ``tranche_done`` event is received, try -to allocate the buffer with the accumulated list of modifiers and the -allocation flags. Try to import the resulting buffer by sending a -``wp_linux_buffer_params.create`` request (this might fail). Repeat with each -tranche until an allocation and import succeeds. Each time a new set of -feedback parameters is received, they should perform these steps again. They -should detect when the optimal allocation parameters didn't change (same -device/format/modifier/flags) to avoid needlessly re-allocating their buffers. - -For compositors ---------------- - -Basic compositors may only support texturing the DMA-BUFs via a rendering API -such as OpenGL or Vulkan. Such compositors can send a single tranche as a reply -to both ``get_default_feedback`` and ``get_surface_feedback``. Set the -``main_device`` to the rendering device. Send the tranche with -``tranche_target_device`` set to the rendering device and all of the DRM -format/modifier pairs supported by the rendering API. Do not set the -``scanout`` flag in the ``tranche_flags`` event. - -Some compositors may support direct scan-out for full-screen surfaces. These -compositors can re-send the feedback parameters when a surface becomes -full-screen or leaves full-screen mode if the client has used the -``get_surface_feedback`` request. The non-full-screen feedback parameters are -the same as basic compositors described above. The full-screen feedback -parameters have two tranches: one with the format/modifier pairs supported by -the KMS plane, with the ``scanout`` flag set in the ``tranche_flags`` event and -with ``tranche_target_device`` set to the KMS scan-out device; the other with -the rest of the format/modifier pairs (supported for texturing, but not for -scan-out), without the ``scanout`` flag set in the ``tranche_flags`` event, and -with the ``tranche_target_device`` set to the rendering device. - -Some compositors may support direct scan-out for all surfaces. These -compositors can send two tranches for surfaces that become candidates for -direct scan-out, similarly to compositors supporting direct scan-out for -fullscreen surfaces. When a surface stops being a candidate for direct -scan-out, compositors should re-send the feedback parameters optimized for -texturing only. The way candidates for direct scan-out are selected is -compositor policy, a possible implementation is to select as many surfaces as -there are available hardware planes, starting from surfaces closer to the eye. - -Some compositors may support multiple devices at the same time. If the -compositor supports rendering with a fixed device and direct scan-out on a -secondary device, it may send a separate tranche for surfaces displayed on -the secondary device that are candidates for direct scan-out. The -``tranche_target_device`` for this tranche will be the secondary device and -will not match the ``main_device``. - -Some compositors may support switching their rendering device at runtime or -changing their rendering device depending on the surface. When the rendering -device changes for a surface, such compositors may re-send the feedback -parameters with a different ``main_device``. However there is a risk that -clients don't support switching their device at runtime and continue using the -previous device. For this reason, compositors should always have a fallback -rendering device that they initially send as ``main_device``, such that these -clients use said fallback device. - -Compositors should not change the ``main_device`` on-the-fly when explicit -modifiers are not supported, because there's a risk of importing buffers -with an implicit non-linear modifier as a linear buffer, resulting in -misinterpreted buffer contents. - -Compositors should not send feedback parameters if they don't have a fallback -path. For instance, compositors shouldn't send a format/modifier supported for -direct scan-out but not supported by the rendering API for texturing. - -Compositors can decide to use multiple tranches to describe the allocation -parameters optimized for texturing. For example, if there are formats which -have a fast texturing path and formats which have a slower texturing path, the -compositor can decide to expose two separate tranches. - -Compositors can decide to use intermediate tranches to describe code-paths -slower than direct scan-out but faster than texturing. For instance, a -compositor could insert an intermediate tranche if it's possible to use a -mem2mem device to convert buffers to be able to use scan-out. - -``dev_t`` encoding -================== - -The protocol carries ``dev_t`` values on the wire using arrays. A compositor -written in C can encode the values as follows: - -.. code-block:: c - - struct stat drm_node_stat; - struct wl_array dev_array = { - .size = sizeof(drm_node_stat.st_rdev), - .data = &drm_node_stat.st_rdev, - }; - -A client can decode the values as follows: - -.. code-block:: c - - dev_t dev; - assert(dev_array->size == sizeof(dev)); - memcpy(&dev, dev_array->data, sizeof(dev)); - -Because two DRM nodes can refer to the same DRM device while having different -``dev_t`` values, clients should use ``drmDevicesEqual`` to compare two -devices. - -``format_table`` encoding -========================= - -The ``format_table`` event carries a file descriptor containing a list of -format + modifier pairs. The list is an array of pairs which can be accessed -with this C structure definition: - -.. code-block:: c - - struct dmabuf_format_modifier { - uint32_t format; - uint32_t pad; /* unused */ - uint64_t modifier; - }; - -Integration with other APIs -=========================== - -- libdrm: ``drmGetDeviceFromDevId`` returns a ``drmDevice`` from a device ID. -- EGL: the `EGL_EXT_device_drm_render_node`_ extension may be used to query the - DRM device render node used by a given EGL display. When unavailable, the - older `EGL_EXT_device_drm`_ extension may be used as a fallback. -- Vulkan: the `VK_EXT_physical_device_drm`_ extension may be used to query the - DRM device used by a given ``VkPhysicalDevice``. - -.. _EGL_EXT_device_drm: https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_device_drm.txt -.. _EGL_EXT_device_drm_render_node: https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_device_drm_render_node.txt -.. _VK_EXT_physical_device_drm: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_physical_device_drm.html diff --git a/protocol/stable/linux-dmabuf/README b/protocol/unstable/linux-dmabuf/README similarity index 100% rename from protocol/stable/linux-dmabuf/README rename to protocol/unstable/linux-dmabuf/README diff --git a/protocol/stable/linux-dmabuf/linux-dmabuf-v1.xml b/protocol/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml similarity index 56% rename from protocol/stable/linux-dmabuf/linux-dmabuf-v1.xml rename to protocol/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml index 38e06f5..b43e81c 100644 --- a/protocol/stable/linux-dmabuf/linux-dmabuf-v1.xml +++ b/protocol/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml @@ -1,5 +1,5 @@ - + Copyright © 2014, 2015 Collabora, Ltd. @@ -24,18 +24,17 @@ DEALINGS IN THE SOFTWARE. - + Following the interfaces from: https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt and the Linux DRM sub-system's AddFb2 ioctl. - This interface offers ways to create generic dmabuf-based wl_buffers. - - Clients can use the get_surface_feedback request to get dmabuf feedback - for a particular surface. If the client wants to retrieve feedback not - tied to a surface, they can use the get_default_feedback request. + This interface offers ways to create generic dmabuf-based + wl_buffers. Immediately after a client binds to this interface, + the set of supported formats and format modifiers is sent with + 'format' and 'modifier' events. The following are required from clients: @@ -56,12 +55,6 @@ at any time use those fds to import the dmabuf into any kernel sub-system that might accept it. - However, when the underlying graphics stack fails to deliver the - promise, because of e.g. a device hot-unplug which raises internal - errors, after the wl_buffer has been successfully created the - compositor must not raise protocol errors to the client when dmabuf - import later fails. - To create a wl_buffer from one or more dmabufs, a client creates a zwp_linux_dmabuf_params_v1 object with a zwp_linux_dmabuf_v1.create_params request. All planes required by the intended format are added with @@ -83,13 +76,14 @@ client. If the client uses a failed wl_buffer as an argument to any request, the behaviour is compositor implementation-defined. - For all DRM formats and unless specified in another protocol extension, - pre-multiplied alpha is used for pixel values. - - Unless specified otherwise in another protocol extension, implicit - synchronization is used. In other words, compositors and clients must - wait and signal fences implicitly passed via the DMA-BUF's reservation - mechanism. + Warning! The protocol described in this file is experimental and + backward incompatible changes may be made. Backward compatible changes + may be added together with the corresponding interface version bump. + Backward incompatible changes are done by bumping the version number in + the protocol and interface names and resetting the interface version. + Once the protocol is to be declared stable, the 'z' prefix and the + version number in the protocol and interface names are removed and the + interface version number is reset. @@ -120,9 +114,10 @@ For the definition of the format codes, see the zwp_linux_buffer_params_v1::create request. - Starting version 4, the format event is deprecated and must not be - sent by compositors. Instead, use get_default_feedback or - get_surface_feedback. + Warning: the 'format' event is likely to be deprecated and replaced + with the 'modifier' event introduced in zwp_linux_dmabuf_v1 + version 3, described below. Please refrain from using the information + received from this event. @@ -142,16 +137,9 @@ is as if no explicit modifier is specified. The effective modifier will be derived from the dmabuf. - A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for - a given format supports both explicit modifiers and implicit modifiers. - For the definition of the format and modifier codes, see the zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add requests. - - Starting version 4, the modifier event is deprecated and must not be - sent by compositors. Instead, use get_default_feedback or - get_surface_feedback. - - - - - - This request creates a new wp_linux_dmabuf_feedback object not bound - to a particular surface. This object will deliver feedback about dmabuf - parameters to use if the client doesn't support per-surface feedback - (see get_surface_feedback). - - - - - - - This request creates a new wp_linux_dmabuf_feedback object for the - specified wl_surface. This object will deliver feedback about dmabuf - parameters to use for buffers attached to this surface. - - If the surface is destroyed before the wp_linux_dmabuf_feedback object, - the feedback object becomes inert. - - - - - + This temporary object is a collection of dmabufs and other parameters that together form a single logical buffer. The temporary @@ -243,11 +206,10 @@ compression, etc. driver-specific modifications to the base format defined by the DRM fourcc code. - Starting from version 4, the invalid_format protocol error is sent if - the format + modifier pair was not advertised as supported. - - Starting from version 5, the invalid_format protocol error is sent if - all planes don't use the same modifier. + Warning: It should be an error if the format/modifier pair was not + advertised with the modifier event. This is not enforced yet because + some implementations always accept DRM_FORMAT_MOD_INVALID. Also + version 2 of this protocol does not have the modifier event. This request raises the PLANE_IDX error if plane_idx is too large. The error PLANE_SET is raised if attempting to set a plane that @@ -263,7 +225,7 @@ summary="low 32 bits of layout modifier"/> - + @@ -334,7 +296,7 @@ - + @@ -343,7 +305,7 @@ successful. It provides the new wl_buffer referencing the dmabuf(s). Upon receiving this event, the client should destroy the - zwp_linux_buffer_params_v1 object. + zlinux_dmabuf_params object. @@ -356,7 +318,7 @@ has not been fulfilled. Upon receiving this event, the client should destroy the - zwp_linux_buffer_params_v1 object. + zlinux_buffer_params object. @@ -392,194 +354,9 @@ - - - - - - - This object advertises dmabuf parameters feedback. This includes the - preferred devices and the supported formats/modifiers. - - The parameters are sent once when this object is created and whenever they - change. The done event is always sent once after all parameters have been - sent. When a single parameter changes, all parameters are re-sent by the - compositor. - - Compositors can re-send the parameters when the current client buffer - allocations are sub-optimal. Compositors should not re-send the - parameters if re-allocating the buffers would not result in a more optimal - configuration. In particular, compositors should avoid sending the exact - same parameters multiple times in a row. - - The tranche_target_device and tranche_formats events are grouped by - tranches of preference. For each tranche, a tranche_target_device, one - tranche_flags and one or more tranche_formats events are sent, followed - by a tranche_done event finishing the list. The tranches are sent in - descending order of preference. All formats and modifiers in the same - tranche have the same preference. - - To send parameters, the compositor sends one main_device event, tranches - (each consisting of one tranche_target_device event, one tranche_flags - event, tranche_formats events and then a tranche_done event), then one - done event. - - - - - Using this request a client can tell the server that it is not going to - use the wp_linux_dmabuf_feedback object anymore. - + - - - This event is sent after all parameters of a wp_linux_dmabuf_feedback - object have been sent. - - This allows changes to the wp_linux_dmabuf_feedback parameters to be - seen as atomic, even if they happen via multiple events. - - - - - - This event provides a file descriptor which can be memory-mapped to - access the format and modifier table. - - The table contains a tightly packed array of consecutive format + - modifier pairs. Each pair is 16 bytes wide. It contains a format as a - 32-bit unsigned integer, followed by 4 bytes of unused padding, and a - modifier as a 64-bit unsigned integer. The native endianness is used. - - The client must map the file descriptor in read-only private mode. - - Compositors are not allowed to mutate the table file contents once this - event has been sent. Instead, compositors must create a new, separate - table file and re-send feedback parameters. Compositors are allowed to - store duplicate format + modifier pairs in the table. - - - - - - - - This event advertises the main device that the server prefers to use - when direct scan-out to the target device isn't possible. The - advertised main device may be different for each - wp_linux_dmabuf_feedback object, and may change over time. - - There is exactly one main device. The compositor must send at least - one preference tranche with tranche_target_device equal to main_device. - - Clients need to create buffers that the main device can import and - read from, otherwise creating the dmabuf wl_buffer will fail (see the - wp_linux_buffer_params.create and create_immed requests for details). - The main device will also likely be kept active by the compositor, - so clients can use it instead of waking up another device for power - savings. - - In general the device is a DRM node. The DRM node type (primary vs. - render) is unspecified. Clients must not rely on the compositor sending - a particular node type. Clients cannot check two devices for equality - by comparing the dev_t value. - - If explicit modifiers are not supported and the client performs buffer - allocations on a different device than the main device, then the client - must force the buffer to have a linear layout. - - - - - - - This event splits tranche_target_device and tranche_formats events in - preference tranches. It is sent after a set of tranche_target_device - and tranche_formats events; it represents the end of a tranche. The - next tranche will have a lower preference. - - - - - - This event advertises the target device that the server prefers to use - for a buffer created given this tranche. The advertised target device - may be different for each preference tranche, and may change over time. - - There is exactly one target device per tranche. - - The target device may be a scan-out device, for example if the - compositor prefers to directly scan-out a buffer created given this - tranche. The target device may be a rendering device, for example if - the compositor prefers to texture from said buffer. - - The client can use this hint to allocate the buffer in a way that makes - it accessible from the target device, ideally directly. The buffer must - still be accessible from the main device, either through direct import - or through a potentially more expensive fallback path. If the buffer - can't be directly imported from the main device then clients must be - prepared for the compositor changing the tranche priority or making - wl_buffer creation fail (see the wp_linux_buffer_params.create and - create_immed requests for details). - - If the device is a DRM node, the DRM node type (primary vs. render) is - unspecified. Clients must not rely on the compositor sending a - particular node type. Clients cannot check two devices for equality by - comparing the dev_t value. - - This event is tied to a preference tranche, see the tranche_done event. - - - - - - - This event advertises the format + modifier combinations that the - compositor supports. - - It carries an array of indices, each referring to a format + modifier - pair in the last received format table (see the format_table event). - Each index is a 16-bit unsigned integer in native endianness. - - For legacy support, DRM_FORMAT_MOD_INVALID is an allowed modifier. - It indicates that the server can support the format with an implicit - modifier. When a buffer has DRM_FORMAT_MOD_INVALID as its modifier, it - is as if no explicit modifier is specified. The effective modifier - will be derived from the dmabuf. - - A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for - a given format supports both explicit modifiers and implicit modifiers. - - Compositors must not send duplicate format + modifier pairs within the - same tranche or across two different tranches with the same target - device and flags. - - This event is tied to a preference tranche, see the tranche_done event. - - For the definition of the format and modifier codes, see the - wp_linux_buffer_params.create request. - - - - - - - - - - - This event sets tranche-specific flags. - - The scanout flag is a hint that direct scan-out may be attempted by the - compositor on the target device if the client appropriately allocates a - buffer. How to allocate a buffer that can be scanned out on the target - device is implementation-defined. - - This event is tied to a preference tranche, see the tranche_done event. - - - -- 2.7.4 From 4c19bd4ea1d735599014cbf27478dc200a0af73a Mon Sep 17 00:00:00 2001 From: Changyeon Lee Date: Wed, 21 Feb 2024 15:43:03 +0900 Subject: [PATCH 10/16] linux-dmabuf: build server and client library Change-Id: I07ac2017a224e6e7a9061ef8c892eddf3cca21b5 --- Makefile.am | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/Makefile.am b/Makefile.am index 1ed2be0..1f0de7d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -510,6 +510,23 @@ libsingle_pixel_buffer_v1_client_la_SOURCES = protocol/staging/single-pixel-buff libsingle_pixel_buffer_v1_client_la_CFLAGS = @WAYLAND_CLIENT_CFLAGS@ libsingle_pixel_buffer_v1_client_la_LIBADD = @WAYLAND_CLIENT_LIBS@ +### linux-dmabuf-unstable-v1 +protocol_LTLIBRARIES += \ + liblinux-dmabuf-unstable-v1-server.la \ + liblinux-dmabuf-unstable-v1-client.la +pkgconfig_DATA += \ + src/liblinux-dmabuf-unstable-v1-server.pc \ + src/liblinux-dmabuf-unstable-v1-client.pc +protocolinclude_HEADERS += \ + protocol/unstable/linux-dmabuf-unstable-v1-server-protocol.h \ + protocol/unstable/linux-dmabuf-unstable-v1-client-protocol.h +liblinux_dmabuf_unstable_v1_server_la_SOURCES = protocol/unstable/linux-dmabuf-unstable-v1-protocol.c +liblinux_dmabuf_unstable_v1_server_la_CFLAGS = @WAYLAND_SERVER_CFLAGS@ +liblinux_dmabuf_unstable_v1_server_la_LIBADD = @WAYLAND_SERVER_LIBS@ +liblinux_dmabuf_unstable_v1_client_la_SOURCES = protocol/unstable/linux-dmabuf-unstable-v1-protocol.c +liblinux_dmabuf_unstable_v1_client_la_CFLAGS = @WAYLAND_CLIENT_CFLAGS@ +liblinux_dmabuf_unstable_v1_client_la_LIBADD = @WAYLAND_CLIENT_LIBS@ + ### wayland-protocols unstable_protocols = \ protocol/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml \ -- 2.7.4 From f1d89da5dcb1464431e49097bb5cbf9a0418393e Mon Sep 17 00:00:00 2001 From: Changyeon Lee Date: Wed, 21 Feb 2024 15:46:09 +0900 Subject: [PATCH 11/16] Package version up to 1.3.49 Change-Id: I3b011d44db4afd7d97532089622d387cb3f6c6df --- packaging/wayland-extension.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packaging/wayland-extension.spec b/packaging/wayland-extension.spec index 16f6496..3e87eac 100644 --- a/packaging/wayland-extension.spec +++ b/packaging/wayland-extension.spec @@ -2,7 +2,7 @@ %define enable_examples 0 Name: wayland-extension -Version: 1.3.48 +Version: 1.3.49 Release: 0 Summary: Wayland extenstion protocols that add functionality not available in the Wayland core protocol License: MIT -- 2.7.4 From afd70bcebb78fa388271e97602c47f6a0c42fb3c Mon Sep 17 00:00:00 2001 From: Changyeon Lee Date: Tue, 27 Feb 2024 20:45:48 +0900 Subject: [PATCH 12/16] linux-dmabuf: remove prefix lib of pc Change-Id: Iba22847aacd37bb066bc426e28403f7962057d3c --- Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index 1f0de7d..64f0f9d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -515,8 +515,8 @@ protocol_LTLIBRARIES += \ liblinux-dmabuf-unstable-v1-server.la \ liblinux-dmabuf-unstable-v1-client.la pkgconfig_DATA += \ - src/liblinux-dmabuf-unstable-v1-server.pc \ - src/liblinux-dmabuf-unstable-v1-client.pc + src/linux-dmabuf-unstable-v1-server.pc \ + src/linux-dmabuf-unstable-v1-client.pc protocolinclude_HEADERS += \ protocol/unstable/linux-dmabuf-unstable-v1-server-protocol.h \ protocol/unstable/linux-dmabuf-unstable-v1-client-protocol.h -- 2.7.4 From e9d09d96547e0a3729a5188013cc6851c4715330 Mon Sep 17 00:00:00 2001 From: Changyeon Lee Date: Tue, 27 Feb 2024 20:46:27 +0900 Subject: [PATCH 13/16] Package version up to 1.3.50 Change-Id: I5c0cc3b91cf20cb55682a059078878bcccc75c88 --- packaging/wayland-extension.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packaging/wayland-extension.spec b/packaging/wayland-extension.spec index 3e87eac..8921a1c 100644 --- a/packaging/wayland-extension.spec +++ b/packaging/wayland-extension.spec @@ -2,7 +2,7 @@ %define enable_examples 0 Name: wayland-extension -Version: 1.3.49 +Version: 1.3.50 Release: 0 Summary: Wayland extenstion protocols that add functionality not available in the Wayland core protocol License: MIT -- 2.7.4 From beebebc2a1a4b352624ac0ebfe354eeb510cd790 Mon Sep 17 00:00:00 2001 From: Junkyeong Kim Date: Wed, 28 Feb 2024 15:58:51 +0900 Subject: [PATCH 14/16] Erase allow-null option of array type arguments allow-null option is prohibited to array type by wayland. Change-Id: Id8c5732ba8b133a34c9044117da9151251a1b27d Signed-off-by: Junkyeong Kim --- protocol/tizen/tizen-launch.xml | 8 ++++---- protocol/tizen/tizen-remote-surface.xml | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/tizen/tizen-launch.xml b/protocol/tizen/tizen-launch.xml index 52d95ee..ea21a46 100644 --- a/protocol/tizen/tizen-launch.xml +++ b/protocol/tizen/tizen-launch.xml @@ -7,7 +7,7 @@ - + @@ -50,7 +50,7 @@ - + @@ -65,8 +65,8 @@ - - + + diff --git a/protocol/tizen/tizen-remote-surface.xml b/protocol/tizen/tizen-remote-surface.xml index 4b5381d..71e4408 100644 --- a/protocol/tizen/tizen-remote-surface.xml +++ b/protocol/tizen/tizen-remote-surface.xml @@ -106,7 +106,7 @@ request. - > + @@ -278,7 +278,7 @@ - + -- 2.7.4 From ba81ed0e8a22922697cc5cf2fcae69d2f48bbd8b Mon Sep 17 00:00:00 2001 From: Junkyeong Kim Date: Wed, 28 Feb 2024 16:01:25 +0900 Subject: [PATCH 15/16] Change code to public-code the code is deprecated. Change-Id: I2867b6a48d40760fb599cb1bfc8a9e9c31051b12 Signed-off-by: Junkyeong Kim --- Makefile.am | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Makefile.am b/Makefile.am index 64f0f9d..881e5e2 100644 --- a/Makefile.am +++ b/Makefile.am @@ -15,7 +15,7 @@ protocol_LTLIBRARIES = ### protocol/tizen/protocol.[ch] protocol/tizen/%-protocol.c : $(top_srcdir)/protocol/tizen/%.xml - $(wayland_scanner) code < $< > $@ + $(wayland_scanner) public-code < $< > $@ protocol/tizen/%-server-protocol.h : $(top_srcdir)/protocol/tizen/%.xml $(wayland_scanner) server-header < $< > $@ protocol/tizen/%-client-protocol.h : $(top_srcdir)/protocol/tizen/%.xml @@ -23,7 +23,7 @@ protocol/tizen/%-client-protocol.h : $(top_srcdir)/protocol/tizen/%.xml ### protocol/unstable/protocol.[ch] protocol/unstable/%-protocol.c : $(top_srcdir)/protocol/unstable/*/%.xml - $(wayland_scanner) code < $< > $@ + $(wayland_scanner) public-code < $< > $@ protocol/unstable/%-server-protocol.h : $(top_srcdir)/protocol/unstable/*/%.xml $(wayland_scanner) server-header < $< > $@ protocol/unstable/%-client-protocol.h : $(top_srcdir)/protocol/unstable/*/%.xml @@ -31,7 +31,7 @@ protocol/unstable/%-client-protocol.h : $(top_srcdir)/protocol/unstable/*/%.xml ### protocol/staging/protocol.[ch] protocol/staging/%-protocol.c : $(top_srcdir)/protocol/staging/*/%.xml - $(wayland_scanner) code < $< > $@ + $(wayland_scanner) public-code < $< > $@ protocol/staging/%-server-protocol.h : $(top_srcdir)/protocol/staging/*/%.xml $(wayland_scanner) server-header < $< > $@ protocol/staging/%-client-protocol.h : $(top_srcdir)/protocol/staging/*/%.xml @@ -39,7 +39,7 @@ protocol/staging/%-client-protocol.h : $(top_srcdir)/protocol/staging/*/%.xml ### protocol/stable/protocol.[ch] protocol/stable/%-protocol.c : $(top_srcdir)/protocol/stable/*/%.xml - $(wayland_scanner) code < $< > $@ + $(wayland_scanner) public-code < $< > $@ protocol/stable/%-server-protocol.h : $(top_srcdir)/protocol/stable/*/%.xml $(wayland_scanner) server-header < $< > $@ protocol/stable/%-client-protocol.h : $(top_srcdir)/protocol/stable/*/%.xml -- 2.7.4 From 311091f58e7340e9171c422c58e609e612e0b6a7 Mon Sep 17 00:00:00 2001 From: Junkyeong Kim Date: Wed, 28 Feb 2024 16:02:32 +0900 Subject: [PATCH 16/16] Package version up to 1.3.51 Change-Id: I7d6e060d8b376f202490dd42c4ad69afadb3de77 Signed-off-by: Junkyeong Kim --- packaging/wayland-extension.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packaging/wayland-extension.spec b/packaging/wayland-extension.spec index 8921a1c..a238348 100644 --- a/packaging/wayland-extension.spec +++ b/packaging/wayland-extension.spec @@ -2,7 +2,7 @@ %define enable_examples 0 Name: wayland-extension -Version: 1.3.50 +Version: 1.3.51 Release: 0 Summary: Wayland extenstion protocols that add functionality not available in the Wayland core protocol License: MIT -- 2.7.4