2026-05-08 11:18:03 +02:00
33 changed files with 368 additions and 2347 deletions
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@ -27,7 +27,7 @@ workflow:
  variables:
    FDO_DISTRIBUTION_VERSION: trixie
    FDO_DISTRIBUTION_PACKAGES: 'build-essential pkg-config meson git ca-certificates libffi-dev libexpat1-dev libxml2-dev'
-    FDO_DISTRIBUTION_TAG: '2026-04-05.0'
+    FDO_DISTRIBUTION_TAG: '2025-11-15.0'
    FDO_DISTRIBUTION_EXEC: 'env FDO_CI_CONCURRENT=${FDO_CI_CONCURRENT} ./.gitlab-ci/debian-install.sh'
 check-commit:
--- a/.gitlab-ci/debian-install.sh
+++ b/.gitlab-ci/debian-install.sh
@ -2,7 +2,7 @@
 # Note: don't forget to bump FDO_DISTRIBUTION_TAG when editing this file!
-git clone --branch 1.25.0 --depth=1 https://gitlab.freedesktop.org/wayland/wayland
+git clone --branch 1.23.1 --depth=1 https://gitlab.freedesktop.org/wayland/wayland
 cd wayland/
 git show -s HEAD
 meson build/ -Dtests=false -Ddocumentation=false
--- a/README.md
+++ b/README.md
@ -16,30 +16,29 @@ compositor and client developers. The governance rules are described in
 ## Protocol phases
-Protocols have three currently used phases: the experimental phase, the staging
+Protocols in general have three phases: the development phase, the testing
-phase, and the stable phase. Anything that is merged upstream is in one of
+phase, and the stable phase.
 those phases, with the exception of deprecated protocols and protocols in
 the legacy protocol phases.
-Backward-incompatible changes can only be introduced in a new major version of
+In the development phase, a protocol may be added to wayland-protocols
-a protocol. In the experimental phase, a protocol is actively being
+as `experimental/`. It is actively being developed, for example by
-developed and iterated upon, not trying to avoid incompatible changes.
+iterating over it in a [merge request] or planning it in an [issue].
-Protocols in the staging phase should try to minimize backward-incompatible
+Extensions in this phase can have backward incompatible changes.
 changes, and protocols in the stable phase should avoid backward-incompatible
 changes.
-Anything that is not merged upstream can be iterated and broken freely, but
+During this phase, patches for clients and compositors are written as a test
-care should be taken to ensure that there are no two protocols with the same
+vehicle. Such patches should be merged with caution in clients and compositors,
-name and version but a different API.
+because the protocol can still change.
 During the experimental phase, patches for clients and compositors are written
 as a test vehicle. Such patches should be merged with caution in clients and
 compositors, because the protocol can still change.
 When a protocol has reached a stage where it is ready for wider adoption,
-it enters the "staging" phase. What this means is that implementation is
+and after the [GOVERNANCE section 2.3] requirements have been met, it enters
-encouraged in clients and compositors where the functionality it specifies is
+the "testing" phase. At this point, the protocol is added to the `staging/`
-wanted.
+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 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
@ -55,10 +54,11 @@ will be made to a deprecated protocol.
 ## Legacy protocol phases
 An "unstable" protocol refers to a protocol categorization policy
-previously used by wayland-protocols, where certain naming conventions were
+previously used by wayland-protocols, where protocols initially
 placed in the `unstable/` directory had certain naming conventions were
 applied, requiring a backward incompatible change to be declared "stable".
-During this phase, protocol interface names were, in addition to
+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.
@ -67,9 +67,8 @@ stable protocols.
 Depending on which stage a protocol is in, the protocol is placed within
 the toplevel directory containing the protocols with the same stage.
 Stable protocols are placed in the `stable/` directory, staging protocols
-are placed in the `staging/` directory, experimental protocols are placed
+are placed in the `staging/` directory, and deprecated protocols are
-in the `experimental/` directory, and deprecated protocols are placed in
+placed in the `deprecated/` directory.
 the `deprecated/` directory.
 Unstable protocols (see [Legacy protocol phases]) can be found in the
 `unstable/` directory, but new ones should never be placed here.
@ -140,6 +139,17 @@ corresponding to the major version 1, as well as the newer version
 `foo-bar/foo-bar-v2.xml` consisting of the interface `wp_foo_bar_v2`,
 corresponding to the major version 2.
 ## Include a disclaimer
 Include the following disclaimer:
 ```
 Warning! The protocol described in this file is currently in the testing
 phase. Backward compatible changes may be added together with the
 corresponding interface version bump. Backward incompatible changes can
 only be done by creating a new major version of the extension.
 ```
 ## Use of RFC 2119 keywords
 Descriptions of all new protocols must use (in lowercase) and adhere to the
@ -165,10 +175,26 @@ A protocol may receive backward compatible additions and changes. This
 is to be done in the general Wayland way, using `version` and `since` XML
 element attributes.
-## Backward incompatible protocol changes
+## Backward incompatible protocol changes for experimental protocols
-Protocols shall try to avoid backwards incompatible protocol changes during
+A protocol in the experimental phase should expect to see backward incompatible
-the staging and stable phases.
+changes at any time.
 Assuming a backward incompatible change is needed here, the procedure for how to
 do so is the following:
 - Increase the major version number in the protocol XML by 1.
 - Increase the major version number in all of the interfaces in the
  XML by 1.
 - Reset the interface version number (interface version attribute) of all
  the interfaces to 1.
 - Remove all of the `since` attributes.
 ## Backward incompatible protocol changes for testing protocols
 While not preferred, a protocol may at any stage, especially during the
 testing phase, when it is located in the `staging/` directory, see
 backward incompatible changes.
 Assuming a backward incompatible change is needed, the procedure for how to
 do so is the following:
@ -181,7 +207,7 @@ do so is the following:
  the interfaces to 1.
 - Remove all of the `since` attributes.
-## The experimental phase
+## Experimental Protocols: Development Recommendations
 Implementations choosing to support experimental protocols must work to
 support the latest version of the protocol at all times. It is therefore
@ -191,46 +217,26 @@ have time and resources to actively develop.
 A runtime option to enable features may also be useful to ensure users
 do not opt-in to potentially broken behavior.
-There is no expectation or requirement to avoid backwards incompatible changes
+There is no expectation or requirement for stability between experimental
-in this phase. It is therefore strongly advised that such consumer projects add
+protocol versions. It is therefore strongly advised that such consumer
-build-time compile options to enable such protocols in order to avoid compile
+projects add build-time compile options to enable such protocols in order
-errors from protocol version mismatches.
+to avoid compile errors from protocol version mismatches.
-## The staging phase
+## Promoting a protocol from experimental
-Protocols can enter the wayland-protocols repository in this stage, without
+The author of an experimental protocol can request that it be promoted at any point
-traversing the experimental phase. The author of an experimental protocol can
+when it meets the requirements for `staging/`. At such time,
-request that it be promoted at any point.
+the namespace prefix should be determined, and then the protocol should be
 renamed and merged into the appropriate directory, deleting the `experimental/`
 entry.
-In both cases, the protocol must meet the requirements of
+## Declaring a protocol stable
 [GOVERNANCE section 2.3] for the staging phase.
 Protocols in the staging phase must carry the following disclaimer:
 ```
 Warning! The protocol described in this file is currently in the staging
 phase. Backward compatible changes may be added together with the
 corresponding interface version bump. Backward incompatible changes can
 only be done by creating a new major version of the protocol.
 ```
 When a protocol gets promoted from the experimental phase, the namespace prefix
 should be determined, and then the protocol should be renamed and merged into
 the appropriate directory, deleting the `experimental/` entry.
 ## The stable phase
 Once it has been concluded that a protocol been proven adequate in
 production, and that it is deemed unlikely to receive any backward
 incompatible changes, it may be declared stable.
-There are other requirements for declaring a protocol stable, see
+The procedure of doing this is the following:
 [GOVERNANCE section 2.3].
 Note that the major version of the stable protocol, as well as all the
 interface versions and names, must remain unchanged.
 The procedure of promoting a protocol to the stable phase is the following:
 - Create a new directory in the `stable/` toplevel directory with the
  same name as the protocol directory in the `staging/` directory.
@ -238,18 +244,24 @@ The procedure of promoting a protocol to the stable phase is the following:
  decided to be declared stable into the new directory. The target name
  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 staging phase.
+- 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.
 - Replace the disclaimer in the protocol files left in the staging/
  directory with the following:
 ```
-Disclaimer: This protocol has been marked stable. This copy is
+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.
 ```
 Note that the major version of the stable protocol extension, as well as
 all the interface versions and names, must remain unchanged.
 There are other requirements for declaring a protocol stable, see
 [GOVERNANCE section 2.3].
 ## Releases
 Each release of wayland-protocols finalizes the version of the protocols
--- a/experimental/xx-cutouts/README
+++ b/experimental/xx-cutouts/README
@ -1,4 +0,0 @@
 xx cutouts protocol
 Maintainers:
 Guido Günther <agx@sigxcpu.org>
--- a/experimental/xx-cutouts/xx-cutouts-v1.xml
+++ b/experimental/xx-cutouts/xx-cutouts-v1.xml
@ -1,232 +0,0 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <protocol name="xx_cutouts_unstable_v1">
  <copyright>
    Copyright © 2026 Phosh.mobi e.V.
    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.
    Warning! The protocol described in this file is currently in the
    experimental phase. Backwards incompatible major versions of the protocol
    are to be expected. Exposing this protocol without an opt-in mechanism is
    discouraged.
  </copyright>
  <description summary="Protocol to describe cut out surface regions">
    This protocol describes the areas of a toplevel that are cut out
    of the available surface area by hardware elements present in the
    physical display. This allows clients to avoid placing user interface
    elements in those areas.
    Typical cutout areas are notches (i.e. embedding a camera) or
    "waterfall" display edges. In the case of a notch the compositor
    would usually supply the bounding box of the notch or an
    approximation by multiple rectangles. Thus a single physical
    element in the display can correspond to multiple cutout events in
    the protocol.
    The protocol currently supports xdg_toplevel surfaces but is meant
    to be extended to other surfaces (like layer surfaces) in the
    future.
    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 can only be done by
    creating a new major version of the extension.
  </description>
  <interface name="xx_cutouts_manager_v1" version="1">
    <description summary="Display cutouts area manager">
      This interface allows a compositor to announce support for
      supplying cutout information to the client.
    </description>
    <enum name="error">
      <entry name="invalid_role" value="0" summary="given wl_surface has incorrect role"/>
      <entry name="defunct_cutouts_object" value="1"
             summary="wl_surface or surface role was destroyed before the cutouts object"/>
    </enum>
    <request name="destroy" type="destructor">
      <description summary="destroy the xx_cutouts_manager object">
        Using this request a client can tell the server that it is not
        going to use the xx_cutouts_manger object anymore.
        Any objects already created through this instance are not affected.
      </description>
    </request>
    <request name="get_cutouts">
      <description summary="create a cutout notifier from a xdg toplevel">
        This creates a new xx_cutouts object for the given
        surface. The role of the surface must be xdg_toplevel
        otherwise an invalid_role protocol error will be raised. Later
        versions of this protocol might allow for other surface roles.
      </description>
      <arg name="id" type="new_id" interface="xx_cutouts_v1"/>
      <arg name="surface" type="object" interface="wl_surface"/>
    </request>
  </interface>
  <interface name="xx_cutouts_v1" version="1">
    <description summary="cutout regions information">
      An xx_cutouts describes the areas currently "cut out" of a
      toplevel.
      Each cutout event carries an id that identifies the
      physical element. If the compositor describes an element by
      multiple cutout events these should use the same element
      id. A typical example is a curved notch that is approximated
      by several cutout_box elements. Using the same element
      id allows the client to identify that these belong to the
      same physical object. Ids are only valid during one configure
      sequence. No guarantee is given that the same id identifies
      the same element in different configure sequences.
      Typically compositors would only send cutout information when
      the toplevel enters fullscreen or maxmized state (as specified
      in the xdg_shell protocol).
      The xx_cutouts_v1 object must be destroyed before its
      underlying xdg_toplevel and wl_surface. Otherwise the
      defunct_cutouts_object protocol error will be send.
    </description>
    <enum name="type">
      <description summary="Cutout type">
        These values indicate the type of cutout. The information is
        meant to help clients to decide whether they can possibly
        ignore the element.
      </description>
      <entry name="cutout" value="0">
        <description summary="A generic cutout">
          This element type can be used by the compositor if it
          doesn't want to provide a more specific type.
        </description>
      </entry>
      <entry name="notch" value="1">
        <description summary="Small functional cutout area">
          A functional, irregular shape on one of the device's
          edges. It often contains a camera.
        </description>
      </entry>
      <entry name="waterfall" value="2">
        <description summary="A curved display edge">
          A curved display edge intended to make the device appear
          like not having any bezel.
        </description>
      </entry>
    </enum>
    <enum name="corner_position">
      <description summary="Corner position">
        The position of a corner on a surface
      </description>
      <entry name="top_left" value="0"/>
      <entry name="top_right" value="1"/>
      <entry name="bottom_right" value="2"/>
      <entry name="bottom_left" value="3"/>
    </enum>
    <enum name="error">
      <entry name="invalid_element_id" value="0"
             summary="Invalid element id in a set_unhandled request"/>
    </enum>
    <request name="destroy" type="destructor">
      <description summary="destroy the xx_cutouts object">
        Using this request a client can tell the server that it is not
        going to use the xx_cutouts object anymore.
      </description>
    </request>
    <event name="cutout_box">
      <description summary="A rectangular cutout region">
        The cutout_box event describes a rectangular cutout area in
        surface-local coordinates.
        This can be an approximation of e.g. a circular camera notch.
      </description>
      <arg name="x" type="int"
           summary="x coordinate of the box's top left corner"/>
      <arg name="y" type="int"
           summary="y coordinate of the box's top left corner"/>
      <arg name="width" type="int"/>
      <arg name="height" type="int"/>
      <arg name="type" type="uint" enum="type" summary="The type of cutout"/>
      <arg name="id" type="uint" summary="An identifier identifying the physical element"/>
    </event>
    <event name="cutout_corner">
      <description summary="A cutout corner">
        The cutout_corner event describes a rounded corner in
        surface-local coordinates. The area towards the screen edge is
        the cutout corner part.
      </description>
      <arg name="position" type="uint" enum="corner_position" summary="The position of the described corner"/>
      <arg name="radius" type="uint" summary="The corner's radius"/>
      <arg name="id" type="uint" summary="An identifier identifying the physical element"/>
    </event>
    <event name="configure">
      <description summary="notify cutout changes">
        The configure event marks the end of a configure sequence. A
        configure sequence is a set of zero or more cutout events and
        the final xx_cutout.configure event.
        In the case of a xdg_toplevel clients should arrange their
        surface for the new cutouts, and then send an
        xdg_surface.ack_configure request at some point before
        committing the new surface. See xdg_surface.configure and
        xdg_surface.ack_configure in the xdg_shell protocol for
        details.
        If the cutout sequence consists of only a configure event and
        contains no cutout or corner events this indicates that the
        surface isn't overlapping with any cutouts or corners.
        If the client receives multiple configure events before it can
        respond to one, it is free to discard all but the last event
        it received.
      </description>
    </event>
    <request name="set_unhandled">
      <description summary="Notify about unhandled cutouts">
        If a client doesn't handle one or more cutouts in the to be
        acked sequence, it can add their element's id to the
        unhandled array. The compositor might then try to reposition
        the surface in a way that avoids these elements in a future
        configure sequence.
        The request (if used) must be sent before acking the configure
        sequence. State set with this request is double-buffered. It
        will get applied on the next ack_configure and stay valid
        until the next configure event.
      </description>
      <arg name="unhandled" type="array" summary="array of unhandled element ids"/>
    </request>
  </interface>
 </protocol>
--- a/experimental/xx-fractional-scale/README
+++ b/experimental/xx-fractional-scale/README
@ -1,4 +0,0 @@
 xx fractional scale v2 protocol
 Maintainers:
 Xaver Hugl <xaver.hugl@kde.org> (@Zamundaaa)
--- a/experimental/xx-fractional-scale/xx-fractional-scale-v2.xml
+++ b/experimental/xx-fractional-scale/xx-fractional-scale-v2.xml
@ -1,128 +0,0 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <protocol name="xx_fractional_scale_v2">
  <copyright>
    Copyright © 2022 Xaver Hugl
    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 fractional scaling">
    This protocol allows compositors and clients to communicate the
    coordinate space their surfaces act in.
  </description>
  <interface name="xx_fractional_scale_manager_v2" version="1">
    <description summary="creates surface scale interfaces">
      A global interface to create xx_fractional_scale_v2 interfaces.
    </description>
    <request name="destroy" type="destructor">
      <description summary="release the global">
        Informs the server that the client will not be using this protocol
        object anymore. This does not affect any other objects.
      </description>
    </request>
    <enum name="error">
      <entry name="fractional_scale_exists" value="0"
        summary="xx_fractional_scale_v2 for the surface already exists"/>
    </enum>
    <request name="get_fractional_scale">
      <description summary="create an interface to enable fractional scaling">
        Create an interface object for a wl_surface to communicate scale.
        If the given wl_surface already has a xx_fractional_scale_v2 object
        associated, the fractional_scale_exists protocol error is raised.
      </description>
      <arg name="id" type="new_id" interface="xx_fractional_scale_v2"
           summary="the new scale interface"/>
      <arg name="surface" type="object" interface="wl_surface"
           summary="the surface"/>
    </request>
  </interface>
  <interface name="xx_fractional_scale_v2" version="1">
    <description summary="interface for fractional scaling">
      An additional interface for a wl_surface object that allows compositor and
      client to communicate in a different coordinate space, in order to enable
      them to accurately describe coordinates and sizes in pixels.
      The two coordinate spaces in consideration are logical and pixels, where
      logical coordinates describe the size content should have and pixels
      describe the size of buffers.
      A scale of one equals a lack of scaling, where the communicated values
      define both logical coordinates and pixels.
      A scale greater than one describes that for every logical coordinate,
      more than one pixel is used, and a scale less than one describes that
      multiple logical coordinates make up one pixel.
      In mathematical terms, logical coordinates can be obtained by dividing
      the provided values by the currently active scale.
      The initial compositor and client coordinate scale factors are 1.
    </description>
    <event name="scale_factor">
      <description summary="set the compositor coordinate space scale factor">
        This event sets a scale factor for the associated wl_surface that
        describes the coordinate system the compositor will use for events
        following xx_fractional_scale_v2.scale_factor.
        The scale factor is encoded in a 8.24 fixed point format.
        The compositor must not send a scale of zero.
        The client should re-render and commit a new buffer with the new scale
        as soon as possible, in order to avoid artifacts caused by the mismatch
        in compositor and client scales.
      </description>
      <arg name="scale_8_24" type="uint" summary="surface scale factor"/>
    </event>
    <request name="set_scale_factor">
      <description summary="set the client coordinate space scale factor">
        This request sets a scale factor for the associated wl_surface that
        describes the coordinate system the client uses for requests following
        xx_fractional_scale_v2.set_scale_factor.
        The scale factor is encoded in a 8.24 fixed point format.
        If this scale factor does not match the scale factor provided by the
        compositor with xx_fractional_scale_v2.scale_factor, the compositor may
        apply transformations to the wl_surface that can result in blurriness
        or other artifacts.
        If scale_8_24 is zero, the error invalid_scale will be raised.
      </description>
      <arg name="scale_8_24" type="uint" summary="surface scale factor"/>
    </request>
    <request name="destroy" type="destructor">
      <description summary="remove the scale interface from the surface">
        The wl_surface's xx_fractional_scale_v2 object is destroyed, and the
        associated scale is reset to 1.
      </description>
    </request>
    <enum name="error">
      <entry name="invalid_scale" value="0"
        summary="scale value is not valid"/>
    </enum>
  </interface>
 </protocol>
--- a/experimental/xx-input-method/xx-input-method-v2.xml
+++ b/experimental/xx-input-method/xx-input-method-v2.xml
@ -47,7 +47,7 @@
    mechanism is discouraged.
  </description>
-  <interface name="xx_input_method_v1" version="4">
+  <interface name="xx_input_method_v1" version="2">
    <description summary="input method">
      An input method object allows for clients to compose text.
@ -168,7 +168,7 @@
        The initial value of cause is input_method.
      </description>
-      <arg name="cause" type="uint" enum="xx_text_input_v3.change_cause"/>
+      <arg name="cause" type="uint" enum="zwp_text_input_v3.change_cause"/>
    </event>
    <event name="content_type">
@ -183,70 +183,8 @@
        The initial value for hint is none, and the initial value for purpose
        is normal.
      </description>
-      <arg name="hint" type="uint" enum="xx_text_input_v3.content_hint"/>
+      <arg name="hint" type="uint" enum="zwp_text_input_v3.content_hint"/>
-      <arg name="purpose" type="uint" enum="xx_text_input_v3.content_purpose"/>
+      <arg name="purpose" type="uint" enum="zwp_text_input_v3.content_purpose"/>
    </event>
    <event name="set_available_actions" since="3">
      <description summary="announce the available actions">
        Announces the actions available for the currently active text input.
        Values set with this event are double-buffered. They will get applied
        on the next .done event.
        They get reset to the initial value on the next committed deactivate event.
        The initial value is an empty set: no actions are available.
        Values in the available_actions array come from text-input-v3.action.
      </description>
      <arg name="available_actions" type="array" summary="available actions"/>
    </event>
    <event name="announce_supported_features" since="3">
      <description summary="announce extra supported features">
        Notifies the input method what the currently active text input client is able to do.
        This event should come within the same .done sequence as .activate. Otherwise, the input method may ignore it.
        Values set with this event are double-buffered. They will get applied
        on the next .done event.
        They get reset to initial on the next committed deactivate event.
        The initial value for features is none.
      </description>
      <arg name="features" type="uint" enum="xx_text_input_v3.supported_features"/>
    </event>
    <enum name="protocol_compat" since="4">
      <description summary="protocol compatibility value">
        Tells the input method client what kinds of events the text input client supports.
      </description>
      <entry name="text_input_v3" value="0x0" summary="zwp-text-input-v3 semantics"/>
      <entry name="xx_text_input" value="0x1">
        <description summary="xx-text-input semantics">
          Changes the meaning of serial compared to v3.
          The text input client now applies requested updates on a "best-effort" basis.
        </description>
      </entry>
      <!-- This doesn't need disambiguating. Both protocols are pdated in lockstep, and the compositor should implement both protocols to the current version. By the experimental protocols contract, every version bump is breaking compatibility. -->
    </enum>
    <event name="announce_protocol_compat" since="3">
      <description summary="set text input's compatibility level">
        Tells the input method client what kinds of events the text input client supports.
        <!-- While text input protocols and input method protocols are updated in lockstep, nobody knows what versions of either will end up on a user's computer. Old input method with new apps? New input method with old apps?
        To limit the scope for now, let's assume the user always keeps the input method up to date, and uses old apps. -->
        Values set with this event are double-buffered. They will get applied
        on the next .done event.
        They get reset to initial on the next committed deactivate event.
        The compositor may send this event as part of a .done chain that switches the active state from inactive to active. It must not send this event otherwise.
        The initial value for version is text_input_v3.
      </description>
      <arg name="compat_level" type="uint" enum="protocol_compat"/>
    </event>
    <event name="done">
@ -271,18 +209,6 @@
      </description>
    </event>
    <request name="perform_action" since="3">
      <description summary="perform action">
        Perform an action on this text input.
        Values set with this event are double-buffered. They must be applied
        and reset to initial on the next commit request.
        The initial value of action is none.
      </description>
      <arg name="action" type="uint" enum="xx_text_input_v3.action" summary="action to perform"/>
    </request>
    <request name="commit_string">
      <description summary="commit string">
        Send the commit string text for insertion to the application.
@ -326,7 +252,7 @@
        Values set with this request are double-buffered. They must be applied on
        the next xx_input_method_v1.commit request.
-        They must be reset to initial on the next committed .deactivate event.
+        They must be reset to initial on the next committed disable event.
        The initial value of text is an empty string. The initial value of
        cursor_begin, and cursor_end are both 0.
@ -343,11 +269,6 @@
        before_length and after_length are the number of bytes before and after
        the current cursor index (excluding the preedit text) to delete.
        If text is selected, it must be deleted.
        If indices exceed the available text boundaries, they should be adjusted to fit in boundaries and deletion reattempted.
        If indices do not lie on byte boundaries, then the text input client should delete at least that many bytes. In this case, the client decides the end point, but a character boundary same as when deleting using the keyboard is recommended.
        If any preedit text is present, it is replaced with the cursor for the
        purpose of this event. In effect before_length is counted from the
        beginning of preedit text, and after_length from its end (see commit
@ -362,34 +283,6 @@
      <arg name="after_length" type="uint"/>
    </request>
    <request name="move_cursor" since="3">
      <description summary="move cursor and change selection">
        Unselects text, moves the cursor and selects text.
        This is equivalent to dragging the mouse over some text: it deselects whatever might be currently selected and selects a new range of text.
        The offsets used in arguments are in bytes relative to the current cursor position. Cursor is the new position of the cursor, and anchor is the opposite end of selection. If there's no selection, anchor should be equal to cursor.
        The offsets do not take preedit contents into account, nor is preedit changed in any way with this request.
        Both cursor and anchor must fall on code point boundaries, otherwise text input client may ignore the request. It is therefore not recommended for an input method to move any of them beyond the text received in surrounding_text.
        When surrounding_text is not supported, the offsets must not be interpreted as bytes, but as some human-readable unit at least as big as a code point, for example a grapheme.
        The cursor and anchor arguments can also take the following special values:
        BEGINNING := 0x8000_0000 = i32::MIN
        END := 0x7fff_ffff = i32::MAX
        meaning, respectively, the beginning and the end of of all text in the input field.
        Values set with this event are double-buffered. They must be applied
        and reset to initial on the next commit request.
        The initial values of both cursor and anchor are 0.
      </description>
      <arg name="cursor" type="int"/>
      <arg name="anchor" type="int"/>
    </request>
    <request name="commit">
      <description summary="apply state">
        Apply state changes from commit_string, set_preedit_string and
@ -405,19 +298,9 @@
        1. Replace existing preedit string with the cursor.
        2. Delete requested surrounding text.
        3. Insert commit string with the cursor at its end.
-        4. Move the cursor and selection.
+        4. Calculate surrounding text to send.
-        5. Calculate surrounding text to send.
+        5. Insert new preedit text in cursor position.
-        6. Insert new preedit text in cursor position.
+        6. Place cursor inside preedit text.
        7. Place cursor inside preedit text.
        8. Perform the requested action.
        Note that the input method can not receive more than 4000 bytes of selection text, which might be the case for example when the entire document is selected. Nevertheless, the text input must delete the entire selected range before inserting the commit string.
        Serial handling with protocol_compat == xx_text_input
        The serial number should be set to 0.
        Serial handling with protocol_compat == text_input_v3
        The serial number reflects the last state of the xx_input_method_v1
        object known to the client. The value of the serial argument must be
@ -454,7 +337,7 @@
        the time of its creation.
        The compositor must issue this request when the object is no longer
-        usable, e.g. due to seat removal.
+        useable, e.g. due to seat removal.
        The input method context becomes inert and should be destroyed after
        deactivation is handled. Any further requests and events except for the
@ -508,7 +391,7 @@
      A typical sequence resulting from the user selecting a new text field and typing some text:
-      1. compositor (Co): input_method.activate()
+      1. compositor (Co): input_method.enable()
      2. Co: input_method.done()
      3. [init sequence]
      4. Co: input_method.set_surrounding_text("new text")
@ -517,7 +400,7 @@
      7. client (Cl): ack_configure()
      8. Cl: wl_surface.commit()
-      When the corresponding input_method receives a committed .deactivate event, the popup gets destroyed and becomes invalid and its surface gets unmapped.
+      When the corresponding input_method receives a commited .disable event, the popup gets destroyed and becomes invalid and its surface gets unmapped.
      The client must not destroy the underlying wl_surface while the
      xx_input_popup_surface_v2 object exists.
@ -566,7 +449,7 @@
        2. Complicate some and mandate .done after some .configures
-        Rejected because the different path for syncing (on .configure or on .done) are difficult to explain and sound like a source of bugs. Also, this ended up needing additional events.
+        Rejected because the different path for syncing (on .confgure or on .done) are difficult to explain and sound like a source of bugs. Also, this ended up needing additional events.
        3. Simplify a lot and remove .configure in favor of relying on .done entirely
@ -591,7 +474,7 @@
        This request notifies the compositor that the client updated its surface in response to a configure sequence.
        The purpose of this request is to synchronize the updates of the surface geometry with the surface contents.
-        For example, when the compositor assigns a size larger than previously, the client must fill the additional space before the popup gets displayed to the user with the new size. When the compositor receives .ack_configure, it can proceed to draw the new size.
+        For example, when the compositor assigns a size larger than prevously, the client must fill the additional space before the popup gets displayed to the user with the new size. When the compositor receives .ack_configure, it can proceed to draw the new size.
        .ack_configure should be sent after every submitted configure sequence, passing along the serial received in it.
@ -720,7 +603,7 @@
    </request>
    <enum name="anchor">
-      <entry name="none" value="0" summary="no edge, specifies center"/>
+      <entry name="none" value="0" summary="no edge, specfies center"/>
      <entry name="top" value="1"/>
      <entry name="bottom" value="2"/>
      <entry name="left" value="3"/>
@ -910,7 +793,7 @@
    </request>
  </interface>
-  <interface name="xx_input_method_manager_v2" version="4">
+  <interface name="xx_input_method_manager_v2" version="2">
    <description summary="input method manager">
      The input method manager allows the client to become the input method on
      a chosen seat.
--- a/experimental/xx-keyboard-filter/README
+++ b/experimental/xx-keyboard-filter/README
@ -1,4 +0,0 @@
 Keyboard filter protocol
 Maintainers:
 Dorota Czaplejewicz <gilaac.dcz@porcupinefactory.org>
--- a/experimental/xx-keyboard-filter/xx-keyboard-filter-v1.xml
+++ b/experimental/xx-keyboard-filter/xx-keyboard-filter-v1.xml
@ -1,178 +0,0 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <protocol name="keyboard_filter_experimental_v1">
  <copyright>
    Copyright 2018 Mike Blumenkrantz
    Copyright 2018 Samsung Electronics Co., Ltd
    Copyright 2018 Red Hat Inc.
    Copyright 2025 DorotaC
    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="filter and intercept keyboard events">
    The keyboard_filter protocol allows a client to intercept selected keyboard events and prevent them from reaching the focused surface.
    This protocol offers a way to alter events reaching an application without the need to allow generating arbitrary keyboard events.
    High-level overview of the interfaces:
    The keyboard_filter_manager exposes the bind_to_input_method request which binds a wl_keyboard to an xx_input_method.
    The resulting keyboard_filter object has the can be then used for intercepting keyboard events in accordance to input method needs.
    This document adheres to the RFC 2119 when using words like "must",
    "should", "may", etc.
    Warning! The protocol described in this file is currently in the
    experimental phase. Backwards incompatible major versions of the
    protocol are to be expected. Exposing this protocol without an opt-in
    mechanism is discouraged.
  </description>
  <interface name="xx_keyboard_filter_v1" version="1">
    <description summary="keyboard event filtering functionality">
      Manages the filtering of key presses.
    </description>
    <enum name="error">
      <entry name="invalid_serial" value="0x1" summary="compositor received serial not adhering to requirements"/>
    </enum>
    <request name="unbind">
      <description summary="Stop intercepting">
        Unbind the keyboard and stop intercepting events.
        Unbinds the bound keyboard and the input method. the compositor must stop redirecting keyboard events. Events that the keyboard_filter client has not yet responded to are treated as if they received the "passthrough" action.
        This request takes effect immediately.
      </description>
    </request>
    <enum name="filter_action">
      <entry name="consume" value="0" summary="consume the key event"/>
      <entry name="passthrough" value="1" summary="pass the key event to the text input client"/>
    </enum>
    <request name="filter">
      <description summary="decide the processing of a keyboard event">
        This request controls the filtering of keyboard input events before reaching the focused surface.
        Usage:
        While keyboard_filter is intercepting, the compositor must send every intercepted event to its bound wl_keyboard, and hold a copy of it in an internal queue.
        When the client responds with the .filter request, the compositor either removes the event from the queue (filter_action.consume), or sends the copy to the original wl_keyboard objects (filter_action.passthrough).
        The compositor must process .filter the oldest event in the queue before processing more recent ones.
        For this reason, the client sets the argument "serial" to the serial of the corresponding event it received.
        Exceptions:
        If the event is other than wl_keyboard.key or contains no serial, it cannot be filtered. The keyboard_filter client must not respond to it with .filter request. When such an event is oldest in the queue, the compositor must proceed as if the event had received a "passthrough" reply.
        As of wl_keyboard v10 and keyboard_filter_v1, the only event that can be filtered is the wl_keyboard.key event.
        Sequence:
        The wl_keyboard begins to receive events after input_method.activate is committed.
        The valid serial is the serial of the oldest wl_keyboard event which has been sent after input_method.activate but which hasn't yet received a .filter confirmation.
        The compositor may raise the invalid_serial error in response to events with serials it had not issued.
        The compositor must ignore events with all other serials. (Particularly, this means events with repeating serials are accepted normally and are not ignored).
        Events must be filtered in order of arrival.
      </description>
      <arg name="serial" type="uint"/>
      <arg name="action" type="uint" enum="filter_action"/>
    </request>
    <request name="destroy" type="destructor">
      <description summary="destroy the keyboard">
        Destroys the keyboard_filter object, stops event interception, and unbinds the wl_keyboard and input_method objects bound to it.
      </description>
    </request>
  </interface>
  <interface name="xx_keyboard_filter_manager_v1" version="1">    
    <enum name="error">
      <entry name="already_bound" value="0x1" summary="an argument is already bound"/>
      <entry name="wrong_seat" value="0x2" summary="the keyboard i attached to the wrong seat for this operation"/>
    </enum>
    <request name="bind_to_input_method">
      <description summary="Bind a keyboard to an input method">
        Bind a keyboard to an input method for the purpose of capturing key presses before they reach the text input client.
        When a wl_keyboard is bound, the compositor must redirect to it the input events intended for the focused surface with text input enabled. The wl_keyboard instance receives no other events from then on.
        See keyboard_filter.filter.
        For the bound wl_keyboard instance to intercept events, the following conditions must be fulfilled:
        - there's a focused surface,
        - the surface has an enabled text input object,
        - the bound input method is active (for the meaning of "active", see input_method.activate, input_method.deactivate).
        When those conditions are fulfilled, the compositor must start redirecting input events intended for the text input surface to the wl_keyboard bound with this request. Otherwise, the text input surface receives events without intercepting them.
        Be aware that the text input client might use a wl_keyboard object(s) of different version(s) than the one used by the input method. The compositor should issue events as it would normally do for the versions in question. This protocol assumes that events to multiple keyboards of different protocol versions are equivalent.
        Background:
        Whenever the input method is activated, the compositor must start sending it keyboard events intended for the text-input client, so that the input method can be controlled using a keyboard.
        Traditionally, from the user perspective, input methods receive keys as if they were an overlay: keys which are interesting to the input method gain a special input method meaning, all others work as usual.
        The binding and the keyboard_filter.filter request together make this possible by letting the input method indicate which events it is interested in.
        Conceptually, when a wl_keyboard is bound to an input_method, the compositor prevents all keyboard events directed to the text input client from reaching it. They are delayed until the input method decides how to filter them using the keyboard_filter.filter request.
        Arguments:
        The wl_keyboard must not be already bound to another interface.
        The wl_keyboard must only receive events between committed .activate and .deactivate.
        The surface argument represents an arbitrary wl_surface. When issuing wl_keyboard.enter and wl_keyboard.leave on the bound wl_keyboard, the compositor must replace the original surface argument with the one provided by the input method in this request.
        Because the wl_keyboard.enter and wl_keyboard.leave events require a surface as the target, one must be provided even if the input method doesn't display one. A dummy one is sufficient. The provided wl_surface will not be used for any other purpose than explained above.
        The surface must outlive the input method.
        NOTE: This feature works much better with compositor-side key repeat introduced in wl_seat version 10. This protocol doesn't provide controls for filtering repeat key events generated client-side.
        A compositor implementing this protocol should implement compositor-side key repeat.
        This request takes effect immediately.
        Attempting to bind a keyboard to an input method which is already bound must cause the already_bound error.
        Attempting to bind a keyboard object which was already bound must cause the already_bound error.
        Attempting to bind a keyboard object to an input method acting on a different seat must cause the wrong_seat error.
        Once any of the bound objects are destroyed, the xx_keyboard_filter_v1 instance becomes disabled and it must ignore all following requests.
        When the input method gets destroyed, the compositor must stop issuing events to the keyboard and ignore any further requests to keyboard_filter, except keyboard_filter.destroy.
      </description>
      <arg name="keyboard" type="object" interface="wl_keyboard" />
      <arg name="input_method" type="object" interface="xx_input_method_v1" />
      <arg name="surface" type="object" interface="wl_surface" />
      <arg name="extensions" type="new_id" interface="xx_keyboard_filter_v1"/>
    </request>
    <request name="destroy" type="destructor">
      <description summary="destroy the input method manager">
        Destroys the xx_keyboard_filter_manager_v1 object.
        The xx_keyboard_filter_v1 objects originating from it remain unaffected.
      </description>
    </request>
  </interface>
 </protocol>
--- a/experimental/xx-session-management/xx-session-management-v1.xml
+++ b/experimental/xx-session-management/xx-session-management-v1.xml
@ -84,12 +84,12 @@
      </entry>
      <entry name="recover" value="2">
        <description summary="an app recovered">
-          An app instance is recovering from for example a compositor or app crash.
+          A app instance is recovering from for example a compositor or app crash.
        </description>
      </entry>
      <entry name="session_restore" value="3">
        <description summary="an app restored">
-          An app instance is restored, for example part of a restored session, or
+          A app instance is restored, for example part of a restored session, or
          restored from having been temporarily terminated due to resource
          constraints.
        </description>
--- a/experimental/xx-text-input/xx-text-input-v3.xml
+++ b/experimental/xx-text-input/xx-text-input-v3.xml
@ -6,7 +6,6 @@
    Copyright © 2015, 2016 Jan Arne Petersen
    Copyright © 2017, 2018 Red Hat, Inc.
    Copyright © 2018       Purism SPC
    Copyright © 2025       DorotaC
    Permission to use, copy, modify, distribute, and sell this
    software and its documentation for any purpose is hereby granted
@ -48,7 +47,7 @@
    interface version number is reset.
  </description>
-  <interface name="xx_text_input_v3" version="3">
+  <interface name="xx_text_input_v3" version="1">
    <description summary="text input">
      The xx_text_input_v3 interface represents text input and input methods
      associated with a seat. It provides enter/leave events to follow the
@ -104,8 +103,7 @@
        This request resets all state associated with previous enable, disable,
        set_surrounding_text, set_text_change_cause, set_content_type, and
        set_cursor_rectangle requests, as well as the state associated with
-        preedit_string, commit_string, delete_surrounding_text, and action
+        preedit_string, commit_string, and delete_surrounding_text events.
        events.
        The set_surrounding_text, set_content_type and set_cursor_rectangle
        requests must follow if the text input supports the necessary
@ -390,11 +388,6 @@
        Before_length and after_length are the number of bytes before and after
        the current cursor index (excluding the selection) to delete.
        If text is selected, it must be deleted.
        If indices exceed the available text boundaries, they should be adjusted to fit in boundaries and deletion reattempted.
        If indices do not lie on byte boundaries, then the text input client should delete at least that many bytes. In this case, the client decides the end point, but a character boundary same as when deleting using the keyboard is recommended.
        If a preedit text is present, in effect before_length is counted from
        the beginning of it, and after_length from its end (see done event
        sequence).
@ -408,49 +401,11 @@
      <arg name="after_length" type="uint" summary="length of text after current cursor position"/>
    </event>
    <event name="move_cursor" since="2">
      <description summary="move cursor and change selection">
        Unselects text, moves the cursor and selects text.
        This is equivalent to dragging the mouse over some text: it deselects whatever might be currently selected and selects a new range of text.
        The offsets used in arguments are in bytes relative to the current cursor position. Cursor is the new position of the cursor, and anchor is the opposite end of selection. If there's no selection, anchor should be equal to cursor.
        In terms of dragging the mouse, the anchor is the start, and cursor the end.
        The offsets do not take preedit contents into account, nor is preedit changed in any way with this request.
        Both cursor and anchor must fall on code point boundaries, otherwise text input client may ignore the request. It is therefore not recommended for an input method to move any of them beyond the text received in surrounding_text.
        <!-- Code point boundary checking must happen in the application because no one else is obliged to track the contents.
        There are two ways to handle it:
        1. add a request from the application informing the compositor of the mistake, so that the compositor can send an error and crash the input method, giving it the chance to reset and go back to normal
        2. just ignore the request and hope the input method can resynchronize through surrounding_text
        Choosing 2. because it's easier to implement.
        -->
        When surrounding_text is not supported, the offsets must not be interpreted as bytes, but as some human-readable unit at least as big as a code point, for example a grapheme.
        The cursor and anchor arguments can also take the following special values:
        BEGINNING := 0x8000_0000 = i32::MIN
        END := 0x7fff_ffff = i32::MAX
        meaning, respectively, the beginning and the end of of all text in the input field.
        Values set with this event are double-buffered. They must be applied
        and reset to initial on the next commit request.
        The initial values of both cursor and anchor are 0.
      </description>
      <arg name="cursor" type="int"/>
      <arg name="anchor" type="int"/>
    </event>
    <event name="done">
      <description summary="apply changes">
        Instruct the application to apply changes to state requested by the
-        preedit_string, commit_string delete_surrounding_text, and action
+        preedit_string, commit_string and delete_surrounding_text events. The
-        events.
+        state relating to these events is double-buffered, and each one
        The state relating to these events is double-buffered, and each one
        modifies the pending state. This event replaces the current state with
        the pending state.
@ -460,17 +415,9 @@
        1. Replace existing preedit string with the cursor.
        2. Delete requested surrounding text.
        3. Insert commit string with the cursor at its end.
-        4. Move the cursor and selection.
+        4. Calculate surrounding text to send.
-        5. Calculate surrounding text to send.
+        5. Insert new preedit text in cursor position.
-        6. Insert new preedit text in cursor position.
+        6. Place cursor inside preedit text.
        7. Place cursor inside preedit text.
        8. Perform the requested action.
        Serial handling starting version 2:
        The argument "serial" is ignored.
        Serial handling version 1:
        The serial number reflects the last state of the xx_text_input_v3
        object known to the compositor. The value of the serial argument must
@ -486,91 +433,9 @@
      </description>
      <arg name="serial" type="uint"/>
    </event>
    <enum name="action" since="2">
      <description summary="action">
        A possible action to perform on a text input.
      </description>
      <entry name="none" value="1">
        <description summary="no action">
          This enum value exists only to provide a default to make double-buffering implementation easier. It should not be used explicitly.
        </description>
      </entry>
      <!-- Notably missing: moving cursor, deleting and setting a selection. They are nicer to use as part of the text manipulation interface: ranges can be selected there.
      Exceptions: the IME doesn't know where lines start or end. The IME will not get to see the entire 4MB document so it can't select all through the text interface. But this doesn't seem urgent. -->
      <!-- types of finish actions are better communicated as a hint: this triggers a URL navigation, this sends a search query, this sends a message, etc. The input method can then choose the appropriate buttons to display -->
      <entry name="finish" value="0">
        <description summary="trigger appropriate action for the completion of editing">
          This should be triggered when the user is done with editing the field and wants to move on. For example, the query was typed and the user wants the search result. Or the name was entered and the address needs to be typed next.
          The action to perform depends on the application, and should match the value of the current content_purpose.
          All clients SHOULD implement this action. Without it, on-screen keyboards don't work as expected.
        </description>
      </entry>
    </enum>
    <event name="perform_action" since="2">
      <description summary="action performed">
        The input method issued an action to perform on this text input.
        Values set with this event are double-buffered. They must be applied
        and reset to initial on the next .done event.
        The initial value of action is none.
      </description>
      <arg name="action" type="uint" enum="action" summary="action performed"/>
    </event>
    <request name="set_available_actions" since="2">
      <description summary="announce the available actions">
        Announces the actions available for the currently active text input.
        Values set with this event are double-buffered. They will get applied
        on the next .done event.
        They get reset to the initial value on the next committed deactivate event.
        The initial value is an empty set: no actions are available.
        Values in the available_actions array come from text-input-v3.action.
      </description>
      <!-- Removed the protocol error on none and duplicates because a client has no interest in crashing for slight compositor misbehaviour. Ignoring extraneous values should not be a problem for any half-competent library. -->
      <arg name="available_actions" type="array" summary="available actions"/>
      <!-- Should this be a bitmap instead of an array? 32 generic actions should be enough, and client-specific actions would need a new protocol anyway -->
    </request>
    <enum name="supported_features" bitfield="true" since="2">
      <description summary="possible supported features">
        Client functionality over the baseline that isn't indicated implicitly.
        This does not include events coming with .enable: when the input method receives such an event, it is clear the text input supports it, e.g. content_type, available_actions.
        Baseline functionality like commit_string, set_preedit_string must always be supported for the protocol to be useful.
        The flags match text-input protocol versions, but should be kept general enough to support other protocols.
      </description>
      <entry name="none" value="0x0" summary="no extra functionality supported"/>
      <entry name="move_cursor" value="0x1" summary="the move_cursor request"/>
    </enum>
    <request name="announce_supported_features" since="2">
      <description summary="announce extra supported features">
        Notifies the input method what the currently active text input client is able to do.
        This event should come within the same .done sequence as .activate. Otherwise, the input method may ignore it.
        Values set with this event are double-buffered. They will get applied
        on the next .done event.
        They get reset to initial on the next committed deactivate event.
        The initial value for features is none.
      </description>
      <arg name="features" type="uint" enum="xx_text_input_v3.supported_features"/>
    </request>
  </interface>
-  <interface name="xx_text_input_manager_v3" version="3">
+  <interface name="xx_text_input_manager_v3" version="1">
    <description summary="text input manager">
      A factory for text-input objects. This object is a global singleton.
    </description>
--- a/experimental/xx-zones/README
+++ b/experimental/xx-zones/README
@ -1,4 +0,0 @@
 Zones protocol
 Maintainers:
 Matthias Klumpp <matthias@tenstral.net> (@mak)
--- a/experimental/xx-zones/xx-zones-v1.xml
+++ b/experimental/xx-zones/xx-zones-v1.xml
@ -1,493 +0,0 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <protocol name="xx_zones_v1">
  <copyright>
    Copyright © 2023-2026 Matthias Klumpp
    Copyright © 2024-2025 Frank Praznik
    Copyright ©      2024 Victoria Brekenfeld
    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 to manage client-specific zones for explicit window placement">
    This protocol provides a way for clients to create and add toplevel windows
    to "zones".
    A zone is an environment with its own coordinate space where clients can
    add and arrange windows that logically belong and relate to each other.
    It provides means for, among other things, requesting that windows are
    placed at specific coordinates within the zone coordinate space.
    See the description of "xx_zone_v1" for more details.
    This document adheres to RFC 2119 when using words like "must",
    "should", "may", etc.
    Warning! The protocol described in this file is currently in the testing
    phase. Backward compatible changes may be added together with the
    corresponding interface version bump. Backward incompatible changes can
    only be done by creating a new major version of the extension.
  </description>
  <interface name="xx_zone_manager_v1" version="1">
    <description summary="manage zones for clients">
      The 'xx_zone_manager' interface defines base requests for obtaining and
      managing zones for a client.
    </description>
    <request name="destroy" type="destructor">
      <description summary="Destroy this object">
       This has no effect other than to destroy the xx_zone_manager object.
      </description>
    </request>
    <request name="get_zone_item">
      <description summary="create a positionable item representing a toplevel">
        Create a new positionable zone item from an 'xdg_toplevel'.
        The resulting wrapper object can then be used to position the
        toplevel window in a zone.
      </description>
      <arg name="id" type="new_id" interface="xx_zone_item_v1"/>
      <arg name="toplevel" type="object" interface="xdg_toplevel" summary="the toplevel window"/>
    </request>
    <request name="get_zone">
      <description summary="join a zone or request a new one">
        Create a new zone. While the zone object exists, the compositor
        must consider it "used" and keep track of it.
        A zone is represented by a string 'handle'.
        The compositor must keep zone handles valid while any client is
        referencing the corresponding zone.
        The compositor may always give a client the same zone for a given
        output, and remember its position and size for the client, but
        clients should not rely on this behavior.
        A client can request a zone to be placed on a specific
        output by passing a wl_output as 'output'. If a valid output
        is set, the compositor should place the zone on that output.
        If NULL is passed, the compositor decides the output.
        The compositor should provide the biggest reasonable zone space
        for the client, governed by its own policy.
        If the compositor wants to deny zone creation (e.g. on a specific
        output), the returned zone must be "invalid". A zone is invalid
        if it has a negative size, in which case the client is forbidden
        to place items in it.
      </description>
      <arg name="id" type="new_id" interface="xx_zone_v1"/>
      <arg name="output" type="object" interface="wl_output"
           summary="the preferred output to place the zone on, or NULL"
           allow-null="true"/>
    </request>
    <request name="get_zone_from_handle">
      <description summary="join a zone via its handle">
        Create a new zone object using the zone's handle.
        For the returned zone, the same rules as described in
        'get_zone' apply.
        This request returns a reference to an existing or remembered zone
        that is represented by 'handle'.
        The zone may potentially have been created by a different client.
        This allows cooperating clients to share the same coordinate space.
        If the zone handle was invalid or unknown, a new zone must
        be created and returned instead, following the rules outlined
        in 'get_zone' and assuming no output preference.
        Every new zone object created by this request emits its initial event
        sequence, including the 'handle' event, which must return a different
        handle from the one passed to this request in case the existing zone
        could not be joined.
      </description>
      <arg name="id" type="new_id" interface="xx_zone_v1"/>
      <arg name="handle" type="string" summary="the handle of a zone"/>
    </request>
  </interface>
  <interface name="xx_zone_item_v1" version="1">
    <description summary="opaque surface object that can be positioned in a zone">
      The zone item object is an opaque descriptor for a positionable
      element, such as a toplevel window.
      It currently can only be created from an 'xdg_toplevel' via the
      'get_zone_item' request on a 'xx_zone_manager'.
      The lifetime of a zone item is tied to its referenced item (usually
      a toplevel).
      When the reference is destroyed, the compositor must send a 'closed'
      event and the zone item becomes inert.
    </description>
    <request name="destroy" type="destructor">
      <description summary="delete this object">
        Destroys the zone item. This request may be sent at any time by the
        client.
        By destroying the object, the respective item surface remains at its
        last position, but its association with its zone is lost.
        This will also cause it to lose any other attached state described by
        this protocol.
        If the item was associated with a zone when this request is sent,
        the compositor must emit 'item_left' on the respective zone, unless
        it had already been emitted before a 'closed' event.
      </description>
    </request>
    <event name="frame_extents">
      <description summary="the extents of the frame bordering the item">
        The 'frame_extents' event describes the current extents of the frame
        bordering the item's content area.
        This event is sent immediately after the item joins a zone, or if
        the item frame extents have been changed by other means (e.g. toggled
        by a client request, or compositor involvement). The dimensions are in
        the same coordinate space as the item's zone (the surface coordinate
        space).
        This event must be followed by a 'position' event, even if the item's
        coordinates did not change as a result of the frame extents changing.
        If the item has no associated frame, the event should still be sent,
        but extents must be set to zero.
        This event can only be emitted if the item is currently associated
        with a zone.
      </description>
      <arg name="top" type="int" summary="current height of the frame bordering the top of the item"/>
      <arg name="bottom" type="int" summary="current height of the frame bordering the bottom of the item"/>
      <arg name="left" type="int" summary="current width of the frame bordering the left of the item"/>
      <arg name="right" type="int" summary="current width of the frame bordering the right of the item"/>
    </event>
    <request name="set_position">
      <description summary="set a preferred item surface position">
        Request a preferred position (x, y) for the specified item
        surface to be placed at, relative to its associated zone.
        This state is double-buffered and is applied on the next
        wl_surface.commit of the surface represented by 'item'.
        X and Y coordinates are relative to the zone this item is associated
        with, and must not be larger than the dimensions set by the zone size.
        They may be smaller than zero, if the item's top-left edge is to be
        placed beyond the zone's top-left sides, but clients should expect the
        compositor to more aggressively sanitize the coordinate values in that
        case.
        If a coordinate exceeds the zone's maximum bounds, the compositor must
        sanitize it to more appropriate values (e.g. by clamping the values to
        the maximum size).
        For infinite zones, the client may pick any coordinate.
        Compositors implementing this protocol should try to place an item
        at the requested coordinates relative to the item's zone, unless doing
        so is not allowed by compositor policy (because e.g. the user has set
        custom rules for the surface represented by the respective item, the
        surface overlaps with a protected shell component, session management
        has loaded previous surface positions or the placement request would
        send the item out of bounds).
        Clients should be aware that their placement preferences might not
        always be followed and must be prepared to handle the case where the
        item is placed at a different position by the compositor.
        Once an item has been mapped, a change to its preferred placement can
        still be requested and should be applied, but must not be followed
        by the compositor while the user is interacting with the affected item
        surface (e.g. clicking &amp; dragging within the window, or resizing it).
        After a call to this request, a 'position' event must be emitted with the
        item's new actual position.
        If the current item has no zone associated with it, a 'position_failed'
        event must be emitted.
        If the compositor did not move the item at all, not even with sanitized
        values, a 'position_failed' event must be emitted as well.
      </description>
      <arg name="x" type="int" summary="x position relative to zone"/>
      <arg name="y" type="int" summary="y position relative to zone"/>
    </request>
    <event name="position">
      <description summary="notify about the position of an item">
        This event notifies the client of the current position (x, y) of
        the item relative to its zone.
        Coordinates are relative to the zone this item belongs to, and only
        valid within it.
        Negative coordinates are possible, if the user has moved an item
        surface beyond the zone's top-left boundary.
        This event is sent in response to a 'set_position' request,
        or if the item position has been changed by other means
        (e.g. user interaction or compositor involvement).
        This event can only be emitted if the item is currently associated
        with a zone.
      </description>
      <arg name="x" type="int" summary="current x position relative to zone"/>
      <arg name="y" type="int" summary="current y position relative to zone"/>
    </event>
    <event name="position_failed">
      <description summary="a set_position request has failed">
        The compositor was unable to set the position of this item entirely,
        and could not even find sanitized coordinates to place the item at
        instead.
        This event will also be emitted if 'set_position' was called while the
        item had no zone associated with it.
      </description>
    </event>
    <event name="closed">
      <description summary="the underlying surface has been destroyed">
        This event indicates that the surface wrapped by this
        zone item has been destroyed.
        The 'xx_zone_item_v1' object becomes inert and the client should
        destroy it. Any requests made on an inert zone item must be silently
        ignored by the compositor, and no further events will be sent for this
        item.
        If the item was associated with a zone when this event is sent,
        the compositor must also emit 'item_left' on the respective zone
        before sending this event.
      </description>
    </event>
  </interface>
  <interface name="xx_zone_v1" version="1">
    <description summary="area for a client in which it can set window positioning preferences">
      An 'xx_zone' describes a display area provided by the compositor in
      which a client can place windows and move them around.
      A zone's area could, for example, correspond to the space usable for
      placing windows on a specific output (space without panels or other
      restricted elements) or it could be an area of the output the compositor
      has specifically chosen for a client to place its surfaces in.
      Clients should make no assumptions about how a zone is presented to the
      user (e.g. compositors may visually distinguish what makes up a zone).
      Items are added to a zone as 'xx_zone_item' objects.
      All item surface position coordinates (x, y) are relative to the selected
      zone.
      They are using the 'size' of the respective zone as coordinate system,
      with (0, 0) being in the top left corner.
      If a zone item is moved out of the top/left boundaries of the zone by
      user interaction, its coordinates must become negative, relative to the
      zone's top-left coordinate origin. A client may position an item at negative
      coordinates.
      The compositor must ensure that any item positioned by the client is
      visible and accessible to the user, and is not moved into invisible space
      outside of a zone.
      Positioning requests may be rejected or altered by the compositor, depending
      on its policy.
      The absolute position of the zone within the compositor's coordinate space
      is opaque to the client and the compositor may move the entire zone without
      the client noticing it. A zone may also be arbitrarily resized, in which
      case the respective 'size' event must be emitted again to notify the client.
      A zone is always tied to an output and does not extend beyond it.
      A zone may be "invalid". An invalid zone is created with a negative
      'size' and must not be used for item arrangement.
      Upon creation the compositor must emit 'size' and 'handle' events for the
      newly created 'xx_zone', followed by 'done'.
    </description>
    <request name="destroy" type="destructor">
      <description summary="destroy the xx_zone object">
        Using this request a client can tell the compositor that it is not
        going to use the 'xx_zone' object anymore.
        The zone itself must only be destroyed if no other client
        is currently referencing it, so this request may only destroy the
        object reference owned by the client.
      </description>
    </request>
    <event name="size">
      <description summary="size of the zone">
        The 'size' event describes the size of this zone.
        It is a rectangle with its origin in the top-left corner, using
        the surface coordinate space (device pixels divided by the scaling
        factor of the output this zone is attached to).
        If a width or height value is zero, the zone is infinite
        in that direction.
        If the width and height values are negative, the zone is considered
        "invalid" and must not be used.
        A size event declaring the zone invalid may only be emitted immediately
        after the zone was created.
        A zone must not become invalid at a later time by sending a negative
        'size' after the zone has been established.
        The 'size' event is sent immediately after creating an 'xx_zone_v1',
        and whenever the size of the zone changes. A zone size can change at
        any time, for any reason, for example due to output size or scaling
        changes, or by compositor policy.
        Upon subsequent emissions of 'size' after 'xx_zone' has already
        been created, the 'done' event does not have to be sent again.
      </description>
      <arg name="width" type="int"
           summary="zone width in logical pixels"/>
      <arg name="height" type="int"
           summary="zone height in logical pixels"/>
    </event>
    <event name="handle">
      <description summary="the zone handle">
        The handle event provides the unique handle of this zone.
        The handle may be shared with any client, which then can use it to
        join this client's zone by calling
        'xx_zone_manager.get_zone_from_handle'.
        This event must only be emitted once after the zone was created.
        If this zone is invalid, the handle must be an empty string.
      </description>
      <arg name="handle" type="string" summary="the exported zone handle"/>
    </event>
    <event name="done">
      <description summary="all information about the zone has been sent">
        This event is sent after all other properties (size, handle) of an
        'xx_zone' have been sent.
        This allows changes to the xx_zone properties to be seen as
        atomic, even if they happen via multiple events.
      </description>
    </event>
    <enum name="error">
      <entry name="invalid" summary="an invalid value has been submitted"
             value="0"/>
    </enum>
    <request name="add_item">
      <description summary="associate an item with this zone">
        Make 'item' a member of this zone.
        This state is double-buffered and is applied on the next
        'wl_surface.commit' of the surface represented by 'item'.
        This request associates an item with this zone.
        If this request is called on an item that already has a zone
        association with a different zone, the item must leave its old zone
        (with 'item_left' being emitted on its old zone) and will instead
        be associated with this zone.
        Upon receiving this request and if the target zone is allowed for 'item',
        a compositor must emit 'item_entered' to confirm the zone association.
        It must even emit this event if the item was already associated with this
        zone before.
        The compositor must move the surface represented by 'item' into the
        boundary of this zone upon receiving this request and accepting it
        (either by extending the zone size, or by moving the item surface).
        If the compositor does not allow the item to switch zone associations,
        and wants it to remain in its previous zone, it must emit
        'item_blocked' instead.
        Compositors might want to prevent zone associations if they
        perform specialized window management (e.g. autotiling) that would
        make clients moving items between certain zones undesirable.
        Once the 'item' is added to its zone, the compositor must first send
        a 'frame_extents' event on the item, followed by an initial 'position'
        event with the item's current position.
        The compositor must then send 'position' events when the position
        of the item in its zone is changed, for as long as the item is
        associated with a zone.
        If the zone is invalid, an 'invalid' error must be raised and the item
        must not be associated with the invalid zone.
        If the referenced item is inert (its underlying surface has been
        destroyed), the request must be silently ignored.
      </description>
      <arg name="item" type="object" interface="xx_zone_item_v1" summary="the zone item"/>
    </request>
    <request name="remove_item">
      <description summary="disassociate an item from this zone">
        Remove 'item' as a member of this zone.
        This state is double-buffered and is applied on the next
        'wl_surface.commit' of the surface represented by 'item'.
        This request removes the item from this zone explicitly,
        making the client unable to retrieve coordinates again.
        Upon receiving this request, the compositor should not change the
        item surface position on screen, and must emit 'item_left' to confirm
        the item's removal. It must even emit this event if the
        item was never associated with this zone.
        If the referenced item is inert (its underlying surface has been
        destroyed), the request must be silently ignored.
      </description>
      <arg name="item" type="object" interface="xx_zone_item_v1" summary="the zone item"/>
    </request>
    <event name="item_blocked">
      <description summary="an item could not be associated with this zone">
        This event notifies the client that an item was prevented from
        joining this zone.
        It is emitted as a response to 'add_item' if the compositor did not
        allow the item to join this particular zone.
      </description>
      <arg name="item" type="object" interface="xx_zone_item_v1" summary="the item that was prevented from joining this zone"/>
    </event>
    <event name="item_entered">
      <description summary="notify about an item having joined this zone">
        This event notifies the client of an item joining this zone.
        It is emitted as a response to 'add_item' or if the compositor
        automatically had the item surface (re)join an existing zone.
      </description>
      <arg name="item" type="object" interface="xx_zone_item_v1" summary="the item that has joined the zone"/>
    </event>
    <event name="item_left">
      <description summary="notify about an item having left this zone">
        This event notifies the client of an item leaving this zone, and
        therefore the client will no longer receive updated coordinates
        or frame extents for this item.
        If the client still wishes to adjust the item surface coordinates, it
        may associate the item with a zone again by calling 'add_item'.
        This event is emitted for example if the user moved an item surface out
        of a smaller zone's boundaries, or onto a different screen where the
        previous zone can not expand to. It is also emitted in response to
        explicitly removing an item via 'remove_item'.
      </description>
      <arg name="item" type="object" interface="xx_zone_item_v1" summary="the item that has left the zone"/>
    </event>
  </interface>
 </protocol>
--- a/meson.build
+++ b/meson.build
@ -1,5 +1,5 @@
 project('wayland-protocols',
-	version: '1.48',
+	version: '1.46',
 	meson_version: '>= 0.58.0',
 	license: 'MIT/Expat',
 )
@ -9,106 +9,90 @@ wayland_protocols_version = meson.project_version()
 fs = import('fs')
 dep_scanner = dependency('wayland-scanner',
-    version: get_option('tests') ? '>=1.25.0' : '>=1.20.0',
+    version: get_option('tests') ? '>=1.23.0' : '>=1.20.0',
    native: true,
    fallback: 'wayland'
 )
 prog_scanner = find_program(dep_scanner.get_variable(pkgconfig: 'wayland_scanner', internal: 'wayland_scanner'))
 stable_protocols = {
-	'linux-dmabuf': {'v1': []},
+	'linux-dmabuf': ['v1'],
-	'presentation-time': {'': []},
+	'presentation-time': [''],
-	'tablet': {'v2': []},
+	'tablet': ['v2'],
-	'viewporter': {'': []},
+	'viewporter': [''],
-	'xdg-shell': {'': []},
+	'xdg-shell': [''],
 }
 unstable_protocols = {
-	'fullscreen-shell': {'v1': []},
+	'fullscreen-shell': ['v1'],
-	'idle-inhibit': {'v1': []},
+	'idle-inhibit': ['v1'],
-	'input-method': {'v1': []},
+	'input-method': ['v1'],
-	'input-timestamps': {'v1': []},
+	'input-timestamps': ['v1'],
-	'keyboard-shortcuts-inhibit': {'v1': []},
+	'keyboard-shortcuts-inhibit': ['v1'],
-	'linux-dmabuf': {'v1': []},
+	'linux-dmabuf': ['v1'],
-	'linux-explicit-synchronization': {'v1': []},
+	'linux-explicit-synchronization': ['v1'],
-	'pointer-constraints': {'v1': []},
+	'pointer-constraints': ['v1'],
-	'pointer-gestures': {'v1': []},
+	'pointer-gestures': ['v1'],
-	'primary-selection': {'v1': []},
+	'primary-selection': ['v1'],
-	'relative-pointer': {'v1': []},
+	'relative-pointer': ['v1'],
-	'tablet': {'v1': [], 'v2': []},
+	'tablet': ['v1', 'v2'],
-	'text-input': {'v1': [], 'v3': []},
+	'text-input': ['v1', 'v3'],
-	'xdg-decoration': {'v1': ['stable/xdg-shell/xdg-shell.xml']},
+	'xdg-decoration': ['v1'],
-	'xdg-foreign': {'v1': [], 'v2': []},
+	'xdg-foreign': ['v1', 'v2'],
-	'xdg-output': {'v1': []},
+	'xdg-output': ['v1'],
-	'xdg-shell': {'v5': [], 'v6': []},
+	'xdg-shell': ['v5', 'v6'],
-	'xwayland-keyboard-grab': {'v1': []},
+	'xwayland-keyboard-grab': ['v1'],
 }
 staging_protocols = {
-	'alpha-modifier': {'v1': []},
+	'alpha-modifier': ['v1'],
-	'color-management': {'v1': []},
+	'color-management': ['v1'],
-	'color-representation': {'v1': []},
+	'color-representation': ['v1'],
-	'commit-timing': {'v1': []},
+	'commit-timing': ['v1'],
-	'content-type': {'v1': []},
+	'content-type': ['v1'],
-	'cursor-shape': {'v1': ['stable/tablet/tablet-v2.xml']},
+	'cursor-shape': ['v1'],
-	'drm-lease': {'v1': []},
+	'drm-lease': ['v1'],
-	'ext-background-effect': {'v1': []},
+	'ext-background-effect': ['v1'],
-	'ext-data-control': {'v1': []},
+	'ext-data-control': ['v1'],
-	'ext-foreign-toplevel-list': {'v1': []},
+	'ext-foreign-toplevel-list': ['v1'],
-	'ext-idle-notify': {'v1': []},
+	'ext-idle-notify': ['v1'],
-	'ext-image-capture-source': {'v1': [
+	'ext-image-capture-source': ['v1'],
-		'staging/ext-foreign-toplevel-list/ext-foreign-toplevel-list-v1.xml',
+	'ext-image-copy-capture': ['v1'],
-	]},
+	'ext-session-lock': ['v1'],
-	'ext-image-copy-capture': {'v1': [
+	'ext-transient-seat': ['v1'],
-		'staging/ext-image-capture-source/ext-image-capture-source-v1.xml',
+	'ext-workspace': ['v1'],
-		'staging/ext-foreign-toplevel-list/ext-foreign-toplevel-list-v1.xml',
+	'fifo': ['v1'],
-	]},
+	'fractional-scale': ['v1'],
-	'ext-session-lock': {'v1': []},
+	'linux-drm-syncobj': ['v1'],
-	'ext-transient-seat': {'v1': []},
+	'pointer-warp': ['v1'],
-	'ext-workspace': {'v1': []},
+	'security-context': ['v1'],
-	'fifo': {'v1': []},
+	'single-pixel-buffer': ['v1'],
-	'fractional-scale': {'v1': []},
+	'tearing-control': ['v1'],
-	'linux-drm-syncobj': {'v1': []},
+	'xdg-activation': ['v1'],
-	'pointer-warp': {'v1': []},
+	'xdg-dialog': ['v1'],
-	'security-context': {'v1': []},
+	'xdg-system-bell': ['v1'],
-	'single-pixel-buffer': {'v1': []},
+	'xdg-toplevel-drag': ['v1'],
-	'tearing-control': {'v1': []},
+	'xdg-toplevel-icon': ['v1'],
-	'xdg-activation': {'v1': []},
+	'xdg-toplevel-tag': ['v1'],
-	'xdg-dialog': {'v1': ['stable/xdg-shell/xdg-shell.xml']},
+	'xwayland-shell': ['v1'],
 	'xdg-session-management': {'v1': ['stable/xdg-shell/xdg-shell.xml']},
 	'xdg-system-bell': {'v1': []},
 	'xdg-toplevel-drag': {'v1': ['stable/xdg-shell/xdg-shell.xml']},
 	'xdg-toplevel-icon': {'v1': ['stable/xdg-shell/xdg-shell.xml']},
 	'xdg-toplevel-tag': {'v1': ['stable/xdg-shell/xdg-shell.xml']},
 	'xwayland-shell': {'v1': []},
 }
 experimental_protocols = {
-	'xx-cutouts': {'v1': []},
+	'xx-input-method': ['v2'],
-	'xx-input-method': {'v2': []},
+	'xx-session-management': ['v1'],
-	'xx-keyboard-filter': {'v1': [
+	'xx-text-input': ['v3'],
 		'experimental/xx-input-method/xx-input-method-v2.xml',
 	]},
 	'xx-session-management': {'v1': ['stable/xdg-shell/xdg-shell.xml']},
 	'xx-text-input': {'v3': []},
 	'xx-zones': {'v1': ['stable/xdg-shell/xdg-shell.xml']},
 }
 protocol_files = []
 installed_protocol_files = []
 protocol_deps = {}
 stable_protocol_files = []
 foreach name, versions : stable_protocols
-	foreach version, deps : versions
+	foreach version : versions
 		if version == ''
-			protocol_file = 'stable/@0@/@0@.xml'.format(name)
+			stable_protocol_files += ['stable/@0@/@0@.xml'.format(name)]
 		else
-			protocol_file = 'stable/@0@/@0@-@1@.xml'.format(name, version)
+			stable_protocol_files += ['stable/@0@/@0@-@1@.xml'.format(name, version)]
 		endif
 		stable_protocol_files += [protocol_file]
 		if deps.length() > 0
 			protocol_deps += {protocol_file: deps}
 		endif
 	endforeach
 endforeach
@ -117,12 +101,10 @@ protocol_files += stable_protocol_files
 staging_protocol_files = []
 foreach name, versions : staging_protocols
-	foreach version, deps : versions
+	foreach version : versions
-		protocol_file = 'staging/@0@/@0@-@1@.xml'.format(name, version)
+		staging_protocol_files += [
-		staging_protocol_files += [protocol_file]
+			'staging/@0@/@0@-@1@.xml'.format(name, version)
-		if deps.length() > 0
+		]
 			protocol_deps += {protocol_file: deps}
 		endif
 	endforeach
 endforeach
 installed_protocol_files += staging_protocol_files
@ -130,12 +112,10 @@ protocol_files += staging_protocol_files
 unstable_protocol_files = []
 foreach name, versions : unstable_protocols
-	foreach version, deps : versions
+	foreach version : versions
-		protocol_file = 'unstable/@0@/@0@-unstable-@1@.xml'.format(name, version)
+		unstable_protocol_files += [
-		unstable_protocol_files += [protocol_file]
+			'unstable/@0@/@0@-unstable-@1@.xml'.format(name, version)
-		if deps.length() > 0
+		]
 			protocol_deps += {protocol_file: deps}
 		endif
 	endforeach
 endforeach
 installed_protocol_files += unstable_protocol_files
@ -143,12 +123,10 @@ protocol_files += unstable_protocol_files
 experimental_protocol_files = []
 foreach name, versions : experimental_protocols
-	foreach version, deps : versions
+	foreach version : versions
-		protocol_file = 'experimental/@0@/@0@-@1@.xml'.format(name, version)
+		experimental_protocol_files += [
-		experimental_protocol_files += [protocol_file]
+			'experimental/@0@/@0@-@1@.xml'.format(name, version)
-		if deps.length() > 0
+		]
 			protocol_deps += {protocol_file: deps}
 		endif
 	endforeach
 endforeach
 protocol_files += experimental_protocol_files
@ -180,29 +158,34 @@ if dep_scanner.version().version_compare('>=1.22.90')
 	include_dirs = ['include']
 endif
-pkgconfig = import('pkgconfig')
+wayland_protocols_srcdir = meson.current_source_dir()
-pkgconfig.generate(
+pkgconfig_configuration = configuration_data()
-	filebase: 'wayland-protocols',
+pkgconfig_configuration.set('prefix', get_option('prefix'))
-	name: 'Wayland Protocols',
+pkgconfig_configuration.set('includedir', '${prefix}/@0@'.format(get_option('includedir')))
-	description: 'Wayland protocol files',
+pkgconfig_configuration.set('datarootdir', '${prefix}/@0@'.format(get_option('datadir')))
-	dataonly: true,
+pkgconfig_configuration.set('abs_top_srcdir', wayland_protocols_srcdir)
-	variables: {
+pkgconfig_configuration.set('PACKAGE', 'wayland-protocols')
-		'prefix': get_option('prefix'),
+pkgconfig_configuration.set('WAYLAND_PROTOCOLS_VERSION', wayland_protocols_version)
-		'includedir': '${prefix}/@0@'.format(get_option('includedir')),
+
-		'datarootdir': '${prefix}/@0@'.format(get_option('datadir')),
+pkg_install_dir = join_paths(get_option('datadir'), 'pkgconfig')
-		'pkgdatadir': '${pc_sysrootdir}${datarootdir}/wayland-protocols'
+configure_file(
-	},
+	input: 'wayland-protocols.pc.in',
-	uninstalled_variables: {
+	output: 'wayland-protocols.pc',
-		'includedir': meson.current_build_dir() / 'include',
+	configuration: pkgconfig_configuration,
-		'pkgdatadir': meson.project_source_root(),
+	install_dir: pkg_install_dir,
-	},
+)
 configure_file(
 	input: 'wayland-protocols-uninstalled.pc.in',
 	output: 'wayland-protocols-uninstalled.pc',
 	configuration: pkgconfig_configuration,
 )
 wayland_protocols = declare_dependency(
 	include_directories: include_dirs,
 	variables: {
-		'pkgdatadir': meson.project_source_root(),
+		'pkgdatadir': wayland_protocols_srcdir,
 	},
 	sources: headers,
 )
--- a/stable/linux-dmabuf/linux-dmabuf-v1.xml
+++ b/stable/linux-dmabuf/linux-dmabuf-v1.xml
@ -61,7 +61,7 @@
      import later fails.
      To create a wl_buffer from one or more dmabufs, a client creates a
-      zwp_linux_buffer_params_v1 object with a zwp_linux_dmabuf_v1.create_params
+      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.
@ -105,7 +105,7 @@
        received.
      </description>
      <arg name="params_id" type="new_id" interface="zwp_linux_buffer_params_v1"
-           summary="id for the newly created zwp_linux_buffer_params_v1"/>
+           summary="the new temporary"/>
    </request>
    <event name="format" deprecated-since="4">
@ -162,7 +162,7 @@
    <request name="get_default_feedback" since="4">
      <description summary="get default feedback">
-        This request creates a new zwp_linux_dmabuf_feedback_v1 object not bound
+        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).
@ -172,11 +172,11 @@
    <request name="get_surface_feedback" since="4">
      <description summary="get feedback for a surface">
-        This request creates a new zwp_linux_dmabuf_feedback_v1 object for the
+        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 zwp_linux_dmabuf_feedback_v1 object,
+        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"/>
@ -206,7 +206,7 @@
    <enum name="error">
      <entry name="already_used" value="0"
-             summary="the zwp_linux_buffer_params_v1 object has already been used to create a wl_buffer"/>
+             summary="the dmabuf_batch object has already been used to create a wl_buffer"/>
      <entry name="plane_idx" value="1"
             summary="plane index out of bounds"/>
      <entry name="plane_set" value="2"
@ -282,7 +282,7 @@
        authoritative source on how the format codes should work.
        The 'flags' is a bitfield of the flags defined in enum "flags".
-        'y_invert' means that the image needs to be y-flipped.
+        'y_invert' means the that the image needs to be y-flipped.
        Flag 'interlaced' means that the frame in the buffer is not
        progressive as usual, but interlaced. An interlaced buffer as
@ -326,7 +326,7 @@
        This request can be sent only once in the object's lifetime, after
        which the only legal request is destroy. This object should be
        destroyed after issuing a 'create' request. Attempting to use this
-        object after issuing 'create' raises the ALREADY_USED protocol error.
+        object after issuing 'create' raises ALREADY_USED protocol error.
        It is not mandatory to issue 'create'. If a client wants to
        cancel the buffer creation, it can just destroy this object.
@ -346,7 +346,7 @@
        zwp_linux_buffer_params_v1 object.
      </description>
      <arg name="buffer" type="new_id" interface="wl_buffer"
-           summary="id for the the newly created wl_buffer"/>
+           summary="the newly created wl_buffer"/>
    </event>
    <event name="failed">
@ -428,16 +428,16 @@
    <request name="destroy" type="destructor">
      <description summary="destroy the feedback object">
        Using this request a client can tell the server that it is not going to
-        use the zwp_linux_dmabuf_feedback_v1 object anymore.
+        use the wp_linux_dmabuf_feedback object anymore.
      </description>
    </request>
    <event name="done">
      <description summary="all feedback has been sent">
-        This event is sent after all parameters of a zwp_linux_dmabuf_feedback_v1
+        This event is sent after all parameters of a wp_linux_dmabuf_feedback
        object have been sent.
-        This allows changes to the zwp_linux_dmabuf_feedback_v1 parameters to be
+        This allows changes to the wp_linux_dmabuf_feedback parameters to be
        seen as atomic, even if they happen via multiple events.
      </description>
    </event>
@ -468,14 +468,14 @@
        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
-        zwp_linux_dmabuf_feedback_v1 object, and may change over time.
+        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
-        zwp_linux_buffer_params_v1.create and create_immed requests for details).
+        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.
@ -494,7 +494,7 @@
    <event name="tranche_done">
      <description summary="a preference tranche has been sent">
-        This event splits tranche_target_device and tranche_formats events into
+        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.
@ -520,7 +520,7 @@
        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 zwp_linux_buffer_params_v1.create and
+        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
@ -534,7 +534,7 @@
    </event>
    <event name="tranche_formats">
-      <description summary="supported buffer format modifiers">
+      <description summary="supported buffer format modifier">
        This event advertises the format + modifier combinations that the
        compositor supports.
@ -558,7 +558,7 @@
        This event is tied to a preference tranche, see the tranche_done event.
        For the definition of the format and modifier codes, see the
-        zwp_linux_buffer_params_v1.create request.
+        wp_linux_buffer_params.create request.
      </description>
      <arg name="indices" type="array" summary="array of 16-bit indexes"/>
    </event>
--- a/stable/tablet/tablet-v2.xml
+++ b/stable/tablet/tablet-v2.xml
@ -997,7 +997,7 @@
 	zwp_tablet_pad_group_v2.mode_switch event for more details.
 	This event is sent in the initial burst of events before the
-	zwp_tablet_pad_group_v2.done event. This event is only sent when
+	zwp_tablet_pad_group_v2.done event. This event is only sent when more than
 	more than one mode is available.
      </description>
      <arg name="modes" type="uint" summary="the number of modes"/>
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@ -75,16 +75,17 @@
    <request name="get_xdg_surface">
      <description summary="create a shell surface from a surface">
 	This creates an xdg_surface for the given surface. While xdg_surface
 	itself is not a role, the corresponding surface may only be assigned
 	a role extending xdg_surface, such as xdg_toplevel or xdg_popup. It is
 	illegal to create an xdg_surface for a wl_surface which already has an
 	assigned role and this will result in a role error.
 	This creates an xdg_surface for the given surface. An xdg_surface is
 	used as basis to define a role to a given surface, such as xdg_toplevel
 	or xdg_popup. It also manages functionality shared between xdg_surface
 	based surface roles.
 	While xdg_surface itself is not a role, the corresponding surface may
 	only be assigned a role extending xdg_surface, such as xdg_toplevel or
 	xdg_popup. It is illegal to create an xdg_surface for a wl_surface which
 	already has anassigned role and this will result in a role error.
 	See the documentation of xdg_surface for more details about what an
 	xdg_surface is and how it is used.
      </description>
@ -200,14 +201,14 @@
    <request name="set_anchor">
      <description summary="set anchor rectangle anchor">
 	Defines the anchor point for the anchor rectangle. The specified anchor
-	is used to derive an anchor point that the child surface will be
+	is used derive an anchor point that the child surface will be
 	positioned relative to. If a corner anchor is set (e.g. 'top_left' or
 	'bottom_right'), the anchor point will be at the specified corner;
 	otherwise, the derived anchor point will be centered on the specified
 	edge, or in the center of the anchor rectangle if no edge is specified.
      </description>
      <arg name="anchor" type="uint" enum="anchor"
-	   summary="anchor point"/>
+	   summary="anchor"/>
    </request>
    <enum name="gravity">
@ -379,7 +380,7 @@
    </request>
    <request name="set_parent_size" since="3">
-      <description summary="set parent size">
+      <description summary="">
 	Set the parent window geometry the compositor should use when
 	positioning the popup. The compositor may use this information to
 	determine the future state the popup should be constrained using. If
@ -504,8 +505,8 @@
 	xdg_popup is and how it is used.
      </description>
      <arg name="id" type="new_id" interface="xdg_popup"/>
-      <arg name="parent" type="object" interface="xdg_surface" allow-null="true" summary="parent surface for this popup"/>
+      <arg name="parent" type="object" interface="xdg_surface" allow-null="true"/>
-      <arg name="positioner" type="object" interface="xdg_positioner" summary="positioner for this popup"/>
+      <arg name="positioner" type="object" interface="xdg_positioner"/>
    </request>
    <request name="set_window_geometry">
@ -551,10 +552,10 @@
 	greater than zero. Setting an invalid size will raise an
 	invalid_size error.
      </description>
-      <arg name="x" type="int" summary="x coordinate of the top-left corner of the window inside this surface"/>
+      <arg name="x" type="int"/>
-      <arg name="y" type="int" summary="y coordinate of the top-left corner of the window inside this surface"/>
+      <arg name="y" type="int"/>
-      <arg name="width" type="int" summary="width of the window"/>
+      <arg name="width" type="int"/>
-      <arg name="height" type="int" summary="height of the window"/>
+      <arg name="height" type="int"/>
    </request>
    <request name="ack_configure">
@ -627,7 +628,7 @@
      id, and well as trigger user interactive operations such as interactive
      resize and move.
-      An xdg_toplevel by default is responsible for providing the full intended
+      A xdg_toplevel by default is responsible for providing the full intended
      visual representation of the toplevel, which depending on the window
      state, may mean things like a title bar, window controls and drop shadow.
@ -683,7 +684,7 @@
 	descendants, and the parent must be different from the child toplevel,
 	otherwise the invalid_parent protocol error is raised.
      </description>
-      <arg name="parent" type="object" interface="xdg_toplevel" allow-null="true" summary="parent surface for this surface"/>
+      <arg name="parent" type="object" interface="xdg_toplevel" allow-null="true"/>
    </request>
    <request name="set_title">
@ -696,7 +697,7 @@
 	The string must be encoded in UTF-8.
      </description>
-      <arg name="title" type="string" summary="title of the surface"/>
+      <arg name="title" type="string"/>
    </request>
    <request name="set_app_id">
@ -725,7 +726,7 @@
 	[0] https://standards.freedesktop.org/desktop-entry-spec/
      </description>
-      <arg name="app_id" type="string" summary="application identifier surface belongs to"/>
+      <arg name="app_id" type="string"/>
    </request>
    <request name="show_window_menu">
@ -980,11 +981,11 @@
 	a surface is illegal and will result in an invalid_size error.
 	The width and height must be greater than or equal to zero. Using
-	strictly negative values for width or height will result in an
+	strictly negative values for width or height will result in a
 	invalid_size error.
      </description>
-      <arg name="width" type="int" summary="maximum width of the window"/>
+      <arg name="width" type="int"/>
-      <arg name="height" type="int" summary="maximum height of the window"/>
+      <arg name="height" type="int"/>
    </request>
    <request name="set_min_size">
@ -1020,11 +1021,11 @@
 	a surface is illegal and will result in an invalid_size error.
 	The width and height must be greater than or equal to zero. Using
-	strictly negative values for width and height will result in an
+	strictly negative values for width and height will result in a
 	invalid_size error.
      </description>
-      <arg name="width" type="int" summary="minimum width of the window"/>
+      <arg name="width" type="int"/>
-      <arg name="height" type="int" summary="minimum height of the window"/>
+      <arg name="height" type="int"/>
    </request>
    <request name="set_maximized">
@ -1094,7 +1095,7 @@
 	If the surface doesn't cover the whole output, the compositor will
 	position the surface in the center of the output and compensate with
-	border fill covering the rest of the output. The content of the
+	with border fill covering the rest of the output. The content of the
 	border fill is undefined, but should be assumed to be in some way that
 	attempts to blend into the surrounding area (e.g. solid black).
@ -1103,7 +1104,7 @@
 	up of subsurfaces, popups or similarly coupled surfaces) are not
 	visible below the fullscreened surface.
      </description>
-      <arg name="output" type="object" interface="wl_output" allow-null="true" summary="preferred output to place surface on"/>
+      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
    </request>
    <request name="unset_fullscreen">
@ -1163,9 +1164,9 @@
 	Clients must send an ack_configure in response to this event. See
 	xdg_surface.configure and xdg_surface.ack_configure for details.
      </description>
-      <arg name="width" type="int" summary="suggested width of window"/>
+      <arg name="width" type="int"/>
-      <arg name="height" type="int" summary="suggested height of window"/>
+      <arg name="height" type="int"/>
-      <arg name="states" type="array" summary="suggested states of the window"/>
+      <arg name="states" type="array"/>
    </event>
    <event name="close">
@ -1201,8 +1202,8 @@
 	xdg_toplevel.configure_bounds will be sent, followed by
 	xdg_toplevel.configure and xdg_surface.configure.
      </description>
-      <arg name="width" type="int" summary="suggested maximum width of surface"/>
+      <arg name="width" type="int"/>
-      <arg name="height" type="int" summary="suggested maximum height of surface"/>
+      <arg name="height" type="int"/>
    </event>
    <!-- Version 5 additions -->
--- a/staging/color-management/appendix.md
+++ b/staging/color-management/appendix.md
@ -53,22 +53,6 @@ The above are specified by [ITU-R BT.1886].
 Note, that $`E < 0`$ and $`E > 1`$ are possible with limited range
 quantization, as required by e.g. the calibration method in [ITU-R BT.814].
 ### `compound_power_2_4`
 ```math
 O = \begin{cases}
 \frac{E}{12.92}, & 0 \leq E < 0.04045\\
 \left( \frac{E + 0.055}{1.055} \right)^{2.4}, & 0.04045 \leq E \leq 1
 \end{cases}
 ```
 The above is the IEC 61966-2-1 piece-wise transfer function,
 as recorded in [Khronos Data Format Specification][KDFS] 1.4.0
 Section 13.3, and restricted to the unit range.
 ```math
 L = (L_W - L_B)O + L_B
 ```
 ### `gamma22`
@ -141,4 +125,3 @@ L = 10'000\ \mathrm{cd/m²} \cdot O + L_B
 [ITU-R BT.814]: https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/specs.md#itu-r-bt814
 [ITU-R BT.1886]: https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/specs.md#itu-r-bt1886
 [ITU-R BT.2100]: https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/specs.md#itu-r-bt2100
 [KDFS]: https://registry.khronos.org/DataFormat/
--- a/staging/color-management/color-management-v1.xml
+++ b/staging/color-management/color-management-v1.xml
@ -77,7 +77,7 @@
    only be done by creating a new major version of the extension.
  </description>
-  <interface name="wp_color_manager_v1" version="3">
+  <interface name="wp_color_manager_v1" version="1">
    <description summary="color manager singleton">
      A singleton global interface used for getting color management extensions
      for wl_surface and wl_output objects, and for creating client defined
@ -124,14 +124,6 @@
             summary="ICC-absolute colorimetric"/>
      <entry name="relative_bpc" value="4"
             summary="media-relative colorimetric + black point compensation"/>
      <entry name="absolute_no_adaptation" value="5" since="2">
        <description summary="ICC-absolute colorimetric without adaptation">
          This rendering intent is a modified absolute rendering intent that
          assumes the viewer is not adapted to the display white point, so no
          chromatic adaptation between surface and display is done.
          This can be useful for color proofing applications.
        </description>
      </entry>
    </enum>
    <enum name="feature">
@ -164,8 +156,6 @@
      </entry>
      <entry name="windows_scrgb" value="7"
             summary="create_windows_scrgb request"/>
      <entry name="windows_bt2100" value="8"
             summary="create_windows_bt2100 request"/>
    </enum>
    <enum name="primaries">
@ -290,7 +280,8 @@
          - United States Federal Communications Commission (2003) Title 47 Code
            of Federal Regulations 73.682 (a) (20)
          - Rec. ITU-R BT.1700-0 625 PAL and 625 SECAM
-          - IEC 61966-2-1 (reference display)
+
          Note: an sRGB display (IEC 61966-2-1) uses this transfer function.
        </description>
      </entry>
      <entry name="gamma28" value="3">
@ -327,18 +318,18 @@
          - IEC 61966-2-4
        </description>
      </entry>
-      <entry name="srgb" value="9" deprecated-since="2">
+      <entry name="srgb" value="9">
-        <description summary="Deprecated (ambiguous sRGB transfer function)">
+        <description summary="sRGB piece-wise transfer function">
          Transfer characteristics as defined by
          - IEC 61966-2-1 sRGB
-          As a rule of thumb, use gamma22 for video, motion picture and
+          Note: This is not appropriate for describing sRGB material.
-          computer graphics, or compound_power_2_4 for ICC calibrated print
+          sRGB material is intended to be viewed on an sRGB display, and
-          workflows.
+          that is described by gamma22.
        </description>
      </entry>
-      <entry name="ext_srgb" value="10" deprecated-since="2">
+      <entry name="ext_srgb" value="10">
-        <description summary="Deprecated (Extended sRGB piece-wise transfer function)">
+        <description summary="Extended sRGB piece-wise transfer function">
          Transfer characteristics as defined by
          - IEC 61966-2-1 sYCC
        </description>
@ -388,12 +379,6 @@
          ARIB STD-B67 or BT.2100.
        </description>
      </entry>
      <entry name="compound_power_2_4" value="14" since="2">
        <description summary="IEC 61966-2-1 encoding function">
          Encoding characteristics as defined by IEC 61966-2-1, for displays
          that invert the encoding function.
        </description>
      </entry>
    </enum>
    <request name="get_output">
@ -527,9 +512,6 @@
      <description summary="supported rendering intent">
        When this object is created, it shall immediately send this event once
        for each rendering intent the compositor supports.
        A compositor must not advertise intents that are deprecated in the
        bound version of the interface.
      </description>
      <arg name="render_intent" type="uint" enum="render_intent"
@ -540,9 +522,6 @@
      <description summary="supported features">
        When this object is created, it shall immediately send this event once
        for each compositor supported feature listed in the enumeration.
        A compositor must not advertise features that are deprecated in the
        bound version of the interface.
      </description>
      <arg name="feature" type="uint" enum="feature"
@ -554,9 +533,6 @@
        When this object is created, it shall immediately send this event once
        for each named transfer function the compositor supports with the
        parametric image description creator.
        A compositor must not advertise transfer functions that are deprecated
        in the bound version of the interface.
      </description>
      <arg name="tf" type="uint" enum="transfer_function"
@ -568,9 +544,6 @@
        When this object is created, it shall immediately send this event once
        for each named set of primaries the compositor supports with the
        parametric image description creator.
        A compositor must not advertise names that are deprecated in the
        bound version of the interface.
      </description>
      <arg name="primaries" type="uint" enum="primaries"
@ -583,55 +556,9 @@
        transfer functions and named primaries have been sent.
      </description>
    </event>
    <request name="get_image_description" since="2">
      <description summary="create an image description from a reference">
        This request retrieves the image description backing a reference.
        The get_information request can be used if and only if the request that
        creates the reference allows it.
      </description>
      <arg name="image_description"
           type="new_id" interface="wp_image_description_v1"/>
      <arg name="reference"
           type="object" interface="wp_image_description_reference_v1"/>
    </request>
    <request name="create_windows_bt2100" since="3">
      <description summary="create Windows-BT.2100 image description object">
        This creates a pre-defined image description for the so-called
        Windows-BT.2100 stimulus encoding. This comes from the Windows 10
        handling of its own definition of a BT.2100 color space for an HDR
        screen driven in BT.2100/PQ signalling mode.
        Windows-BT.2100 uses BT.2020 color primaries and white point.
        The transfer characteristic is st2084_pq.
        Windows-BT.2100 is generally displayed by Windows 10 without any
        adjustments to the signal to account for viewing conditions.
        The reference white level of Windows-BT.2100 is unknown. If a
        reference white level must be assumed for compositor processing, it
        should be 203 cd/m² of Report ITU-R BT.2408-7.
        The target color volume of Windows-BT.2100 is unknown. The color gamut
        may be anything up to BT.2100.
        This request can be used when the compositor advertises
        wp_color_manager_v1.feature.windows_bt2100.
        Otherwise this request raises the protocol error unsupported_feature.
        The resulting image description object does not allow get_information
        request. The wp_image_description_v1.ready event shall be sent.
      </description>
      <arg name="image_description"
           type="new_id" interface="wp_image_description_v1"/>
      </request>
  </interface>
-  <interface name="wp_color_management_output_v1" version="3">
+  <interface name="wp_color_management_output_v1" version="1">
    <description summary="output color properties">
      A wp_color_management_output_v1 describes the color properties of an
      output.
@ -701,7 +628,7 @@
    </request>
  </interface>
-  <interface name="wp_color_management_surface_v1" version="3">
+  <interface name="wp_color_management_surface_v1" version="1">
    <description summary="color management extension to a surface">
        A wp_color_management_surface_v1 allows the client to set the color
        space and HDR properties of a surface.
@ -789,7 +716,7 @@
    </request>
  </interface>
-  <interface name="wp_color_management_surface_feedback_v1" version="3">
+  <interface name="wp_color_management_surface_feedback_v1" version="1">
    <description summary="color management extension to a surface">
        A wp_color_management_surface_feedback_v1 allows the client to get the
        preferred image description of a surface.
@ -812,14 +739,27 @@
             summary="attempted to use an unsupported feature"/>
    </enum>
-    <event name="preferred_changed" deprecated-since="2">
+    <event name="preferred_changed">
-      <description summary="the preferred image description changed (32-bit)">
+      <description summary="the preferred image description changed">
-        Starting from interface version 2, 'preferred_changed2' is sent instead
+        The preferred image description is the one which likely has the most
-        of this event. See the 'preferred_changed2' event for the definition.
+        performance and/or quality benefits for the compositor if used by the
        client for its wl_surface contents. This event is sent whenever the
        compositor changes the wl_surface's preferred image description.
        This event sends the identity of the new preferred state as the argument,
        so clients who are aware of the image description already can reuse it.
        Otherwise, if the client client wants to know what the preferred image
        description is, it shall use the get_preferred request.
        The preferred image description is not automatically used for anything.
        It is only a hint, and clients may set any valid image description with
        set_image_description, but there might be performance and color accuracy
        improvements by providing the wl_surface contents in the preferred
        image description. Therefore clients that can, should render according
        to the preferred image description
      </description>
-      <arg name="identity" type="uint"
+      <arg name="identity" type="uint" summary="image description id number"/>
           summary="the 32-bit image description id number"/>
    </event>
    <request name="get_preferred">
@ -876,38 +816,9 @@
      <arg name="image_description"
           type="new_id" interface="wp_image_description_v1"/>
    </request>
    <!-- Version 2 additions -->
    <event name="preferred_changed2" since="2">
      <description summary="the preferred image description changed">
        The preferred image description is the one which likely has the most
        performance and/or quality benefits for the compositor if used by the
        client for its wl_surface contents. This event is sent whenever the
        compositor changes the wl_surface's preferred image description.
        This event sends the identity of the new preferred state as the argument,
        so clients who are aware of the image description already can reuse it.
        Otherwise, if the client client wants to know what the preferred image
        description is, it shall use the get_preferred request.
        The preferred image description is not automatically used for anything.
        It is only a hint, and clients may set any valid image description with
        set_image_description, but there might be performance and color accuracy
        improvements by providing the wl_surface contents in the preferred
        image description. Therefore clients that can, should render according
        to the preferred image description
      </description>
      <arg name="identity_hi" type="uint"
           summary="high 32 bits of the 64-bit image description id number"/>
      <arg name="identity_lo" type="uint"
           summary="low 32 bits of the 64-bit image description id number"/>
    </event>
  </interface>
-  <interface name="wp_image_description_creator_icc_v1" version="3">
+  <interface name="wp_image_description_creator_icc_v1" version="1">
    <description summary="holder of image description ICC information">
      This type of object is used for collecting all the information required
      to create a wp_image_description_v1 object from an ICC file. A complete
@ -1023,7 +934,7 @@
    </request>
  </interface>
-  <interface name="wp_image_description_creator_params_v1" version="3">
+  <interface name="wp_image_description_creator_params_v1" version="1">
    <description summary="holder of image description parameters">
      This type of object is used for collecting all the parameters required
      to create a wp_image_description_v1 object. A complete set of required
@ -1094,16 +1005,14 @@
        complete, the protocol error incomplete_set is raised. For the
        definition of a complete set, see the description of this interface.
-        When both max_cll and max_fall are set, max_fall must be less or equal
+        The protocol error invalid_luminance is raised if any of the following
-        to max_cll otherwise the invalid_luminance protocol error is raised.
+        requirements is not met:
        In version 1, these following conditions also result in the
        invalid_luminance protocol error. Version 2 and later do not have this
        requirement.
        - When max_cll is set, it must be greater than min L and less or equal
          to max L of the mastering luminance range.
        - When max_fall is set, it must be greater than min L and less or equal
          to max L of the mastering luminance range.
        - When both max_cll and max_fall are set, max_fall must be less or equal
          to max_cll.
        If the particular combination of the parameter set is not supported
        by the compositor, the resulting image description object shall
@ -1397,7 +1306,7 @@
    </request>
  </interface>
-  <interface name="wp_image_description_v1" version="3">
+  <interface name="wp_image_description_v1" version="1">
    <description summary="Colorimetric image description">
      An image description carries information about the pixel color encoding
      and its intended display and viewing environment. The image description is
@ -1474,22 +1383,38 @@
           summary="ad hoc human-readable explanation"/>
    </event>
-    <event name="ready" deprecated-since="2">
+    <event name="ready">
-      <description summary="the object is ready to be used (32-bit)">
+      <description summary="indication that the object is ready to be used">
-        Starting from interface version 2, the 'ready2' event is sent instead
+        Once this event has been sent, the wp_image_description_v1 object is
-        of this event.
+        deemed "ready". Ready objects can be used to send requests and can be
        used through other interfaces.
-        For the definition of this event, see the 'ready2' event. The
+        Every ready wp_image_description_v1 protocol object refers to an
-        difference to this event is as follows.
+        underlying image description record in the compositor. Multiple protocol
        objects may end up referring to the same record. Clients may identify
        these "copies" by comparing their id numbers: if the numbers from two
        protocol objects are identical, the protocol objects refer to the same
        image description record. Two different image description records
        cannot have the same id number simultaneously. The id number does not
        change during the lifetime of the image description record.
        The id number is valid only as long as the protocol object is alive. If
        all protocol objects referring to the same image description record are
        destroyed, the id number may be recycled for a different image
        description record.
        Image description id number is not a protocol object id. Zero is
        reserved as an invalid id number. It shall not be possible for a client
        to refer to an image description by its id number in protocol. The id
        numbers might not be portable between Wayland connections. A compositor
        shall not send an invalid id number.
        This identity allows clients to de-duplicate image description records
        and avoid get_information request if they already have the image
        description information.
      </description>
-      <arg name="identity" type="uint"
+      <arg name="identity" type="uint" summary="image description id number"/>
           summary="the 32-bit image description id number"/>
    </event>
    <request name="get_information">
@ -1506,45 +1431,9 @@
      <arg name="information"
           type="new_id" interface="wp_image_description_info_v1"/>
    </request>
    <!-- Version 2 additions -->
    <event name="ready2" since="2">
      <description summary="the object is ready to be used">
        Once this event has been sent, the wp_image_description_v1 object is
        deemed "ready". Ready objects can be used to send requests and can be
        used through other interfaces.
        Every ready wp_image_description_v1 protocol object refers to an
        underlying image description record in the compositor. Multiple protocol
        objects may end up referring to the same record. Clients may identify
        these "copies" by comparing their id numbers: if the numbers from two
        protocol objects are identical, the protocol objects refer to the same
        image description record. Two different image description records
        cannot have the same id number simultaneously. The id number does not
        change during the lifetime of the image description record.
        Image description id number is not a protocol object id. Zero is
        reserved as an invalid id number. It shall not be possible for a client
        to refer to an image description by its id number in protocol. The id
        numbers might not be portable between Wayland connections. A compositor
        shall not send an invalid id number.
        Compositors must not recycle image description id numbers.
        This identity allows clients to de-duplicate image description records
        and avoid get_information request if they already have the image
        description information.
      </description>
      <arg name="identity_hi" type="uint"
           summary="high 32 bits of the 64-bit image description id number"/>
      <arg name="identity_lo" type="uint"
           summary="low 32 bits of the 64-bit image description id number"/>
    </event>
  </interface>
-  <interface name="wp_image_description_info_v1" version="3">
+  <interface name="wp_image_description_info_v1" version="1">
    <description summary="Colorimetric image description information">
      Sends all matching events describing an image description object exactly
      once and finally sends the 'done' event.
@ -1673,7 +1562,9 @@
        SMPTE ST 2086 definition of HDR static metadata for mastering displays.
        While primary color volume is about how color is encoded, the target
-        color volume is the actually displayable color volume.
+        color volume is the actually displayable color volume. If target color
        volume is equal to the primary color volume, then this event is not
        sent.
        Each coordinate value is multiplied by 1 million to get the argument
        value to carry precision of 6 decimals.
@ -1735,22 +1626,4 @@
           summary="Maximum frame-average light level (cd/m²)"/>
    </event>
  </interface>
  <interface name="wp_image_description_reference_v1" version="1" frozen="true">
    <description summary="Reference to an image description">
      This object is a reference to an image description. This interface is
      frozen at version 1 to allow other protocols to create
      wp_image_description_v1 objects.
      The wp_color_manager_v1.get_image_description request can be used to
      retrieve the underlying image description.
    </description>
    <request name="destroy" type="destructor">
      <description summary="destroy the reference">
        Destroy this object. This has no effect on the referenced image
        description.
      </description>
    </request>
  </interface>
 </protocol>
--- a/staging/color-representation/notes.rst
+++ b/staging/color-representation/notes.rst
@ -71,7 +71,7 @@ inverse steps, including the transfer characteristics which are not defined by
 this protocol to convert the encoding back to tristimulus values with color
 primaries which are also not defined by this protocol.
-Some ``MatrixCoefficients`` code points require applying formulas or inferring
+Some ``MatrixCoefficients`` code points require applying formulas or infering
 constants from the transfer characteristics or color primaries of the image.
 Compositors should not advertise support for such code points if the client
 can't communicate the transfer characteristics and color primaries to the
--- a/staging/ext-foreign-toplevel-list/ext-foreign-toplevel-list-v1.xml
+++ b/staging/ext-foreign-toplevel-list/ext-foreign-toplevel-list-v1.xml
@ -201,7 +201,7 @@
        The compositor must only send this event when the handle is created.
-        The identifier must be unique per toplevel and its handles. Two different
+        The identifier must be unique per toplevel and it's handles. Two different
        toplevels must not have the same identifier. The identifier is only valid
        as long as the toplevel is mapped. If the toplevel is unmapped the identifier
        must not be reused. An identifier must not be reused by the compositor to
--- a/staging/ext-image-capture-source/ext-image-capture-source-v1.xml
+++ b/staging/ext-image-capture-source/ext-image-capture-source-v1.xml
@ -39,7 +39,7 @@
    only be done by creating a new major version of the extension.
  </description>
-  <interface name="ext_image_capture_source_v1" version="1" frozen="true">
+  <interface name="ext_image_capture_source_v1" version="1">
    <description summary="opaque image capture source object">
      The image capture source object is an opaque descriptor for a capturable
      resource.  This resource may be any sort of entity from which an image
--- a/staging/ext-workspace/ext-workspace-v1.xml
+++ b/staging/ext-workspace/ext-workspace-v1.xml
@ -184,7 +184,7 @@
      <description summary="workspace added to workspace group">
        This event is emitted whenever a workspace is assigned to this group.
        A workspace may only ever be assigned to a single group at a single point
-        in time, but can be re-assigned during its lifetime.
+        in time, but can be re-assigned during it's lifetime.
      </description>
      <arg name="workspace" type="object" interface="ext_workspace_handle_v1"/>
    </event>
@ -255,10 +255,10 @@
      <description summary="workspace id">
        If this event is emitted, it will be send immediately after the
        ext_workspace_handle_v1 is created or when an id is assigned to
-        a workspace (at most once during its lifetime).
+        a workspace (at most once during it's lifetime).
        An id will never change during the lifetime of the `ext_workspace_handle_v1`
-        and is guaranteed to be unique during its lifetime.
+        and is guaranteed to be unique during it's lifetime.
        Ids are not human-readable and shouldn't be displayed, use `name` for that purpose.
--- a/staging/xdg-session-management/README
+++ b/staging/xdg-session-management/README
@ -1,5 +0,0 @@
 xdg session management protocol
 Maintainers:
 Jonas Ådahl <jadahl@gmail.com>
 Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
--- a/staging/xdg-session-management/xdg-session-management-v1.xml
+++ b/staging/xdg-session-management/xdg-session-management-v1.xml
@ -1,333 +0,0 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <protocol name="xdg_session_management_v1">
  <copyright>
    Copyright 2018 Mike Blumenkrantz
    Copyright 2018 Samsung Electronics Co., Ltd
    Copyright 2018 Red Hat Inc.
    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 managing application sessions">
    This description provides a high-level overview of the interplay between
    the interfaces defined this protocol. For details, see the protocol
    specification.
    The xdg_session_manager protocol declares interfaces necessary to
    allow clients to restore toplevel state from previous executions. The
    xdg_session_manager_v1.get_session request can be used to obtain a
    xdg_session_v1 resource representing the state of a set of toplevels.
    Clients may obtain the session string to use in future calls through
    the xdg_session_v1.created event. Compositors will use this string
    as an identifiable token for future runs, possibly storing data about
    the related toplevels in persistent storage. Clients that wish to
    track sessions in multiple environments may use the $XDG_CURRENT_DESKTOP
    environment variable.
    Toplevels are managed through the xdg_session_v1.add_toplevel and
    xdg_session_v1.remove_toplevel pair of requests. Clients will explicitly
    request a toplevel to be restored according to prior state through the
    xdg_session_v1.restore_toplevel request before the toplevel is mapped.
    Compositors may store session information up to any arbitrary level, and
    apply any limits and policies to the amount of data stored and its lifetime.
    Clients must account for missing sessions and partial session restoration.
    Warning! The protocol described in this file is currently in the testing
    phase. Backward compatible changes may be added together with the
    corresponding interface version bump. Backward incompatible changes can
    only be done by creating a new major version of the extension.
  </description>
  <interface name="xdg_session_manager_v1" version="1">
    <description summary="manage sessions for applications">
      The xdg_session_manager_v1 interface defines base requests for creating and
      managing a session for an application. Sessions persist across application
      and compositor restarts unless explicitly destroyed. A session is created
      for the purpose of maintaining an application's xdg_toplevel surfaces
      across compositor or application restarts. The compositor should remember
      as many states as possible for surfaces in a given session, but there is
      no requirement for which states must be remembered.
      Policies such as cache eviction are declared an implementation detail of
      the compositor. Clients should account for no longer existing sessions.
    </description>
    <enum name="error">
      <entry name="in_use" summary="a requested session is already in use"
             value="1"/>
      <entry name="invalid_session_id" summary="invalid session identifier"
             value="2"/>
      <entry name="invalid_reason" summary="invalid reason" value="3"/>
    </enum>
    <enum name="reason">
      <description summary="reason for getting a session">
        The reason may determine in what way a session restores the window
        management state of associated toplevels.
        For example newly launched applications might be launched on the active
        workspace with restored size and position, while a recovered
        application might restore additional state such as active workspace and
        stacking order.
      </description>
      <entry name="launch" value="1">
        <description summary="an app is newly launched">
          A new app instance is launched, for example from an app launcher.
        </description>
      </entry>
      <entry name="recover" value="2">
        <description summary="an app recovered">
          An app instance is recovering from for example a compositor or app crash.
        </description>
      </entry>
      <entry name="session_restore" value="3">
        <description summary="an app restored">
          An app instance is restored, for example part of a restored session, or
          restored from having been temporarily terminated due to resource
          constraints.
        </description>
      </entry>
    </enum>
    <request name="destroy" type="destructor">
      <description summary="Destroy this object">
        Destroy the manager object. The existing session objects will be
        unaffected.
      </description>
    </request>
    <request name="get_session">
      <description summary="create or restore a session">
        Create a session object corresponding to either an existing session
        identified by the given session identifier string or a new session.
        While the session object exists, the session is considered to be "in
        use".
        If an identifier string represents a session that is currently actively
        in use by the the same client, an 'in_use' error is raised. If some
        other client is currently using the same session, the new session will
        replace managing the associated state.
        If the reason is not a valid enum entry, the 'invalid_reason' protocol
        error is raised.
        NULL is passed to initiate a new session. If a session_id is passed
        which does not represent a valid session, the compositor treats it as if
        NULL had been passed.
        The session id string must be UTF-8 encoded. It is also limited by the
        maximum length of wayland messages (around 4KB). The 'invalid_session_id'
        protocol error will be raised if an invalid string is provided.
        A client is allowed to have any number of in use sessions at the same
        time.
      </description>
      <arg name="id" type="new_id" interface="xdg_session_v1"/>
      <arg name="reason" type="uint" enum="reason"
           summary="reason for session"/>
      <arg name="session_id" type="string"
           summary="the session to restore"
           allow-null="true"/>
    </request>
  </interface>
  <interface name="xdg_session_v1" version="1">
    <description summary="A session for an application">
      A xdg_session_v1 object represents a session for an application. While the
      object exists, all surfaces which have been added to the session will
      have states stored by the compositor which can be reapplied at a later
      time. Two sessions cannot exist for the same identifier string.
      States for surfaces added to a session are automatically updated by the
      compositor when they are changed.
    </description>
    <enum name="error">
      <entry name="name_in_use"
             summary="toplevel name is already in use"
             value="1"/>
      <entry name="already_mapped"
             summary="toplevel was already mapped when restored"
             value="2"/>
      <entry name="invalid_name"
             summary="provided toplevel name is invalid"
             value="3"/>
      <entry name="already_added"
             summary="toplevel already added"
             value="4"/>
    </enum>
    <request name="destroy" type="destructor">
      <description summary="Destroy the session">
        Destroy a session object, preserving the current state but not continuing
        to make further updates if state changes occur. This makes the associated
        xdg_toplevel_session_v1 objects inert.
      </description>
    </request>
    <request name="remove" type="destructor">
      <description summary="Remove the session">
        Remove the session, making it no longer available for restoration. A
        compositor should in response to this request remove the data related to
        this session from its storage.
      </description>
    </request>
    <request name="add_toplevel">
      <description summary="add a new surface to the session">
        Attempt to add a given surface to the session. The passed name is used
        to identify what window is being restored, and may be used to store
        window specific state within the session.
        The name given to the toplevel must not correspond to any previously
        existing toplevel names in the session. If the name matches an already
        known toplevel name in the session, a 'name_in_use' protocol error will
        be raised.
        The toplevel object must not be added more than once to any session
        created by the client, otherwise the 'already_added' protocol error
        will be raised.
        This request will return a xdg_toplevel_session_v1 for later
        manipulation. As this resource is created from an empty initial state,
        compositors must not emit a xdg_toplevel_session_v1.restored event for
        resources created through this request.
        The name string must be UTF-8 encoded. It is also limited by the maximum
        length of wayland messages (around 4KB). The 'invalid_name' protocol
        error will be raised if an invalid string is provided.
      </description>
      <arg name="id" type="new_id" interface="xdg_toplevel_session_v1"/>
      <arg name="toplevel" type="object" interface="xdg_toplevel"/>
      <arg name="name" type="string" summary="name identifying the toplevel"/>
    </request>
    <request name="restore_toplevel">
      <description summary="restore a surface state">
        Inform the compositor that the toplevel associated with the passed name
        should have its window management state restored.
        If the toplevel name was previously granted to another xdg_toplevel,
        the 'name_in_use' protocol error will be raised.
        The toplevel object must not be added more than once to any session
        created by the client, otherwise the 'already_added' protocol error
        will be raised.
        This request must be called prior to the first commit on the associated
        wl_surface after creating the toplevel, otherwise an 'already_mapped'
        error is raised.
        As part of the initial configure sequence, if the toplevel was
        successfully restored, a xdg_toplevel_session_v1.restored event is
        emitted. If the toplevel name was not known in the session, this request
        will be equivalent to the xdg_toplevel_session_v1.add_toplevel request,
        and no such event will be emitted. See the xdg_toplevel_session_v1.restored
        event for further details.
        The name string must be UTF-8 encoded. It is also limited by the maximum
        length of wayland messages (around 4KB). The 'invalid_name' protocol
        error will be raised if an invalid string is provided.
      </description>
      <arg name="id" type="new_id" interface="xdg_toplevel_session_v1"/>
      <arg name="toplevel" type="object" interface="xdg_toplevel"/>
      <arg name="name" type="string" summary="name identifying the toplevel"/>
    </request>
    <request name="remove_toplevel">
      <description summary="remove a surface from the session">
        Remove a specified surface from the session and render any related
        xdg_toplevel_session_v1 object inert. The compositor should remove any
        data related to the toplevel in the corresponding session from its internal
        storage.
        The window is specified by its name in the session. The name string
        must be encoded in UTF-8, and it is limited in size by the maximum
        length of wayland messages (around 4KB).
      </description>
      <arg name="name" type="string" summary="name identifying the toplevel"/>
    </request>
    <event name="created">
      <description summary="newly-created session id">
        Emitted at most once some time after getting a new session object. It
        means that no previous state was restored, and a new session was created.
        The passed id can be persistently stored and used to restore previous
        sessions.
      </description>
      <arg name="session_id" type="string"/>
    </event>
    <event name="restored">
      <description summary="the session has been restored">
        Emitted at most once some time after getting a new session object. It
        means that previous state was at least partially restored. The same id
        can again be used to restore previous sessions.
      </description>
    </event>
    <event name="replaced">
      <description summary="the session has been replaced">
        Emitted at most once, if the session was taken over by some other
        client. When this happens, the session and all its toplevel session
        objects become inert, and should be destroyed.
      </description>
    </event>
  </interface>
  <interface name="xdg_toplevel_session_v1" version="1">
    <description summary="A session for an application">
      A xdg_toplevel_session_v1 resource acts as a handle for the given
      toplevel in the session. It allows for receiving events after a
      toplevel state was restored, and has the requests to manage them.
    </description>
    <request name="destroy" type="destructor">
      <description summary="Destroy the object">
        Destroy the object. This has no effect over window management of the
        associated toplevel.
      </description>
    </request>
    <request name="rename">
      <description summary="change the name of toplevel session">
        Renames the toplevel session. The new name can be used in subsequent requests
        to identify this session object. The state associated with this toplevel
        session will be preserved.
        If the xdg_session_v1 already contains a toplevel with the specified name,
        the 'name_in_use' protocol error will be raised.
      </description>
      <arg name="name" type="string" summary="new name to identify the toplevel"/>
    </request>
    <event name="restored">
      <description summary="a toplevel's session has been restored">
        The "restored" event is emitted prior to the first
        xdg_toplevel.configure for the toplevel. It will only be emitted after
        xdg_session_v1.restore_toplevel, and the initial empty surface state has
        been applied, and it indicates that the surface's session is being
        restored with this configure event.
      </description>
    </event>
  </interface>
 </protocol>
--- a/staging/xdg-toplevel-icon/xdg-toplevel-icon-v1.xml
+++ b/staging/xdg-toplevel-icon/xdg-toplevel-icon-v1.xml
@ -163,7 +163,7 @@
        fall back to using pixel buffer data instead.
        If this request is made after the icon has been assigned to a toplevel
-        via 'set_icon', an 'immutable' error must be raised.
+        via 'set_icon', a 'immutable' error must be raised.
        [1]: https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
      </description>
@ -195,7 +195,7 @@
        request is sent. The wl_buffer.release event is unused.
        If this request is made after the icon has been assigned to a toplevel
-        via 'set_icon', an 'immutable' error must be raised.
+        via 'set_icon', a 'immutable' error must be raised.
      </description>
      <arg name="buffer" type="object" interface="wl_buffer"/>
      <arg name="scale" type="int"
--- a/tests/meson.build
+++ b/tests/meson.build
@ -7,7 +7,7 @@ libwayland = [
 # Check that each protocol passes through the scanner
 foreach protocol_file : protocol_files
-	protocol_path = join_paths(meson.project_source_root(), protocol_file)
+	protocol_path = join_paths(wayland_protocols_srcdir, protocol_file)
 	test_name = 'scan-@0@'.format(protocol_file.underscorify())
 	test(test_name, prog_scan_sh,
 		args: protocol_path,
@ -22,19 +22,16 @@ endforeach
 add_languages('c', 'cpp', native: false)
 replace = find_program('replace.py')
-# First pass: generate scanner outputs for each protocol and record the
+extra_linker_flags = meson.get_compiler('c').get_supported_link_arguments([
-# generated custom_targets for use when building test executables.
+	'-Wl,--unresolved-symbols=ignore-all',
-protocol_code = {}
+])
 protocol_client_header = {}
 protocol_server_header = {}
 protocol_replace_command = {}
 foreach protocol_file : protocol_files
 	xml_file = fs.name(protocol_file)
 	xml_components = xml_file.split('.')
 	protocol_base_file_name = xml_components[0]
-	protocol_path = files(join_paths(meson.project_source_root(), protocol_file))
+	protocol_path = files(join_paths(wayland_protocols_srcdir, protocol_file))
 	client_header_path = '@0@-client.h'.format(protocol_base_file_name)
 	server_header_path = '@0@-server.h'.format(protocol_base_file_name)
 	code_path = '@0@-code.c'.format(protocol_base_file_name)
@ -78,10 +75,7 @@ foreach protocol_file : protocol_files
 		install: false,
 	)
-	protocol_code += {protocol_file: code}
+	replace_command = [
 	protocol_client_header += {protocol_file: client_header}
 	protocol_server_header += {protocol_file: server_header}
 	protocol_replace_command += {protocol_file: [
 		replace,
 		'@INPUT@',
 		'@OUTPUT@',
@ -89,22 +83,7 @@ foreach protocol_file : protocol_files
 		client_header.full_path(),
 		'PROTOCOL_SERVER_INCLUDE_FILE',
 		server_header.full_path(),
-	]}
+	]
 endforeach
 # Second pass: build test executables, linking in dependency code.
 foreach protocol_file : protocol_files
 	client_header = protocol_client_header[protocol_file]
 	server_header = protocol_server_header[protocol_file]
 	code = protocol_code[protocol_file]
 	replace_command = protocol_replace_command[protocol_file]
 	dep_code = []
 	if protocol_file in protocol_deps
 		foreach dep : protocol_deps[protocol_file]
 			dep_code += [protocol_code[dep]]
 		endforeach
 	endif
 	# Check that header can be included by a pedantic C99 compiler
 	test_name = 'test-build-pedantic-@0@'.format(protocol_file.underscorify())
@ -121,8 +100,9 @@ foreach protocol_file : protocol_files
 			test_source,
 			client_header,
 			server_header,
-			code,
+			code
-		] + dep_code,
+		],
 		link_args: extra_linker_flags,
 		dependencies: libwayland,
 		c_args: [
 			'-std=c99',
@ -149,7 +129,8 @@ foreach protocol_file : protocol_files
 				test_source,
 				client_header,
 				server_header,
-			] + dep_code,
+			],
 			link_args: extra_linker_flags,
 			dependencies: libwayland,
 			cpp_args: [
 				'-Wall',
--- a/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
+++ b/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
@ -1,29 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <protocol name="pointer_gestures_unstable_v1">
  <copyright>
    Copyright © 2015, 2021 Red Hat Inc.
    Permission to use, copy, modify, distribute, and sell this
    software and its documentation for any purpose is hereby granted
    without fee, provided that the above copyright notice appear in
    all copies and that both that copyright notice and this permission
    notice appear in supporting documentation, and that the name of
    the copyright holders not be used in advertising or publicity
    pertaining to distribution of the software without specific,
    written prior permission.  The copyright holders make no
    representations about the suitability of this software for any
    purpose.  It is provided "as is" without express or implied
    warranty.
    THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
    SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
    FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
    SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
    AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
    ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
    THIS SOFTWARE.
  </copyright>
  <interface name="zwp_pointer_gestures_v1" version="3">
    <description summary="touchpad gestures">
@ -85,7 +61,7 @@
  </interface>
-  <interface name="zwp_pointer_gesture_swipe_v1" version="3">
+  <interface name="zwp_pointer_gesture_swipe_v1" version="2">
    <description summary="a swipe gesture object">
      A swipe gesture object notifies a client about a multi-finger swipe
      gesture detected on an indirect input device such as a touchpad.
@ -148,7 +124,7 @@
    </event>
  </interface>
-  <interface name="zwp_pointer_gesture_pinch_v1" version="3">
+  <interface name="zwp_pointer_gesture_pinch_v1" version="2">
    <description summary="a pinch gesture object">
      A pinch gesture object notifies a client about a multi-finger pinch
      gesture detected on an indirect input device such as a touchpad.
--- a/unstable/text-input/text-input-unstable-v3.xml
+++ b/unstable/text-input/text-input-unstable-v3.xml
@ -47,7 +47,7 @@
    interface version number is reset.
  </description>
-  <interface name="zwp_text_input_v3" version="2">
+  <interface name="zwp_text_input_v3" version="1">
    <description summary="text input">
      The zwp_text_input_v3 interface represents text input and input methods
      associated with a seat. It provides enter/leave events to follow the
@ -210,15 +210,6 @@
      <entry name="sensitive_data" value="0x80" summary="typed text should not be stored"/>
      <entry name="latin" value="0x100" summary="just Latin characters should be entered"/>
      <entry name="multiline" value="0x200" summary="the text input is multiline"/>
      <entry
        name="on_screen_input_provided" value="0x400" since="2"
        summary="an on-screen way to fill in the input is already provided by the client"/>
      <entry
        name="no_emoji" value="0x800" since="2"
        summary="prefer not offering emoji support"/>
      <entry
        name="preedit_shown" value="0x1000" since="2"
        summary="the text input will display preedit text in place"/>
    </enum>
    <enum name="content_purpose">
@ -282,19 +273,6 @@
        the text input does not support describing the cursor area. If the
        empty values get applied, subsequent attempts to change them may have
        no effect.
        As of version 2, the zwp_text_input_v3.commit request does not apply
        values sent with this request. Instead, it stores them in a separate
        "committed" area. The committed values, if still valid, get applied on
        the next wl_surface.commit request on the surface with text-input focus.
        Both committed and applied values get invalidated on:
        - the next committed enable or disable request, or
        - a change of the focused surface of the text-input (leave or enter events).
        This double stage application allows the compositor to position
        the input method popup in the same frame as the contents
        of the text on the surface are updated.
      </description>
      <arg name="x" type="int"/>
      <arg name="y" type="int"/>
@ -425,10 +403,8 @@
    <event name="done">
      <description summary="apply changes">
        Instruct the application to apply changes to state requested by the
-        preedit_string, commit_string delete_surrounding_text, and action
+        preedit_string, commit_string and delete_surrounding_text events. The
-        events.
+        state relating to these events is double-buffered, and each one
        The state relating to these events is double-buffered, and each one
        modifies the pending state. This event replaces the current state with
        the pending state.
@ -441,7 +417,6 @@
        4. Calculate surrounding text to send.
        5. Insert new preedit text in cursor position.
        6. Place cursor inside preedit text.
        7. Perform the requested action.
        The serial number reflects the last state of the zwp_text_input_v3
        object known to the compositor. The value of the serial argument must
@ -457,132 +432,9 @@
      </description>
      <arg name="serial" type="uint"/>
    </event>
    <!-- Version 2 additions -->
    <enum name="error" since="2">
      <entry name="invalid_action" value="0" summary="an invalid or duplicate action was specified"/>
    </enum>
    <enum name="action" since="2">
      <description summary="action">
        A possible action to perform on a text input.
        The submit action is intended for input entries that expect some sort of
        activation after user interaction, e.g. the URL entry in a browser.
      </description>
      <entry name="none" value="0" summary="no action"/>
      <entry name="submit" value="1" summary="the action is submitted"/>
    </enum>
    <event name="action" since="2">
      <description summary="action performed">
        An action was performed on this text input.
        Values set with this event are double-buffered. They must be applied
        and reset to initial on the next zwp_text_input_v3.done event.
        The initial value of action is none.
      </description>
      <arg name="action" type="uint" enum="action" summary="action performed"/>
      <arg name="serial" type="uint" summary="serial number of the action event"/>
    </event>
    <event name="language" since="2">
      <description summary="notify of language selection">
        Notify the application of language used by the input method.
        This event will be sent on creation if known and for all subsequent changes.
        The language should be specified as an IETF BCP 47 tag.
        Setting an empty string will reset any known language back to the default unknown state.
      </description>
      <arg name="language" type="string" summary="new language set by IME"/>
    </event>
    <request name="set_available_actions" since="2">
      <description summary="set the available actions">
        Set the actions available for this text input.
        Values set with this request are double-buffered. They will get applied
        on the next zwp_text_input_v3.commit request.
        If the available_actions array contains the none action, or contains the
        same action multiple times, the compositor must raise the invalid_action
        protocol error.
        Initially, no actions are available.
      </description>
      <arg name="available_actions" type="array" summary="available actions"/>
    </request>
    <request name="show_input_panel" since="2">
      <description summary="show input panel">
 	Requests an input panel to be shown (e.g. a on-screen keyboard).
 	This request only hints the desired interaction pattern from the
 	client side, and its effect may be ignored by compositors given
 	other environmental factors. Repeated calls will be ignored.
      </description>
    </request>
    <request name="hide_input_panel" since="2">
      <description summary="hide input panel">
 	Requests an input panel to be hidden.
 	This request only hints the desired interaction pattern from the
 	client side, and its effect may be ignored by compositors given
 	other environmental factors. Repeated calls will be ignored.
      </description>
    </request>
    <enum name="preedit_hint">
      <description summary="preedit style hint">
 	Style hints for the preedit string.
      </description>
      <entry name="whole" value="1" summary="simple pre-edit text style, typically underlined"/>
      <entry name="selection" value="2"
        summary="hint for a selected piece of text, e.g. per-character navigation and composition"/>
      <entry name="prediction" value="3" summary="predicted text, not typed by the user"/>
      <entry name="prefix" value="4"
        summary="prefixed text not being currently edited, e.g. prior to a 'selection' section"/>
      <entry name="suffix" value="5"
        summary="suffixed text not being currently edited, e.g. after a 'selection' section"/>
      <entry name="spelling_error" value="6" summary="spelling error"/>
      <entry name="compose_error" value="7"
        summary="wrong composition, e.g. user input that can not be transliterated"/>
    </enum>
    <event name="preedit_hint" since="2">
      <description summary="pre-edit">
        Notify of contextual hints for the pre-edit string. This
        event is always sent together with a zwp_text_input_v3.preedit_string
        event.
        The parameters start and end are counted in bytes relative to the
        beginning of the text buffer submitted through
        zwp_text_input_v3.preedit_string, and represent the substring in the
        pre-edit text affected by the hint.
        Multiple events may be submitted if the preedit string has different
        sections. The extent of hints may overlap. The parts of the preedit
        string that are not covered by any zwp_text_input_v3.preedit_hint event,
        the text will be considered unhinted. This is also the case if no
        preedit_hint event is sent.
        Clients should provide recognizable visuals to these hints. if they are
        unable to comply with this requisition, it may be preferable for them
        keep the preedit_shown content hint disabled.
        Values set with this event are double-buffered. They must be applied
        and reset on the next zwp_text_input_v3.done event.
      </description>
      <arg name="start" type="uint" summary="starting point of the affected substring"/>
      <arg name="end" type="uint" summary="end point of the affected substring"/>
      <arg name="hint" type="uint" enum="preedit_hint" summary="hint to apply"/>
    </event>
  </interface>
-  <interface name="zwp_text_input_manager_v3" version="2">
+  <interface name="zwp_text_input_manager_v3" version="1">
    <description summary="text input manager">
      A factory for text-input objects. This object is a global singleton.
    </description>
--- a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
+++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
@ -23,7 +23,7 @@
    DEALINGS IN THE SOFTWARE.
  </copyright>
-  <interface name="zxdg_decoration_manager_v1" version="2">
+  <interface name="zxdg_decoration_manager_v1" version="1">
    <description summary="window decoration manager">
      This interface allows a compositor to announce support for server-side
      decorations.
@ -60,33 +60,18 @@
      <description summary="create a new toplevel decoration object">
        Create a new decoration object associated with the given toplevel.
-        For objects of version 1, creating an xdg_toplevel_decoration from an
+        Creating an xdg_toplevel_decoration from an xdg_toplevel which has a
-        xdg_toplevel which has a buffer attached or committed is a client
+        buffer attached or committed is a client error, and any attempts by a
-        error, and any attempts by a client to attach or manipulate a buffer
+        client to attach or manipulate a buffer prior to the first
-        prior to the first xdg_toplevel_decoration.configure event must also be
+        xdg_toplevel_decoration.configure event must also be treated as
-        treated as errors.
+        errors.
        For objects of version 2 or newer, creating an xdg_toplevel_decoration
        from an xdg_toplevel which has a buffer attached or committed is
        allowed. The initial decoration mode of the surface if a buffer is
        already attached depends on whether a xdg_toplevel_decoration object
        has been associated with the surface or not prior to this request.
        If an xdg_toplevel_decoration was associated with the surface, then
        destroyed without a surface commit, the previous decoration mode is
        retained.
        If no xdg_toplevel_decoration was associated with the surface prior to
        this request, or if a surface commit has been performed after a previous
        xdg_toplevel_decoration object associated with the surface was
        destroyed, the decoration mode is assumed to be client-side.
      </description>
      <arg name="id" type="new_id" interface="zxdg_toplevel_decoration_v1"/>
      <arg name="toplevel" type="object" interface="xdg_toplevel"/>
    </request>
  </interface>
-  <interface name="zxdg_toplevel_decoration_v1" version="2">
+  <interface name="zxdg_toplevel_decoration_v1" version="1">
    <description summary="decoration object for a toplevel surface">
      The decoration object allows the compositor to toggle server-side window
      decorations for a toplevel surface. The client can request to switch to
@ -109,8 +94,7 @@
    <request name="destroy" type="destructor">
      <description summary="destroy the decoration object">
        Switch back to a mode without any server-side decorations at the next
-        commit, unless a new xdg_toplevel_decoration is created for the surface
+        commit.
        first.
      </description>
    </request>
--- a/wayland-protocols-uninstalled.pc.in
+++ b/wayland-protocols-uninstalled.pc.in
@ -0,0 +1,5 @@
 pkgdatadir=@abs_top_srcdir@
 Name: Wayland Protocols
 Description: Wayland protocol files (not installed)
 Version: @WAYLAND_PROTOCOLS_VERSION@
--- a/wayland-protocols.pc.in
+++ b/wayland-protocols.pc.in
@ -0,0 +1,8 @@
 prefix=@prefix@
 includedir=@includedir@
 datarootdir=@datarootdir@
 pkgdatadir=${pc_sysrootdir}${datarootdir}/@PACKAGE@
 Name: Wayland Protocols
 Description: Wayland protocol files
 Version: @WAYLAND_PROTOCOLS_VERSION@