开源软件构建与测试

_service:tar_scm:wayland-protocols.spec Changed

_service:tar_scm:wayland-protocols-1.32.tar.xz/.gitlab-ci.yml -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/.gitlab-ci.yml Changed

_service:tar_scm:wayland-protocols-1.32.tar.xz/GOVERNANCE.md -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/GOVERNANCE.md Changed

@@ -58,7 +58,7 @@
 2. Protocols in a namespace may optionally use the namespace followed by a dash
    in the name (e.g. "xdg-shell").
 3. The "xdg" namespace is established for protocols letting clients
-   configure its surfaces as "windows", allowing clients to affect how they
+   configure their surfaces as "windows", allowing clients to affect how they
    are managed.
 4. The "wp" namespace is established for protocols generally useful to Wayland
    implementations (i.e. "plumbing" protocols).
@@ -72,7 +72,7 @@
 2. Protocols in the "xdg" and "wp" namespace are eligible for inclusion only if
    ACKed by at least 3 members.
 3. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if
-   if NACKed by any member.
+   NACKed by any member.
 4. Protocols in the "xdg" and "wp" namespaces must have at least 3 open-source
    implementations (either 1 client + 2 servers, or 2 clients + 1 server) to be
    eligible for inclusion.
@@ -95,7 +95,7 @@
    use this time to acquire them.
 4. When the proposed protocol meets all requirements for inclusion per section
    2.2, and the minimum discussion period has elapsed, the sponsoring member may
-   merge their changes in the wayland-protocol repository.
+   merge their changes into the wayland-protocol repository.
 5. Amendments to existing protocols may be proposed by the same process, with
    no minimum discussion period.
 6. Declaring a protocol stable may be proposed by the same process, with the

_service:tar_scm:wayland-protocols-1.32.tar.xz/MEMBERS.md -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/MEMBERS.md Changed

_service:tar_scm:wayland-protocols-1.32.tar.xz/README.md -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/README.md Changed

@@ -10,9 +10,14 @@
 of XML files containing the protocol specification, and a README file
 containing detailed state and a list of maintainers.
 
+wayland-protocols is a standardization body formed of various Wayland
+compositor and client developers. The governance rules are described in
+GOVERNANCE.md(GOVERNANCE.md) and the current members are listed in
+MEMBERS.md(MEMBERS.md).
+
 ## Protocol phases
 
-Protocols in general has three phases: the development phase, the testing
+Protocols in general have three phases: the development phase, the testing
 phase, and the stable phase.
 
 In the development phase, a protocol is not officially part of
@@ -31,14 +36,14 @@
 and after the GOVERNANCE section
 2.3(GOVERNANCE.md#2.3-introducing-new-protocols) requirements have been
 met, it enters the "testing" phase. At this point, the protocol is added
-to `staging/` directory of wayland-protocols and made part of a release.
+to the `staging/` directory of wayland-protocols and made part of a release.
 What this means is that implementation is encouraged in clients and
 compositors where the functionality it specifies is wanted.
 
 Extensions in staging cannot have backward incompatible changes, in that
 sense they are equal to stable extensions. However, they may be completely
-replaced with a new major version, or a different protocol extension all
-together, if design flaws are found in the testing phase.
+replaced with a new major version, or a different protocol extension altogether,
+if design flaws are found in the testing phase.
 
 After a staging protocol has been sufficiently tested in the wild and
 proven adequate, its maintainers and the community at large may declare it
@@ -58,8 +63,8 @@
 placed in the `unstable/` directory had certain naming conventions were
 applied, requiring a backward incompatible change to be declared "stable".
 
-During this phase, protocol extension interface names were in addition to
-the major version postfix also prefixed with `z` to distinguish from
+During this phase, protocol extension interface names were, in addition to
+the major version postfix, also prefixed with `z` to distinguish them from
 stable protocols.
 
 ## Protocol directory tree structure
@@ -196,8 +201,8 @@
   same name as the protocol directory in the `staging/` directory.
 - Copy the final version of the XML that is the version that was
   decided to be declared stable into the new directory. The target name
-  should be the same name as the protocol directory but with the `.xml`
-  suffix.
+  should be the same name as the protocol directory plus the version and
+  the `.xml` suffix.
 - Remove the disclaimer about the protocol being in the testing phase.
 - Update the `README` file in the staging directory and create a new
   `README` file in the new directory.
@@ -243,7 +248,7 @@
 period.
 
 For the meaning and requirement of acknowledgments and available
-implementations, see the GOVERNANCE.md document.
+implementations, see the GOVERNANCE.md(GOVERNANCE.md) document.
 
 ### Managing merge requests

_service:tar_scm:wayland-protocols-1.32.tar.xz/meson.build -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/meson.build Changed

@@ -1,5 +1,5 @@
 project('wayland-protocols',
-	version: '1.32',
+	version: '1.33',
 	meson_version: '>= 0.55.0',
 	license: 'MIT/Expat',
 )
@@ -8,11 +8,12 @@
 
 fs = import('fs')
 
-stable_protocols = 
-	'presentation-time',
-	'viewporter',
-	'xdg-shell',
-
+stable_protocols = {
+	'presentation-time': '',
+	'viewporter': '',
+	'xdg-shell': '',
+	'linux-dmabuf': 'v1',
+}
 
 unstable_protocols = {
 	'fullscreen-shell': 'v1',
@@ -46,26 +47,33 @@
 	'security-context': 'v1',
 	'single-pixel-buffer': 'v1',
 	'tearing-control': 'v1',
+	'ext-transient-seat': 'v1',
 	'xdg-activation': 'v1',
 	'xwayland-shell': 'v1',
 }
 
 protocol_files = 
 
-foreach name : stable_protocols
-	protocol_files += 'stable/@0@/@0@.xml'.format(name)
+foreach name, versions : stable_protocols
+	foreach version : versions
+		if version == ''
+			protocol_files += 'stable/@0@/@0@.xml'.format(name)
+		else
+			protocol_files += 'stable/@0@/@0@-@1@.xml'.format(name, version)
+		endif
+	endforeach
 endforeach
 
-foreach name : staging_protocols.keys()
-	foreach version : staging_protocols.get(name)
+foreach name, versions : staging_protocols
+	foreach version : versions
 		protocol_files += 
 			'staging/@0@/@0@-@1@.xml'.format(name, version)
 		
 	endforeach
 endforeach
 
-foreach name : unstable_protocols.keys()
-	foreach version : unstable_protocols.get(name)
+foreach name, versions : unstable_protocols
+	foreach version : versions
 		protocol_files += 
 			'unstable/@0@/@0@-unstable-@1@.xml'.format(name, version)

_service:tar_scm:wayland-protocols-1.33.tar.bz2/stable/linux-dmabuf Added

_service:tar_scm:wayland-protocols-1.33.tar.bz2/stable/linux-dmabuf/README Added

_service:tar_scm:wayland-protocols-1.33.tar.bz2/stable/linux-dmabuf/feedback.rst Added

@@ -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
+

_service:tar_scm:wayland-protocols-1.33.tar.bz2/stable/linux-dmabuf/linux-dmabuf-v1.xml Added

@@ -0,0 +1,585 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="linux_dmabuf_v1">
+
+  <copyright>
+    Copyright © 2014, 2015 Collabora, 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.
+  </copyright>
+
+  <interface name="zwp_linux_dmabuf_v1" version="5">
+    <description summary="factory for creating dmabuf-based wl_buffers">
+      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.
+
+      The following are required from clients:
+
+      - Clients must ensure that either all data in the dma-buf is
+        coherent for all subsequent read access or that coherency is
+        correctly handled by the underlying kernel-side dma-buf
+        implementation.
+
+      - Don't make any more attachments after sending the buffer to the
+        compositor. Making more attachments later increases the risk of
+        the compositor not being able to use (re-import) an existing
+        dmabuf-based wl_buffer.
+
+      The underlying graphics stack must ensure the following:
+
+      - The dmabuf file descriptors relayed to the server will stay valid
+        for the whole lifetime of the wl_buffer. This means the server may
+        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
+      the 'add' request. Finally, a 'create' or 'create_immed' request is
+      issued, which has the following outcome depending on the import success.
+
+      The 'create' request,
+      - on success, triggers a 'created' event which provides the final
+        wl_buffer to the client.
+      - on failure, triggers a 'failed' event to convey that the server
+        cannot use the dmabufs received from the client.
+
+      For the 'create_immed' request,
+      - on success, the server immediately imports the added dmabufs to
+        create a wl_buffer. No event is sent from the server in this case.
+      - on failure, the server can choose to either:
+        - terminate the client by raising a fatal error.
+        - mark the wl_buffer as failed, and send a 'failed' event to the
+          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.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="unbind the factory">
+        Objects created through this interface, especially wl_buffers, will
+        remain valid.
+      </description>
+    </request>
+
+    <request name="create_params">
+      <description summary="create a temporary object for buffer parameters">
+        This temporary object is used to collect multiple dmabuf handles into
+        a single batch to create a wl_buffer. It can only be used once and
+        should be destroyed after a 'created' or 'failed' event has been
+        received.
+      </description>
+      <arg name="params_id" type="new_id" interface="zwp_linux_buffer_params_v1"
+           summary="the new temporary"/>
+    </request>
+
+    <event name="format">
+      <description summary="supported buffer format">
+        This event advertises one buffer format that the server supports.
+        All the supported formats are advertised once when the client
+        binds to this interface. A roundtrip after binding guarantees
+        that the client has received all supported formats.
+
+        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.
+      </description>
+      <arg name="format" type="uint" summary="DRM_FORMAT code"/>
+    </event>
+
+    <event name="modifier" since="3">
+      <description summary="supported buffer format modifier">
+        This event advertises the formats that the server supports, along with
+        the modifiers supported for each format. All the supported modifiers
+        for all the supported formats are advertised once when the client
+        binds to this interface. A roundtrip after binding guarantees that
+        the client has received all supported format-modifier pairs.
+
+        For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
+        0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event.
+        It indicates that the server can support the format with an implicit
+        modifier. When a plane 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.
+
+        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.
+      </description>
+      <arg name="format" type="uint" summary="DRM_FORMAT code"/>
+      <arg name="modifier_hi" type="uint"
+           summary="high 32 bits of layout modifier"/>
+      <arg name="modifier_lo" type="uint"
+           summary="low 32 bits of layout modifier"/>
+    </event>
+
+    
+
+    <request name="get_default_feedback" since="4">
+      <description summary="get default 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).
+      </description>
+      <arg name="id" type="new_id" interface="zwp_linux_dmabuf_feedback_v1"/>
+    </request>
+
+    <request name="get_surface_feedback" since="4">
+      <description summary="get feedback for a surface">
+        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.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_linux_dmabuf_feedback_v1"/>
+      <arg name="surface" type="object" interface="wl_surface"/>
+    </request>
+  </interface>
+
+  <interface name="zwp_linux_buffer_params_v1" version="5">
+    <description summary="parameters for creating a dmabuf-based wl_buffer">
+      This temporary object is a collection of dmabufs and other
+      parameters that together form a single logical buffer. The temporary
+      object may eventually create one wl_buffer unless cancelled by
+      destroying it before requesting 'create'.
+
+      Single-planar formats only require one dmabuf, however
+      multi-planar formats may require more than one dmabuf. For all
+      formats, an 'add' request must be called once per plane (even if the
+      underlying dmabuf fd is identical).

_service:tar_scm:wayland-protocols-1.32.tar.xz/stable/presentation-time/presentation-time.xml -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/stable/presentation-time/presentation-time.xml Changed

_service:tar_scm:wayland-protocols-1.32.tar.xz/stable/xdg-shell/xdg-shell.xml -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/stable/xdg-shell/xdg-shell.xml Changed

_service:tar_scm:wayland-protocols-1.32.tar.xz/staging/drm-lease/drm-lease-v1.xml -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/staging/drm-lease/drm-lease-v1.xml Changed

_service:tar_scm:wayland-protocols-1.33.tar.bz2/staging/ext-transient-seat Added

_service:tar_scm:wayland-protocols-1.33.tar.bz2/staging/ext-transient-seat/README Added

_service:tar_scm:wayland-protocols-1.33.tar.bz2/staging/ext-transient-seat/ext-transient-seat-v1.xml Added

@@ -0,0 +1,110 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="ext_transient_seat_v1">
+  <copyright>
+    Copyright © 2020 - 2023 Andri Yngvason
+
+    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.
+  </copyright>
+
+  <description summary="protocol for creating temporary seats">
+    The transient seat protocol can be used by privileged clients to create
+    independent seats that will be removed from the compositor when the client
+    destroys its transient seat.
+
+    This protocol is intended for use with virtual input protocols such as
+    "virtual_keyboard_unstable_v1" or "wlr_virtual_pointer_unstable_v1", both
+    of which allow the user to select a seat.
+
+    The "wl_seat" global created by this protocol does not generate input events
+    on its own, or have any capabilities except those assigned to it by other
+    protocol extensions, such as the ones mentioned above.
+
+    For example, a remote desktop server can create a seat with virtual inputs
+    for each remote user by following these steps for each new connection:
+     * Create a transient seat
+     * Wait for the transient seat to be created
+     * Locate a "wl_seat" global with a matching name
+     * Create virtual inputs using the resulting "wl_seat" global
+  </description>
+
+  <interface name="ext_transient_seat_manager_v1" version="1">
+    <description summary="transient seat manager">
+      The transient seat manager creates short-lived seats.
+    </description>
+
+    <request name="create">
+      <description summary="create a transient seat">
+        Create a new seat that is removed when the client side transient seat
+        object is destroyed.
+
+        The actual seat may be removed sooner, in which case the transient seat
+        object shall become inert.
+      </description>
+      <arg name="seat" type="new_id" interface="ext_transient_seat_v1"/>
+    </request>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the manager">
+        Destroy the manager.
+
+        All objects created by the manager will remain valid until they are
+        destroyed themselves.
+      </description>
+    </request>
+  </interface>
+
+  <interface name="ext_transient_seat_v1" version="1">
+    <description summary="transient seat handle">
+      When the transient seat handle is destroyed, the seat itself will also be
+      destroyed.
+    </description>
+
+    <event name="ready">
+      <description summary="transient seat is ready">
+        This event advertises the global name for the wl_seat to be used with
+        wl_registry_bind.
+
+        It is sent exactly once, immediately after the transient seat is created
+        and the new "wl_seat" global is advertised, if and only if the creation
+        of the transient seat was allowed.
+      </description>
+      <arg name="global_name" type="uint"/>
+    </event>
+
+    <event name="denied">
+      <description summary="transient seat creation denied">
+        The event informs the client that the compositor denied its request to
+        create a transient seat.
+
+        It is sent exactly once, immediately after the transient seat object is
+        created, if and only if the creation of the transient seat was denied.
+
+        After receiving this event, the client should destroy the object.
+      </description>
+    </event>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy transient seat">
+        When the transient seat object is destroyed by the client, the
+        associated seat created by the compositor is also destroyed.
+      </description>
+    </request>
+  </interface>
+</protocol>

_service:tar_scm:wayland-protocols-1.32.tar.xz/staging/security-context/engines.md -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/staging/security-context/engines.md Changed

_service:tar_scm:wayland-protocols-1.32.tar.xz/staging/security-context/security-context-v1.xml -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/staging/security-context/security-context-v1.xml Changed

@@ -73,6 +73,9 @@
 
         The compositor must continue to accept connections on listen_fd when
         the Wayland client which created the security context disconnects.
+
+        After sending this request, closing listen_fd and close_fd remains the
+        only valid operation on them.
       </description>
       <arg name="id" type="new_id" interface="wp_security_context_v1"/>
       <arg name="listen_fd" type="fd" summary="listening socket FD"/>
@@ -111,7 +114,8 @@
 
     <request name="set_sandbox_engine">
       <description summary="set the sandbox engine">
-        Attach a unique sandbox engine name to the security context.
+        Attach a unique sandbox engine name to the security context. The name
+        should follow the reverse-DNS style (e.g. "org.flatpak").
 
         A list of well-known engines is maintained at:
         https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/security-context/engines.md
@@ -163,6 +167,11 @@
         Atomically register the new client and attach the security context
         metadata.
 
+        If the provided metadata is inconsistent or does not match with out of
+        band metadata (see
+        https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/security-context/engines.md),
+        the invalid_metadata error may be sent eventually.
+
         It's a protocol error to send any request other than "destroy" after
         this request. In this case, the already_used error is sent.
       </description>

_service:tar_scm:wayland-protocols-1.32.tar.xz/unstable/linux-dmabuf/README -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/unstable/linux-dmabuf/README Changed

_service:tar_scm:wayland-protocols-1.32.tar.xz/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml Changed

@@ -24,7 +24,7 @@
     DEALINGS IN THE SOFTWARE.
   </copyright>
 
-  <interface name="zwp_linux_dmabuf_v1" version="4">
+  <interface name="zwp_linux_dmabuf_v1" version="5">
     <description summary="factory for creating dmabuf-based wl_buffers">
       Following the interfaces from:
       https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
@@ -86,14 +86,14 @@
       For all DRM formats and unless specified in another protocol extension,
       pre-multiplied alpha is used for pixel values.
 
-      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.
+      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.
+
+      Disclaimer: This protocol extension has been marked stable. This copy is
+      no longer used and only retained for backwards compatibility. The
+      canonical version can be found in the stable/ directory.
     </description>
 
     <request name="destroy" type="destructor">
@@ -190,7 +190,7 @@
     </request>
   </interface>
 
-  <interface name="zwp_linux_buffer_params_v1" version="4">
+  <interface name="zwp_linux_buffer_params_v1" version="5">
     <description summary="parameters for creating a dmabuf-based wl_buffer">
       This temporary object is a collection of dmabufs and other
       parameters that together form a single logical buffer. The temporary
@@ -250,6 +250,9 @@
         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
         was already set.
@@ -397,7 +400,7 @@
     </request>
   </interface>
 
-  <interface name="zwp_linux_dmabuf_feedback_v1" version="4">
+  <interface name="zwp_linux_dmabuf_feedback_v1" version="5">
     <description summary="dmabuf feedback">
       This object advertises dmabuf parameters feedback. This includes the
       preferred devices and the supported formats/modifiers.

_service:tar_scm:wayland-protocols-1.32.tar.xz/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml -> _service:tar_scm:wayland-protocols-1.33.tar.bz2/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml Changed

_service:tar_scm:wayland-protocols-1691564297.a3d1f6e.tar Deleted

Changes of Revision 2