22 files changed, 10822 insertions, 0 deletions
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/alpha-modifier-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/alpha-modifier-v1.xml
new file mode 100644
index 0000000..932fa6f
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/alpha-modifier-v1.xml
@@ -0,0 +1,103 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="alpha_modifier_v1">
+  <copyright>
+    Copyright © 2024 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>
+  <interface name="wp_alpha_modifier_v1" version="1">
+    <description summary="surface alpha modifier manager">
+      This interface allows a client to set a factor for the alpha values on a
+      surface, which can be used to offload such operations to the compositor,
+      which can in turn for example offload them to KMS.
+      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>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the alpha modifier manager object">
+        Destroy the alpha modifier manager. This doesn't destroy objects
+        created with the manager.
+      </description>
+    </request>
+    <enum name="error">
+      <entry name="already_constructed" value="0"
+             summary="wl_surface already has a alpha modifier object"/>
+    </enum>
+    <request name="get_surface">
+      <description summary="create a new toplevel decoration object">
+        Create a new alpha modifier surface object associated with the
+        given wl_surface. If there is already such an object associated with
+        the wl_surface, the already_constructed error will be raised.
+      </description>
+      <arg name="id" type="new_id" interface="wp_alpha_modifier_surface_v1"/>
+      <arg name="surface" type="object" interface="wl_surface"/>
+    </request>
+  </interface>
+  <interface name="wp_alpha_modifier_surface_v1" version="1">
+    <description summary="alpha modifier object for a surface">
+      This interface allows the client to set a factor for the alpha values on
+      a surface, which can be used to offload such operations to the compositor.
+      The default factor is UINT32_MAX.
+      This object has to be destroyed before the associated wl_surface. Once the
+      wl_surface is destroyed, all request on this object will raise the
+      no_surface error.
+    </description>
+    <enum name="error">
+      <entry name="no_surface" value="0" summary="wl_surface was destroyed"/>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the alpha modifier object">
+        This destroys the object, and is equivalent to set_multiplier with
+        a value of UINT32_MAX, with the same double-buffered semantics as
+        set_multiplier.
+      </description>
+    </request>
+    <request name="set_multiplier">
+      <description summary="specify the alpha multiplier">
+        Sets the alpha multiplier for the surface. The alpha multiplier is
+        double-buffered state, see wl_surface.commit for details.
+        This factor is applied in the compositor's blending space, as an
+        additional step after the processing of per-pixel alpha values for the
+        wl_surface. The exact meaning of the factor is thus undefined, unless
+        the blending space is specified in a different extension.
+        This multiplier is applied even if the buffer attached to the
+        wl_surface doesn't have an alpha channel; in that case an alpha value
+        of one is used instead.
+        Zero means completely transparent, UINT32_MAX means completely opaque.
+      </description>
+      <arg name="factor" type="uint"/>
+    </request>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/color-management-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/color-management-v1.xml
new file mode 100644
index 0000000..7f8da78
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/color-management-v1.xml
@@ -0,0 +1,1631 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="color_management_v1">
+  <copyright>
+    Copyright 2019 Sebastian Wick
+    Copyright 2019 Erwin Burema
+    Copyright 2020 AMD
+    Copyright 2020-2024 Collabora, Ltd.
+    Copyright 2024 Xaver Hugl
+    Copyright 2022-2025 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="color management protocol">
+    The aim of the color management extension is to allow clients to know
+    the color properties of outputs, and to tell the compositor about the color
+    properties of their content on surfaces. Doing this enables a compositor
+    to perform automatic color management of content for different outputs
+    according to how content is intended to look like.
+    The color properties are represented as an image description object which
+    is immutable after it has been created. A wl_output always has an
+    associated image description that clients can observe. A wl_surface
+    always has an associated preferred image description as a hint chosen by
+    the compositor that clients can also observe. Clients can set an image
+    description on a wl_surface to denote the color characteristics of the
+    surface contents.
+    An image description includes SDR and HDR colorimetry and encoding, HDR
+    metadata, and viewing environment parameters. An image description does
+    not include the properties set through color-representation extension.
+    It is expected that the color-representation extension is used in
+    conjunction with the color management extension when necessary,
+    particularly with the YUV family of pixel formats.
+    Recommendation ITU-T H.273
+    "Coding-independent code points for video signal type identification"
+    shall be referred to as simply H.273 here.
+    The color-and-hdr repository
+    (https://gitlab.freedesktop.org/pq/color-and-hdr) contains
+    background information on the protocol design and legacy color management.
+    It also contains a glossary, learning resources for digital color, tools,
+    samples and more.
+    The terminology used in this protocol is based on common color science and
+    color encoding terminology where possible. The glossary in the color-and-hdr
+    repository shall be the authority on the definition of terms in this
+    protocol.
+    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="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
+      image description objects. The extension interfaces allow
+      getting the image description of outputs and setting the image
+      description of surfaces.
+      Compositors should never remove this global.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the color manager">
+        Destroy the wp_color_manager_v1 object. This does not affect any other
+        objects in any way.
+      </description>
+    </request>
+    <enum name="error">
+      <entry name="unsupported_feature" value="0"
+             summary="request not supported"/>
+      <entry name="surface_exists" value="1"
+             summary="color management surface exists already"/>
+    </enum>
+    <enum name="render_intent">
+      <description summary="rendering intents">
+        See the ICC.1:2022 specification from the International Color Consortium
+        for more details about rendering intents.
+        The principles of ICC defined rendering intents apply with all types of
+        image descriptions, not only those with ICC file profiles.
+        Compositors must support the perceptual rendering intent. Other
+        rendering intents are optional.
+      </description>
+      <entry name="perceptual" value="0"
+             summary="perceptual"/>
+      <entry name="relative" value="1"
+             summary="media-relative colorimetric"/>
+      <entry name="saturation" value="2"
+             summary="saturation"/>
+      <entry name="absolute" value="3"
+             summary="ICC-absolute colorimetric"/>
+      <entry name="relative_bpc" value="4"
+             summary="media-relative colorimetric + black point compensation"/>
+    </enum>
+    <enum name="feature">
+      <description summary="compositor supported features"/>
+      <entry name="icc_v2_v4" value="0"
+             summary="create_icc_creator request"/>
+      <entry name="parametric" value="1"
+             summary="create_parametric_creator request"/>
+      <entry name="set_primaries" value="2"
+             summary="parametric set_primaries request"/>
+      <entry name="set_tf_power" value="3"
+             summary="parametric set_tf_power request"/>
+      <entry name="set_luminances" value="4"
+             summary="parametric set_luminances request"/>
+      <entry name="set_mastering_display_primaries" value="5">
+        <description summary="parametric set_mastering_display_primaries request">
+          The compositor supports set_mastering_display_primaries request with a
+          target color volume fully contained inside the primary color volume.
+        </description>
+      </entry>
+      <entry name="extended_target_volume" value="6">
+        <description summary="parametric target exceeds primary color volume">
+          The compositor additionally supports target color volumes that
+          extend outside of the primary color volume.
+          This can only be advertised if feature set_mastering_display_primaries
+          is supported as well.
+        </description>
+      </entry>
+      <entry name="windows_scrgb" value="7"
+             summary="get_windows_scrgb request"/>
+    </enum>
+    <enum name="primaries">
+      <description summary="named color primaries">
+        Named color primaries used to encode well-known sets of primaries. H.273
+        is the authority, when it comes to the exact values of primaries and
+        authoritative specifications, where an equivalent code point exists.
+        A value of 0 is invalid and will never be present in the list of enums.
+        Descriptions do list the specifications for convenience.
+      </description>
+      <entry name="srgb" value="1">
+        <description summary="Color primaries for the sRGB color space as defined by the BT.709 standard">
+          Color primaries as defined by
+          - Rec. ITU-R BT.709-6
+          - Rec. ITU-R BT.1361-0 conventional colour gamut system and extended
+            colour gamut system (historical)
+          - IEC 61966-2-1 sRGB or sYCC
+          - IEC 61966-2-4
+          - Society of Motion Picture and Television Engineers (SMPTE) RP 177
+            (1993) Annex B
+          Equivalent to H.273 ColourPrimaries code point 1.
+        </description>
+      </entry>
+      <entry name="pal_m" value="2">
+        <description summary="Color primaries for PAL-M as defined by the BT.470 standard">
+          Color primaries as defined by
+          - Rec. ITU-R BT.470-6 System M (historical)
+          - United States National Television System Committee 1953
+            Recommendation for transmission standards for color television
+          - United States Federal Communications Commission (2003) Title 47 Code
+            of Federal Regulations 73.682 (a)(20)
+          Equivalent to H.273 ColourPrimaries code point 4.
+        </description>
+      </entry>
+      <entry name="pal" value="3">
+        <description summary="Color primaries for PAL as defined by the BT.601 standard">
+          Color primaries as defined by
+          - Rec. ITU-R BT.470-6 System B, G (historical)
+          - Rec. ITU-R BT.601-7 625
+          - Rec. ITU-R BT.1358-0 625 (historical)
+          - Rec. ITU-R BT.1700-0 625 PAL and 625 SECAM
+          Equivalent to H.273 ColourPrimaries code point 5.
+        </description>
+      </entry>
+      <entry name="ntsc" value="4">
+        <description summary="Color primaries for NTSC as defined by the BT.601 standard">
+          Color primaries as defined by
+          - Rec. ITU-R BT.601-7 525
+          - Rec. ITU-R BT.1358-1 525 or 625 (historical)
+          - Rec. ITU-R BT.1700-0 NTSC
+          - SMPTE 170M (2004)
+          - SMPTE 240M (1999) (historical)
+          Equivalent to H.273 ColourPrimaries code point 6 and 7.
+        </description>
+      </entry>
+      <entry name="generic_film" value="5">
+        <description summary="Generic film with colour filters using Illuminant C">
+          Color primaries as defined by H.273 for generic film.
+          Equivalent to H.273 ColourPrimaries code point 8.
+        </description>
+      </entry>
+      <entry name="bt2020" value="6">
+        <description summary="Color primaries as defined by the BT.2020 and BT.2100 standard">
+          Color primaries as defined by
+          - Rec. ITU-R BT.2020-2
+          - Rec. ITU-R BT.2100-0
+          Equivalent to H.273 ColourPrimaries code point 9.
+        </description>
+      </entry>
+      <entry name="cie1931_xyz" value="7">
+        <description summary="Color primaries of the full CIE 1931 XYZ color space">
+          Color primaries as defined as the maximum of the CIE 1931 XYZ color
+          space by
+          - SMPTE ST 428-1
+          - (CIE 1931 XYZ as in ISO 11664-1)
+          Equivalent to H.273 ColourPrimaries code point 10.
+        </description>
+      </entry>
+      <entry name="dci_p3" value="8">
+        <description summary="Color primaries of the DCI P3 color space as defined by the SMPTE RP 431 standard">
+          Color primaries as defined by Digital Cinema System and published in
+          SMPTE RP 431-2 (2011). Equivalent to H.273 ColourPrimaries code point
+          11.
+        </description>
+      </entry>
+      <entry name="display_p3" value="9">
+        <description summary="Color primaries of Display P3 variant of the DCI-P3 color space as defined by the SMPTE EG 432 standard">
+          Color primaries as defined by Digital Cinema System and published in
+          SMPTE EG 432-1 (2010).
+          Equivalent to H.273 ColourPrimaries code point 12.
+        </description>
+      </entry>
+      <entry name="adobe_rgb" value="10">
+        <description summary="Color primaries of the Adobe RGB color space as defined by the ISO 12640 standard">
+          Color primaries as defined by Adobe as "Adobe RGB" and later published
+          by ISO 12640-4 (2011).
+        </description>
+      </entry>
+    </enum>
+    <enum name="transfer_function">
+      <description summary="named transfer functions">
+        Named transfer functions used to represent well-known transfer
+        characteristics. H.273 is the authority, when it comes to the exact
+        formulas and authoritative specifications, where an equivalent code
+        point exists.
+        A value of 0 is invalid and will never be present in the list of enums.
+        Descriptions do list the specifications for convenience.
+      </description>
+      <entry name="bt1886" value="1">
+        <description summary="BT.1886 display transfer characteristic">
+          Rec. ITU-R BT.1886 is the display transfer characteristic assumed by
+          - Rec. ITU-R BT.601-7 525 and 625
+          - Rec. ITU-R BT.709-6
+          - Rec. ITU-R BT.2020-2
+          These recommendations are referred to by H.273 TransferCharacteristics
+          code points 1, 6, 14, and 15, which are all equivalent.
+          This TF implies these default luminances from Rec. ITU-R BT.2035:
+          - primary color volume minimum: 0.01 cd/m²
+          - primary color volume maximum: 100 cd/m²
+          - reference white: 100 cd/m²
+        </description>
+      </entry>
+      <entry name="gamma22" value="2">
+        <description summary="Assumed display gamma 2.2 transfer function">
+          Transfer characteristics as defined by
+          - Rec. ITU-R BT.470-6 System M (historical)
+          - United States National Television System Committee 1953
+            Recommendation for transmission standards for color television
+          - 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
+          Equivalent to H.273 TransferCharacteristics code point 4.
+        </description>
+      </entry>
+      <entry name="gamma28" value="3">
+        <description summary="Assumed display gamma 2.8 transfer function">
+          Transfer characteristics as defined by
+          - Rec. ITU-R BT.470-6 System B, G (historical)
+          Equivalent to H.273 TransferCharacteristics code point 5.
+        </description>
+      </entry>
+      <entry name="st240" value="4">
+        <description summary="SMPTE ST 240 transfer function">
+          Transfer characteristics as defined by
+          - SMPTE ST 240 (1999)
+          Equivalent to H.273 TransferCharacteristics code point 7.
+        </description>
+      </entry>
+      <entry name="ext_linear" value="5">
+        <description summary="extended linear transfer function">
+          Linear transfer function defined over all real numbers.
+          Normalised electrical values are equal the normalised optical values.
+          The differences to H.273 TransferCharacteristics code point 8 are
+          the definition over all real numbers.
+        </description>
+      </entry>
+      <entry name="log_100" value="6">
+        <description summary="logarithmic 100:1 transfer function">
+          Logarithmic transfer characteristic (100:1 range).
+          Equivalent to H.273 TransferCharacteristics code point 9.
+        </description>
+      </entry>
+      <entry name="log_316" value="7">
+        <description summary="logarithmic (100*Sqrt(10) : 1) transfer function">
+          Logarithmic transfer characteristic (100 * Sqrt(10) : 1 range).
+          Equivalent to H.273 TransferCharacteristics code point 10.
+        </description>
+      </entry>
+      <entry name="xvycc" value="8">
+        <description summary="IEC 61966-2-4 transfer function">
+          Transfer characteristics as defined by
+          - IEC 61966-2-4
+          Equivalent to H.273 TransferCharacteristics code point 11.
+        </description>
+      </entry>
+      <entry name="srgb" value="9">
+        <description summary="sRGB piece-wise transfer function">
+          Transfer characteristics as defined by
+          - IEC 61966-2-1 sRGB
+          Equivalent to H.273 TransferCharacteristics code point 13 with
+          MatrixCoefficients set to 0.
+        </description>
+      </entry>
+      <entry name="ext_srgb" value="10">
+        <description summary="Extended sRGB piece-wise transfer function">
+          Transfer characteristics as defined by
+          - IEC 61966-2-1 sYCC
+          Equivalent to H.273 TransferCharacteristics code point 13 with
+          MatrixCoefficients set to anything but 0.
+        </description>
+      </entry>
+      <entry name="st2084_pq" value="11">
+        <description summary="perceptual quantizer transfer function">
+          Transfer characteristics as defined by
+          - SMPTE ST 2084 (2014) for 10-, 12-, 14- and 16-bit systems
+          - Rec. ITU-R BT.2100-2 perceptual quantization (PQ) system
+          Equivalent to H.273 TransferCharacteristics code point 16.
+          This TF implies these default luminances
+          - primary color volume minimum: 0.005 cd/m²
+          - primary color volume maximum: 10000 cd/m²
+          - reference white: 203 cd/m²
+          The difference between the primary color volume minimum and maximum
+          must be approximately 10000 cd/m² as that is the swing of the EOTF
+          defined by ST 2084 and BT.2100. The default value for the
+          reference white is a protocol addition: it is suggested by
+          Report ITU-R BT.2408-7 and is not part of ST 2084 or BT.2100.
+        </description>
+      </entry>
+      <entry name="st428" value="12">
+        <description summary="SMPTE ST 428 transfer function">
+          Transfer characteristics as defined by
+          - SMPTE ST 428-1 (2019)
+          Equivalent to H.273 TransferCharacteristics code point 17.
+        </description>
+      </entry>
+      <entry name="hlg" value="13">
+        <description summary="hybrid log-gamma transfer function">
+          Transfer characteristics as defined by
+          - ARIB STD-B67 (2015)
+          - Rec. ITU-R BT.2100-2 hybrid log-gamma (HLG) system
+          Equivalent to H.273 TransferCharacteristics code point 18.
+          This TF implies these default luminances
+          - primary color volume minimum: 0.005 cd/m²
+          - primary color volume maximum: 1000 cd/m²
+          - reference white: 203 cd/m²
+          HLG is a relative display-referred signal with a specified
+          non-linear mapping to the display peak luminance (the HLG OOTF).
+          All absolute luminance values used here for HLG assume a 1000 cd/m²
+          peak display.
+          The default value for the reference white is a protocol addition:
+          it is suggested by Report ITU-R BT.2408-7 and is not part of
+          ARIB STD-B67 or BT.2100.
+        </description>
+      </entry>
+    </enum>
+    <request name="get_output">
+      <description summary="create a color management interface for a wl_output">
+        This creates a new wp_color_management_output_v1 object for the
+        given wl_output.
+        See the wp_color_management_output_v1 interface for more details.
+      </description>
+      <arg name="id" type="new_id" interface="wp_color_management_output_v1"/>
+      <arg name="output" type="object" interface="wl_output"/>
+    </request>
+    <request name="get_surface">
+      <description summary="create a color management interface for a wl_surface">
+        If a wp_color_management_surface_v1 object already exists for the given
+        wl_surface, the protocol error surface_exists is raised.
+        This creates a new color wp_color_management_surface_v1 object for the
+        given wl_surface.
+        See the wp_color_management_surface_v1 interface for more details.
+      </description>
+      <arg name="id" type="new_id" interface="wp_color_management_surface_v1"/>
+      <arg name="surface" type="object" interface="wl_surface"/>
+    </request>
+    <request name="get_surface_feedback">
+      <description summary="create a color management feedback interface">
+        This creates a new color wp_color_management_surface_feedback_v1 object
+        for the given wl_surface.
+        See the wp_color_management_surface_feedback_v1 interface for more
+        details.
+      </description>
+      <arg name="id" type="new_id"
+           interface="wp_color_management_surface_feedback_v1"/>
+      <arg name="surface" type="object" interface="wl_surface"/>
+    </request>
+    <request name="create_icc_creator">
+      <description summary="make a new ICC-based image description creator object">
+        Makes a new ICC-based image description creator object with all
+        properties initially unset. The client can then use the object's
+        interface to define all the required properties for an image description
+        and finally create a wp_image_description_v1 object.
+        This request can be used when the compositor advertises
+        wp_color_manager_v1.feature.icc_v2_v4.
+        Otherwise this request raises the protocol error unsupported_feature.
+      </description>
+      <arg name="obj"
+           type="new_id" interface="wp_image_description_creator_icc_v1"
+           summary="the new creator object"/>
+    </request>
+    <request name="create_parametric_creator">
+      <description summary="make a new parametric image description creator object">
+        Makes a new parametric image description creator object with all
+        properties initially unset. The client can then use the object's
+        interface to define all the required properties for an image description
+        and finally create a wp_image_description_v1 object.
+        This request can be used when the compositor advertises
+        wp_color_manager_v1.feature.parametric.
+        Otherwise this request raises the protocol error unsupported_feature.
+      </description>
+      <arg name="obj"
+           type="new_id" interface="wp_image_description_creator_params_v1"
+           summary="the new creator object"/>
+    </request>
+    <request name="create_windows_scrgb">
+      <description summary="create Windows-scRGB image description object">
+        This creates a pre-defined image description for the so-called
+        Windows-scRGB stimulus encoding. This comes from the Windows 10 handling
+        of its own definition of an scRGB color space for an HDR screen
+        driven in BT.2100/PQ signalling mode.
+        Windows-scRGB uses sRGB (BT.709) color primaries and white point.
+        The transfer characteristic is extended linear.
+        The nominal color channel value range is extended, meaning it includes
+        negative and greater than 1.0 values. Negative values are used to
+        escape the sRGB color gamut boundaries. To make use of the extended
+        range, the client needs to use a pixel format that can represent those
+        values, e.g. floating-point 16 bits per channel.
+        Nominal color value R=G=B=0.0 corresponds to BT.2100/PQ system
+        0 cd/m², and R=G=B=1.0 corresponds to BT.2100/PQ system 80 cd/m².
+        The maximum is R=G=B=125.0 corresponding to 10k cd/m².
+        Windows-scRGB is displayed by Windows 10 by converting it to
+        BT.2100/PQ, maintaining the CIE 1931 chromaticity and mapping the
+        luminance as above. No adjustment is made to the signal to account
+        for the viewing conditions.
+        The reference white level of Windows-scRGB is unknown. If a
+        reference white level must be assumed for compositor processing, it
+        should be R=G=B=2.5375 corresponding to 203 cd/m² of Report ITU-R
+        BT.2408-7.
+        The target color volume of Windows-scRGB is unknown. The color gamut
+        may be anything between sRGB and BT.2100.
+        Note: EGL_EXT_gl_colorspace_scrgb_linear definition differs from
+        Windows-scRGB by using R=G=B=1.0 as the reference white level, while
+        Windows-scRGB reference white level is unknown or varies. However,
+        it seems probable that Windows implements both
+        EGL_EXT_gl_colorspace_scrgb_linear and Vulkan
+        VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT as Windows-scRGB.
+        This request can be used when the compositor advertises
+        wp_color_manager_v1.feature.windows_scrgb.
+        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>
+    <event name="supported_intent">
+      <description summary="supported rendering intent">
+        When this object is created, it shall immediately send this event once
+        for each rendering intent the compositor supports.
+      </description>
+      <arg name="render_intent" type="uint" enum="render_intent"
+           summary="rendering intent"/>
+    </event>
+    <event name="supported_feature">
+      <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.
+      </description>
+      <arg name="feature" type="uint" enum="feature"
+           summary="supported feature"/>
+    </event>
+    <event name="supported_tf_named">
+      <description summary="supported named transfer characteristic">
+        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.
+      </description>
+      <arg name="tf" type="uint" enum="transfer_function"
+           summary="Named transfer function"/>
+    </event>
+    <event name="supported_primaries_named">
+      <description summary="supported named primaries">
+        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.
+      </description>
+      <arg name="primaries" type="uint" enum="primaries"
+           summary="Named color primaries"/>
+    </event>
+    <event name="done">
+      <description summary="all features have been sent">
+        This event is sent when all supported rendering intents, features,
+        transfer functions and named primaries have been sent.
+      </description>
+    </event>
+  </interface>
+  <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.
+      The wp_color_management_output_v1 is associated with the wl_output global
+      underlying the wl_output object. Therefore the client destroying the
+      wl_output object has no impact, but the compositor removing the output
+      global makes the wp_color_management_output_v1 object inert.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the color management output">
+        Destroy the color wp_color_management_output_v1 object. This does not
+        affect any remaining protocol objects.
+      </description>
+    </request>
+    <event name="image_description_changed">
+      <description summary="image description changed">
+        This event is sent whenever the image description of the output changed,
+        followed by one wl_output.done event common to output events across all
+        extensions.
+        If the client wants to use the updated image description, it needs to do
+        get_image_description again, because image description objects are
+        immutable.
+      </description>
+    </event>
+    <request name="get_image_description">
+      <description summary="get the image description of the output">
+        This creates a new wp_image_description_v1 object for the current image
+        description of the output. There always is exactly one image description
+        active for an output so the client should destroy the image description
+        created by earlier invocations of this request. This request is usually
+        sent as a reaction to the image_description_changed event or when
+        creating a wp_color_management_output_v1 object.
+        The image description of an output represents the color encoding the
+        output expects. There might be performance and power advantages, as well
+        as improved color reproduction, if a content update matches the image
+        description of the output it is being shown on. If a content update is
+        shown on any other output than the one it matches the image description
+        of, then the color reproduction on those outputs might be considerably
+        worse.
+        The created wp_image_description_v1 object preserves the image
+        description of the output from the time the object was created.
+        The resulting image description object allows get_information request.
+        If this protocol object is inert, the resulting image description object
+        shall immediately deliver the wp_image_description_v1.failed event with
+        the no_output cause.
+        If the interface version is inadequate for the output's image
+        description, meaning that the client does not support all the events
+        needed to deliver the crucial information, the resulting image
+        description object shall immediately deliver the
+        wp_image_description_v1.failed event with the low_version cause.
+        Otherwise the object shall immediately deliver the ready event.
+      </description>
+      <arg name="image_description"
+           type="new_id" interface="wp_image_description_v1"/>
+    </request>
+  </interface>
+  <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.
+        If the wl_surface associated with the wp_color_management_surface_v1 is
+        destroyed, the wp_color_management_surface_v1 object becomes inert.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the color management interface for a surface">
+        Destroy the wp_color_management_surface_v1 object and do the same as
+        unset_image_description.
+      </description>
+    </request>
+    <enum name="error">
+      <description summary="protocol errors"/>
+      <entry name="render_intent" value="0"
+             summary="unsupported rendering intent"/>
+      <entry name="image_description" value="1"
+             summary="invalid image description"/>
+      <entry name="inert" value="2"
+             summary="forbidden request on inert object"/>
+    </enum>
+    <request name="set_image_description">
+      <description summary="set the surface image description">
+        If this protocol object is inert, the protocol error inert is raised.
+        Set the image description of the underlying surface. The image
+        description and rendering intent are double-buffered state, see
+        wl_surface.commit.
+        It is the client's responsibility to understand the image description
+        it sets on a surface, and to provide content that matches that image
+        description. Compositors might convert images to match their own or any
+        other image descriptions.
+        Image descriptions which are not ready (see wp_image_description_v1)
+        are forbidden in this request, and in such case the protocol error
+        image_description is raised.
+        All image descriptions which are ready (see wp_image_description_v1)
+        are allowed and must always be accepted by the compositor.
+        A rendering intent provides the client's preference on how content
+        colors should be mapped to each output. The render_intent value must
+        be one advertised by the compositor with
+        wp_color_manager_v1.render_intent event, otherwise the protocol error
+        render_intent is raised.
+        When an image description is set on a surface, the Transfer
+        Characteristics of the image description defines the valid range of
+        the nominal (real-valued) color channel values. The processing of
+        out-of-range color channel values is undefined, but compositors are
+        recommended to clamp the values to the valid range when possible.
+        By default, a surface does not have an associated image description
+        nor a rendering intent. The handling of color on such surfaces is
+        compositor implementation defined. Compositors should handle such
+        surfaces as sRGB, but may handle them differently if they have specific
+        requirements.
+        Setting the image description has copy semantics; after this request,
+        the image description can be immediately destroyed without affecting
+        the pending state of the surface.
+      </description>
+      <arg name="image_description"
+           type="object" interface="wp_image_description_v1"/>
+      <arg name="render_intent"
+           type="uint" enum="wp_color_manager_v1.render_intent"
+           summary="rendering intent"/>
+    </request>
+    <request name="unset_image_description">
+      <description summary="remove the surface image description">
+        If this protocol object is inert, the protocol error inert is raised.
+        This request removes any image description from the surface. See
+        set_image_description for how a compositor handles a surface without
+        an image description. This is double-buffered state, see
+        wl_surface.commit.
+      </description>
+    </request>
+  </interface>
+  <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.
+        If the wl_surface associated with this object is destroyed, the
+        wp_color_management_surface_feedback_v1 object becomes inert.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the color management interface for a surface">
+        Destroy the wp_color_management_surface_feedback_v1 object.
+      </description>
+    </request>
+    <enum name="error">
+      <description summary="protocol errors"/>
+      <entry name="inert" value="0"
+             summary="forbidden request on inert object"/>
+      <entry name="unsupported_feature" value="1"
+             summary="attempted to use an unsupported feature"/>
+    </enum>
+    <event name="preferred_changed">
+      <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" type="uint" summary="image description id number"/>
+    </event>
+    <request name="get_preferred">
+      <description summary="get the preferred image description">
+        If this protocol object is inert, the protocol error inert is raised.
+        The preferred image description represents the compositor's preferred
+        color encoding for this wl_surface at the current time. There might be
+        performance and power advantages, as well as improved color
+        reproduction, if the image description of a content update matches the
+        preferred image description.
+        This creates a new wp_image_description_v1 object for the currently
+        preferred image description for the wl_surface. The client should
+        stop using and destroy the image descriptions created by earlier
+        invocations of this request for the associated wl_surface.
+        This request is usually sent as a reaction to the preferred_changed
+        event or when creating a wp_color_management_surface_feedback_v1 object
+        if the client is capable of adapting to image descriptions.
+        The created wp_image_description_v1 object preserves the preferred image
+        description of the wl_surface from the time the object was created.
+        The resulting image description object allows get_information request.
+        If the image description is parametric, the client should set it on its
+        wl_surface only if the image description is an exact match with the
+        client content. Particularly if everything else matches, but the target
+        color volume is greater than what the client needs, the client should
+        create its own parameric image description with its exact parameters.
+        If the interface version is inadequate for the preferred image
+        description, meaning that the client does not support all the
+        events needed to deliver the crucial information, the resulting image
+        description object shall immediately deliver the
+        wp_image_description_v1.failed event with the low_version cause,
+        otherwise the object shall immediately deliver the ready event.
+      </description>
+      <arg name="image_description"
+           type="new_id" interface="wp_image_description_v1"/>
+    </request>
+    <request name="get_preferred_parametric">
+      <description summary="get the preferred image description">
+        The same description as for get_preferred applies, except the returned
+        image description is guaranteed to be parametric. This is meant for
+        clients that can only deal with parametric image descriptions.
+        If the compositor doesn't support parametric image descriptions, the
+        unsupported_feature error is emitted.
+      </description>
+      <arg name="image_description"
+           type="new_id" interface="wp_image_description_v1"/>
+    </request>
+  </interface>
+  <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
+      set of required parameters consists of these properties:
+      - ICC file
+      Each required property must be set exactly once if the client is to create
+      an image description. The set requests verify that a property was not
+      already set. The create request verifies that all required properties are
+      set. There may be several alternative requests for setting each property,
+      and in that case the client must choose one of them.
+      Once all properties have been set, the create request must be used to
+      create the image description object, destroying the creator in the
+      process.
+    </description>
+    <enum name="error">
+      <description summary="protocol errors"/>
+      <entry name="incomplete_set" value="0"
+             summary="incomplete parameter set"/>
+      <entry name="already_set" value="1"
+             summary="property already set"/>
+      <entry name="bad_fd" value="2"
+             summary="fd not seekable and readable"/>
+      <entry name="bad_size" value="3"
+             summary="no or too much data"/>
+      <entry name="out_of_file" value="4"
+             summary="offset + length exceeds file size"/>
+    </enum>
+    <request name="create" type="destructor">
+      <description summary="Create the image description object from ICC data">
+        Create an image description object based on the ICC information
+        previously set on this object. A compositor must parse the ICC data in
+        some undefined but finite amount of time.
+        The completeness of the parameter set is verified. If the set is not
+        complete, the protocol error incomplete_set is raised. For the
+        definition of a complete set, see the description of this interface.
+        If the particular combination of the information is not supported
+        by the compositor, the resulting image description object shall
+        immediately deliver the wp_image_description_v1.failed event with the
+        'unsupported' cause. If a valid image description was created from the
+        information, the wp_image_description_v1.ready event will eventually
+        be sent instead.
+        This request destroys the wp_image_description_creator_icc_v1 object.
+        The resulting image description object does not allow get_information
+        request.
+      </description>
+      <arg name="image_description"
+           type="new_id" interface="wp_image_description_v1"/>
+    </request>
+    <request name="set_icc_file">
+      <description summary="set the ICC profile file">
+        Sets the ICC profile file to be used as the basis of the image
+        description.
+        The data shall be found through the given fd at the given offset, having
+        the given length. The fd must be seekable and readable. Violating these
+        requirements raises the bad_fd protocol error.
+        If reading the data fails due to an error independent of the client, the
+        compositor shall send the wp_image_description_v1.failed event on the
+        created wp_image_description_v1 with the 'operating_system' cause.
+        The maximum size of the ICC profile is 32 MB. If length is greater than
+        that or zero, the protocol error bad_size is raised. If offset + length
+        exceeds the file size, the protocol error out_of_file is raised.
+        A compositor may read the file at any time starting from this request
+        and only until whichever happens first:
+        - If create request was issued, the wp_image_description_v1 object
+          delivers either failed or ready event; or
+        - if create request was not issued, this
+          wp_image_description_creator_icc_v1 object is destroyed.
+        A compositor shall not modify the contents of the file, and the fd may
+        be sealed for writes and size changes. The client must ensure to its
+        best ability that the data does not change while the compositor is
+        reading it.
+        The data must represent a valid ICC profile. The ICC profile version
+        must be 2 or 4, it must be a 3 channel profile and the class must be
+        Display or ColorSpace. Violating these requirements will not result in a
+        protocol error, but will eventually send the
+        wp_image_description_v1.failed event on the created
+        wp_image_description_v1 with the 'unsupported' cause.
+        See the International Color Consortium specification ICC.1:2022 for more
+        details about ICC profiles.
+        If ICC file has already been set on this object, the protocol error
+        already_set is raised.
+      </description>
+      <arg name="icc_profile" type="fd"
+           summary="ICC profile"/>
+      <arg name="offset" type="uint"
+           summary="byte offset in fd to start of ICC data"/>
+      <arg name="length" type="uint"
+           summary="length of ICC data in bytes"/>
+    </request>
+  </interface>
+  <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
+      parameters consists of these properties:
+      - transfer characteristic function (tf)
+      - chromaticities of primaries and white point (primary color volume)
+      The following properties are optional and have a well-defined default
+      if not explicitly set:
+      - primary color volume luminance range
+      - reference white luminance level
+      - mastering display primaries and white point (target color volume)
+      - mastering luminance range
+      The following properties are optional and will be ignored
+      if not explicitly set:
+      - maximum content light level
+      - maximum frame-average light level
+      Each required property must be set exactly once if the client is to create
+      an image description. The set requests verify that a property was not
+      already set. The create request verifies that all required properties are
+      set. There may be several alternative requests for setting each property,
+      and in that case the client must choose one of them.
+      Once all properties have been set, the create request must be used to
+      create the image description object, destroying the creator in the
+      process.
+    </description>
+    <enum name="error">
+      <description summary="protocol errors"/>
+      <entry name="incomplete_set" value="0"
+             summary="incomplete parameter set"/>
+      <entry name="already_set" value="1"
+             summary="property already set"/>
+      <entry name="unsupported_feature" value="2"
+             summary="request not supported"/>
+      <entry name="invalid_tf" value="3"
+             summary="invalid transfer characteristic"/>
+      <entry name="invalid_primaries_named" value="4"
+             summary="invalid primaries named"/>
+      <entry name="invalid_luminance" value="5"
+             summary="invalid luminance value or range"/>
+    </enum>
+    <request name="create" type="destructor">
+      <description summary="Create the image description object using params">
+        Create an image description object based on the parameters previously
+        set on this object.
+        The completeness of the parameter set is verified. If the set is not
+        complete, the protocol error incomplete_set is raised. For the
+        definition of a complete set, see the description of this interface.
+        The protocol error invalid_luminance is raised if any of the following
+        requirements is not met:
+        - 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
+        immediately deliver the wp_image_description_v1.failed event with the
+        'unsupported' cause. If a valid image description was created from the
+        parameter set, the wp_image_description_v1.ready event will eventually
+        be sent instead.
+        This request destroys the wp_image_description_creator_params_v1
+        object.
+        The resulting image description object does not allow get_information
+        request.
+      </description>
+      <arg name="image_description"
+           type="new_id" interface="wp_image_description_v1"/>
+    </request>
+    <request name="set_tf_named">
+      <description summary="named transfer characteristic">
+        Sets the transfer characteristic using explicitly enumerated named
+        functions.
+        When the resulting image description is attached to an image, the
+        content should be encoded and decoded according to the industry standard
+        practices for the transfer characteristic.
+        Only names advertised with wp_color_manager_v1 event supported_tf_named
+        are allowed. Other values shall raise the protocol error invalid_tf.
+        If transfer characteristic has already been set on this object, the
+        protocol error already_set is raised.
+      </description>
+      <arg name="tf" type="uint" enum="wp_color_manager_v1.transfer_function"
+           summary="named transfer function"/>
+    </request>
+    <request name="set_tf_power">
+      <description summary="transfer characteristic as a power curve">
+        Sets the color component transfer characteristic to a power curve with
+        the given exponent. Negative values are handled by mirroring the
+        positive half of the curve through the origin. The valid domain and
+        range of the curve are all finite real numbers. This curve represents
+        the conversion from electrical to optical color channel values.
+        When the resulting image description is attached to an image, the
+        content should be encoded with the inverse of the power curve.
+        The curve exponent shall be multiplied by 10000 to get the argument eexp
+        value to carry the precision of 4 decimals.
+        The curve exponent must be at least 1.0 and at most 10.0. Otherwise the
+        protocol error invalid_tf is raised.
+        If transfer characteristic has already been set on this object, the
+        protocol error already_set is raised.
+        This request can be used when the compositor advertises
+        wp_color_manager_v1.feature.set_tf_power. Otherwise this request raises
+        the protocol error unsupported_feature.
+      </description>
+      <arg name="eexp" type="uint" summary="the exponent * 10000"/>
+    </request>
+    <request name="set_primaries_named">
+      <description summary="named primaries">
+        Sets the color primaries and white point using explicitly named sets.
+        This describes the primary color volume which is the basis for color
+        value encoding.
+        Only names advertised with wp_color_manager_v1 event
+        supported_primaries_named are allowed. Other values shall raise the
+        protocol error invalid_primaries_named.
+        If primaries have already been set on this object, the protocol error
+        already_set is raised.
+      </description>
+      <arg name="primaries" type="uint" enum="wp_color_manager_v1.primaries"
+           summary="named primaries"/>
+    </request>
+    <request name="set_primaries">
+      <description summary="primaries as chromaticity coordinates">
+        Sets the color primaries and white point using CIE 1931 xy chromaticity
+        coordinates. This describes the primary color volume which is the basis
+        for color value encoding.
+        Each coordinate value is multiplied by 1 million to get the argument
+        value to carry precision of 6 decimals.
+        If primaries have already been set on this object, the protocol error
+        already_set is raised.
+        This request can be used if the compositor advertises
+        wp_color_manager_v1.feature.set_primaries. Otherwise this request raises
+        the protocol error unsupported_feature.
+      </description>
+      <arg name="r_x" type="int" summary="Red x * 1M"/>
+      <arg name="r_y" type="int" summary="Red y * 1M"/>
+      <arg name="g_x" type="int" summary="Green x * 1M"/>
+      <arg name="g_y" type="int" summary="Green y * 1M"/>
+      <arg name="b_x" type="int" summary="Blue x * 1M"/>
+      <arg name="b_y" type="int" summary="Blue y * 1M"/>
+      <arg name="w_x" type="int" summary="White x * 1M"/>
+      <arg name="w_y" type="int" summary="White y * 1M"/>
+    </request>
+    <request name="set_luminances">
+      <description summary="primary color volume luminance range and reference white">
+        Sets the primary color volume luminance range and the reference white
+        luminance level. These values include the minimum display emission
+        and ambient flare luminances, assumed to be optically additive and have
+        the chromaticity of the primary color volume white point.
+        The default luminances from
+        https://www.color.org/chardata/rgb/srgb.xalter are
+        - primary color volume minimum: 0.2 cd/m²
+        - primary color volume maximum: 80 cd/m²
+        - reference white: 80 cd/m²
+        Setting a named transfer characteristic can imply other default
+        luminances.
+        The default luminances get overwritten when this request is used.
+        With transfer_function.st2084_pq the given 'max_lum' value is ignored,
+        and 'max_lum' is taken as 'min_lum' + 10000 cd/m².
+        'min_lum' and 'max_lum' specify the minimum and maximum luminances of
+        the primary color volume as reproduced by the targeted display.
+        'reference_lum' specifies the luminance of the reference white as
+        reproduced by the targeted display, and reflects the targeted viewing
+        environment.
+        Compositors should make sure that all content is anchored, meaning that
+        an input signal level of 'reference_lum' on one image description and
+        another input signal level of 'reference_lum' on another image
+        description should produce the same output level, even though the
+        'reference_lum' on both image representations can be different.
+        'reference_lum' may be higher than 'max_lum'. In that case reaching
+        the reference white output level in image content requires the
+        'extended_target_volume' feature support.
+        If 'max_lum' or 'reference_lum' are less than or equal to 'min_lum',
+        the protocol error invalid_luminance is raised.
+        The minimum luminance is multiplied by 10000 to get the argument
+        'min_lum' value and carries precision of 4 decimals. The maximum
+        luminance and reference white luminance values are unscaled.
+        If the primary color volume luminance range and the reference white
+        luminance level have already been set on this object, the protocol error
+        already_set is raised.
+        This request can be used if the compositor advertises
+        wp_color_manager_v1.feature.set_luminances. Otherwise this request
+        raises the protocol error unsupported_feature.
+      </description>
+      <arg name="min_lum" type="uint"
+           summary="minimum luminance (cd/m²) * 10000"/>
+      <arg name="max_lum" type="uint"
+           summary="maximum luminance (cd/m²)"/>
+      <arg name="reference_lum" type="uint"
+           summary="reference white luminance (cd/m²)"/>
+    </request>
+    <request name="set_mastering_display_primaries">
+      <description summary="mastering display primaries as chromaticity coordinates">
+        Provides the color primaries and white point of the mastering display
+        using CIE 1931 xy chromaticity coordinates. This is compatible with the
+        SMPTE ST 2086 definition of HDR static metadata.
+        The mastering display primaries and mastering display luminances define
+        the target color volume.
+        If mastering display primaries are not explicitly set, the target color
+        volume is assumed to have the same primaries as the primary color volume.
+        The target color volume is defined by all tristimulus values between 0.0
+        and 1.0 (inclusive) of the color space defined by the given mastering
+        display primaries and white point. The colorimetry is identical between
+        the container color space and the mastering display color space,
+        including that no chromatic adaptation is applied even if the white
+        points differ.
+        The target color volume can exceed the primary color volume to allow for
+        a greater color volume with an existing color space definition (for
+        example scRGB). It can be smaller than the primary color volume to
+        minimize gamut and tone mapping distances for big color spaces (HDR
+        metadata).
+        To make use of the entire target color volume a suitable pixel format
+        has to be chosen (e.g. floating point to exceed the primary color
+        volume, or abusing limited quantization range as with xvYCC).
+        Each coordinate value is multiplied by 1 million to get the argument
+        value to carry precision of 6 decimals.
+        If mastering display primaries have already been set on this object, the
+        protocol error already_set is raised.
+        This request can be used if the compositor advertises
+        wp_color_manager_v1.feature.set_mastering_display_primaries. Otherwise
+        this request raises the protocol error unsupported_feature. The
+        advertisement implies support only for target color volumes fully
+        contained within the primary color volume.
+        If a compositor additionally supports target color volume exceeding the
+        primary color volume, it must advertise
+        wp_color_manager_v1.feature.extended_target_volume. If a client uses
+        target color volume exceeding the primary color volume and the
+        compositor does not support it, the result is implementation defined.
+        Compositors are recommended to detect this case and fail the image
+        description gracefully, but it may as well result in color artifacts.
+      </description>
+      <arg name="r_x" type="int" summary="Red x * 1M"/>
+      <arg name="r_y" type="int" summary="Red y * 1M"/>
+      <arg name="g_x" type="int" summary="Green x * 1M"/>
+      <arg name="g_y" type="int" summary="Green y * 1M"/>
+      <arg name="b_x" type="int" summary="Blue x * 1M"/>
+      <arg name="b_y" type="int" summary="Blue y * 1M"/>
+      <arg name="w_x" type="int" summary="White x * 1M"/>
+      <arg name="w_y" type="int" summary="White y * 1M"/>
+    </request>
+    <request name="set_mastering_luminance">
+      <description summary="display mastering luminance range">
+        Sets the luminance range that was used during the content mastering
+        process as the minimum and maximum absolute luminance L. These values
+        include the minimum display emission and ambient flare luminances,
+        assumed to be optically additive and have the chromaticity of the
+        primary color volume white point. This should be
+        compatible with the SMPTE ST 2086 definition of HDR static metadata.
+        The mastering display primaries and mastering display luminances define
+        the target color volume.
+        If mastering luminances are not explicitly set, the target color volume
+        is assumed to have the same min and max luminances as the primary color
+        volume.
+        If max L is less than or equal to min L, the protocol error
+        invalid_luminance is raised.
+        Min L value is multiplied by 10000 to get the argument min_lum value
+        and carry precision of 4 decimals. Max L value is unscaled for max_lum.
+        This request can be used if the compositor advertises
+        wp_color_manager_v1.feature.set_mastering_display_primaries. Otherwise
+        this request raises the protocol error unsupported_feature. The
+        advertisement implies support only for target color volumes fully
+        contained within the primary color volume.
+        If a compositor additionally supports target color volume exceeding the
+        primary color volume, it must advertise
+        wp_color_manager_v1.feature.extended_target_volume. If a client uses
+        target color volume exceeding the primary color volume and the
+        compositor does not support it, the result is implementation defined.
+        Compositors are recommended to detect this case and fail the image
+        description gracefully, but it may as well result in color artifacts.
+      </description>
+      <arg name="min_lum" type="uint" summary="min L (cd/m²) * 10000"/>
+      <arg name="max_lum" type="uint" summary="max L (cd/m²)"/>
+    </request>
+    <request name="set_max_cll">
+      <description summary="maximum content light level">
+        Sets the maximum content light level (max_cll) as defined by CTA-861-H.
+        max_cll is undefined by default.
+      </description>
+      <arg name="max_cll" type="uint" summary="Maximum content light level (cd/m²)"/>
+    </request>
+    <request name="set_max_fall">
+      <description summary="maximum frame-average light level">
+        Sets the maximum frame-average light level (max_fall) as defined by
+        CTA-861-H.
+        max_fall is undefined by default.
+      </description>
+      <arg name="max_fall" type="uint" summary="Maximum frame-average light level (cd/m²)"/>
+    </request>
+  </interface>
+  <interface name="wp_image_description_v1" version="1">
+    <description summary="Colorimetric image description">
+      An image description carries information about the color encoding used on
+      a surface when attached to a wl_surface via
+      wp_color_management_surface_v1.set_image_description. A compositor can use
+      this information to decode pixel values into colorimetrically meaningful
+      quantities.
+      Note, that the wp_image_description_v1 object is not ready to be used
+      immediately after creation. The object eventually delivers either the
+      'ready' or the 'failed' event, specified in all requests creating it. The
+      object is deemed "ready" after receiving the 'ready' event.
+      An object which is not ready is illegal to use, it can only be destroyed.
+      Any other request in this interface shall result in the 'not_ready'
+      protocol error. Attempts to use an object which is not ready through other
+      interfaces shall raise protocol errors defined there.
+      Once created and regardless of how it was created, a
+      wp_image_description_v1 object always refers to one fixed image
+      description. It cannot change after creation.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the image description">
+        Destroy this object. It is safe to destroy an object which is not ready.
+        Destroying a wp_image_description_v1 object has no side-effects, not
+        even if a wp_color_management_surface_v1.set_image_description has not
+        yet been followed by a wl_surface.commit.
+      </description>
+    </request>
+    <enum name="error">
+      <description summary="protocol errors"/>
+      <entry name="not_ready" value="0"
+             summary="attempted to use an object which is not ready"/>
+      <entry name="no_information" value="1"
+             summary="get_information not allowed"/>
+    </enum>
+    <enum name="cause">
+      <description summary="generic reason for failure"/>
+      <entry name="low_version" value="0"
+             summary="interface version too low"/>
+      <entry name="unsupported" value="1"
+             summary="unsupported image description data"/>
+      <entry name="operating_system" value="2"
+             summary="error independent of the client"/>
+      <entry name="no_output" value="3"
+             summary="the relevant output no longer exists"/>
+    </enum>
+    <event name="failed">
+      <description summary="graceful error on creating the image description">
+        If creating a wp_image_description_v1 object fails for a reason that is
+        not defined as a protocol error, this event is sent.
+        The requests that create image description objects define whether and
+        when this can occur. Only such creation requests can trigger this event.
+        This event cannot be triggered after the image description was
+        successfully formed.
+        Once this event has been sent, the wp_image_description_v1 object will
+        never become ready and it can only be destroyed.
+      </description>
+      <arg name="cause" type="uint" enum="cause"
+           summary="generic reason"/>
+      <arg name="msg" type="string"
+           summary="ad hoc human-readable explanation"/>
+    </event>
+    <event name="ready">
+      <description summary="indication that 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.
+        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" summary="image description id number"/>
+    </event>
+    <request name="get_information">
+      <description summary="get information about the image description">
+        Creates a wp_image_description_info_v1 object which delivers the
+        information that makes up the image description.
+        Not all image description protocol objects allow get_information
+        request. Whether it is allowed or not is defined by the request that
+        created the object. If get_information is not allowed, the protocol
+        error no_information is raised.
+      </description>
+      <arg name="information"
+           type="new_id" interface="wp_image_description_info_v1"/>
+    </request>
+  </interface>
+  <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.
+      This means
+      - if the image description is parametric, it must send
+        - primaries
+        - named_primaries, if applicable
+        - at least one of tf_power and tf_named, as applicable
+        - luminances
+        - target_primaries
+        - target_luminance
+      - if the image description is parametric, it may send, if applicable,
+        - target_max_cll
+        - target_max_fall
+      - if the image description contains an ICC profile, it must send the
+        icc_file event
+      Once a wp_image_description_info_v1 object has delivered a 'done' event it
+      is automatically destroyed.
+      Every wp_image_description_info_v1 created from the same
+      wp_image_description_v1 shall always return the exact same data.
+    </description>
+    <event name="done" type="destructor">
+      <description summary="end of information">
+        Signals the end of information events and destroys the object.
+      </description>
+    </event>
+    <event name="icc_file">
+      <description summary="ICC profile matching the image description">
+        The icc argument provides a file descriptor to the client which may be
+        memory-mapped to provide the ICC profile matching the image description.
+        The fd is read-only, and if mapped then it must be mapped with
+        MAP_PRIVATE by the client.
+        The ICC profile version and other details are determined by the
+        compositor. There is no provision for a client to ask for a specific
+        kind of a profile.
+      </description>
+      <arg name="icc" type="fd" summary="ICC profile file descriptor"/>
+      <arg name="icc_size" type="uint" summary="ICC profile size, in bytes"/>
+      <!-- Offset always 0, compositor must not expose unnecessary data. -->
+    </event>
+    <event name="primaries">
+      <description summary="primaries as chromaticity coordinates">
+        Delivers the primary color volume primaries and white point using CIE
+        1931 xy chromaticity coordinates.
+        Each coordinate value is multiplied by 1 million to get the argument
+        value to carry precision of 6 decimals.
+      </description>
+      <arg name="r_x" type="int" summary="Red x * 1M"/>
+      <arg name="r_y" type="int" summary="Red y * 1M"/>
+      <arg name="g_x" type="int" summary="Green x * 1M"/>
+      <arg name="g_y" type="int" summary="Green y * 1M"/>
+      <arg name="b_x" type="int" summary="Blue x * 1M"/>
+      <arg name="b_y" type="int" summary="Blue y * 1M"/>
+      <arg name="w_x" type="int" summary="White x * 1M"/>
+      <arg name="w_y" type="int" summary="White y * 1M"/>
+    </event>
+    <event name="primaries_named">
+      <description summary="named primaries">
+        Delivers the primary color volume primaries and white point using an
+        explicitly enumerated named set.
+      </description>
+      <arg name="primaries" type="uint" enum="wp_color_manager_v1.primaries"
+           summary="named primaries"/>
+    </event>
+    <event name="tf_power">
+      <description summary="transfer characteristic as a power curve">
+        The color component transfer characteristic of this image description is
+        a pure power curve. This event provides the exponent of the power
+        function. This curve represents the conversion from electrical to
+        optical pixel or color values.
+        The curve exponent has been multiplied by 10000 to get the argument eexp
+        value to carry the precision of 4 decimals.
+      </description>
+      <arg name="eexp" type="uint" summary="the exponent * 10000"/>
+    </event>
+    <event name="tf_named">
+      <description summary="named transfer characteristic">
+        Delivers the transfer characteristic using an explicitly enumerated
+        named function.
+      </description>
+      <arg name="tf" type="uint" enum="wp_color_manager_v1.transfer_function"
+           summary="named transfer function"/>
+    </event>
+    <event name="luminances">
+      <description summary="primary color volume luminance range and reference white">
+        Delivers the primary color volume luminance range and the reference
+        white luminance level. These values include the minimum display emission
+        and ambient flare luminances, assumed to be optically additive and have
+        the chromaticity of the primary color volume white point.
+        The minimum luminance is multiplied by 10000 to get the argument
+        'min_lum' value and carries precision of 4 decimals. The maximum
+        luminance and reference white luminance values are unscaled.
+      </description>
+      <arg name="min_lum" type="uint"
+           summary="minimum luminance (cd/m²) * 10000"/>
+      <arg name="max_lum" type="uint"
+           summary="maximum luminance (cd/m²)"/>
+      <arg name="reference_lum" type="uint"
+           summary="reference white luminance (cd/m²)"/>
+    </event>
+    <event name="target_primaries">
+      <description summary="target primaries as chromaticity coordinates">
+        Provides the color primaries and white point of the target color volume
+        using CIE 1931 xy chromaticity coordinates. This is compatible with the
+        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. 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.
+      </description>
+      <arg name="r_x" type="int" summary="Red x * 1M"/>
+      <arg name="r_y" type="int" summary="Red y * 1M"/>
+      <arg name="g_x" type="int" summary="Green x * 1M"/>
+      <arg name="g_y" type="int" summary="Green y * 1M"/>
+      <arg name="b_x" type="int" summary="Blue x * 1M"/>
+      <arg name="b_y" type="int" summary="Blue y * 1M"/>
+      <arg name="w_x" type="int" summary="White x * 1M"/>
+      <arg name="w_y" type="int" summary="White y * 1M"/>
+    </event>
+    <event name="target_luminance">
+      <description summary="target luminance range">
+        Provides the luminance range that the image description is targeting as
+        the minimum and maximum absolute luminance L. These values include the
+        minimum display emission and ambient flare luminances, assumed to be
+        optically additive and have the chromaticity of the primary color
+        volume white point. This should be compatible with the SMPTE ST 2086
+        definition of HDR static metadata.
+        This luminance range is only theoretical and may not correspond to the
+        luminance of light emitted on an actual display.
+        Min L value is multiplied by 10000 to get the argument min_lum value and
+        carry precision of 4 decimals. Max L value is unscaled for max_lum.
+      </description>
+      <arg name="min_lum" type="uint" summary="min L (cd/m²) * 10000"/>
+      <arg name="max_lum" type="uint" summary="max L (cd/m²)"/>
+    </event>
+    <event name="target_max_cll">
+      <description summary="target maximum content light level">
+        Provides the targeted max_cll of the image description. max_cll is
+        defined by CTA-861-H.
+        This luminance is only theoretical and may not correspond to the
+        luminance of light emitted on an actual display.
+      </description>
+      <arg name="max_cll" type="uint"
+           summary="Maximum content light-level (cd/m²)"/>
+    </event>
+    <event name="target_max_fall">
+      <description summary="target maximum frame-average light level">
+        Provides the targeted max_fall of the image description. max_fall is
+        defined by CTA-861-H.
+        This luminance is only theoretical and may not correspond to the
+        luminance of light emitted on an actual display.
+      </description>
+      <arg name="max_fall" type="uint"
+           summary="Maximum frame-average light level (cd/m²)"/>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/cursor-shape-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/cursor-shape-v1.xml
new file mode 100644
index 0000000..56f6a1a
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/cursor-shape-v1.xml
@@ -0,0 +1,147 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="cursor_shape_v1">
+  <copyright>
+    Copyright 2018 The Chromium Authors
+    Copyright 2023 Simon Ser
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+  <interface name="wp_cursor_shape_manager_v1" version="1">
+    <description summary="cursor shape manager">
+      This global offers an alternative, optional way to set cursor images. This
+      new way uses enumerated cursors instead of a wl_surface like
+      wl_pointer.set_cursor does.
+      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>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the manager">
+        Destroy the cursor shape manager.
+      </description>
+    </request>
+    <request name="get_pointer">
+      <description summary="manage the cursor shape of a pointer device">
+        Obtain a wp_cursor_shape_device_v1 for a wl_pointer object.
+      </description>
+      <arg name="cursor_shape_device" type="new_id" interface="wp_cursor_shape_device_v1"/>
+      <arg name="pointer" type="object" interface="wl_pointer"/>
+    </request>
+    <request name="get_tablet_tool_v2">
+      <description summary="manage the cursor shape of a tablet tool device">
+        Obtain a wp_cursor_shape_device_v1 for a zwp_tablet_tool_v2 object.
+      </description>
+      <arg name="cursor_shape_device" type="new_id" interface="wp_cursor_shape_device_v1"/>
+      <arg name="tablet_tool" type="object" interface="zwp_tablet_tool_v2"/>
+    </request>
+  </interface>
+  <interface name="wp_cursor_shape_device_v1" version="1">
+    <description summary="cursor shape for a device">
+      This interface advertises the list of supported cursor shapes for a
+      device, and allows clients to set the cursor shape.
+    </description>
+    <enum name="shape">
+      <description summary="cursor shapes">
+        This enum describes cursor shapes.
+        The names are taken from the CSS W3C specification:
+        https://w3c.github.io/csswg-drafts/css-ui/#cursor
+      </description>
+      <entry name="default" value="1" summary="default cursor"/>
+      <entry name="context_menu" value="2" summary="a context menu is available for the object under the cursor"/>
+      <entry name="help" value="3" summary="help is available for the object under the cursor"/>
+      <entry name="pointer" value="4" summary="pointer that indicates a link or another interactive element"/>
+      <entry name="progress" value="5" summary="progress indicator"/>
+      <entry name="wait" value="6" summary="program is busy, user should wait"/>
+      <entry name="cell" value="7" summary="a cell or set of cells may be selected"/>
+      <entry name="crosshair" value="8" summary="simple crosshair"/>
+      <entry name="text" value="9" summary="text may be selected"/>
+      <entry name="vertical_text" value="10" summary="vertical text may be selected"/>
+      <entry name="alias" value="11" summary="drag-and-drop: alias of/shortcut to something is to be created"/>
+      <entry name="copy" value="12" summary="drag-and-drop: something is to be copied"/>
+      <entry name="move" value="13" summary="drag-and-drop: something is to be moved"/>
+      <entry name="no_drop" value="14" summary="drag-and-drop: the dragged item cannot be dropped at the current cursor location"/>
+      <entry name="not_allowed" value="15" summary="drag-and-drop: the requested action will not be carried out"/>
+      <entry name="grab" value="16" summary="drag-and-drop: something can be grabbed"/>
+      <entry name="grabbing" value="17" summary="drag-and-drop: something is being grabbed"/>
+      <entry name="e_resize" value="18" summary="resizing: the east border is to be moved"/>
+      <entry name="n_resize" value="19" summary="resizing: the north border is to be moved"/>
+      <entry name="ne_resize" value="20" summary="resizing: the north-east corner is to be moved"/>
+      <entry name="nw_resize" value="21" summary="resizing: the north-west corner is to be moved"/>
+      <entry name="s_resize" value="22" summary="resizing: the south border is to be moved"/>
+      <entry name="se_resize" value="23" summary="resizing: the south-east corner is to be moved"/>
+      <entry name="sw_resize" value="24" summary="resizing: the south-west corner is to be moved"/>
+      <entry name="w_resize" value="25" summary="resizing: the west border is to be moved"/>
+      <entry name="ew_resize" value="26" summary="resizing: the east and west borders are to be moved"/>
+      <entry name="ns_resize" value="27" summary="resizing: the north and south borders are to be moved"/>
+      <entry name="nesw_resize" value="28" summary="resizing: the north-east and south-west corners are to be moved"/>
+      <entry name="nwse_resize" value="29" summary="resizing: the north-west and south-east corners are to be moved"/>
+      <entry name="col_resize" value="30" summary="resizing: that the item/column can be resized horizontally"/>
+      <entry name="row_resize" value="31" summary="resizing: that the item/row can be resized vertically"/>
+      <entry name="all_scroll" value="32" summary="something can be scrolled in any direction"/>
+      <entry name="zoom_in" value="33" summary="something can be zoomed in"/>
+      <entry name="zoom_out" value="34" summary="something can be zoomed out"/>
+    </enum>
+    <enum name="error">
+      <entry name="invalid_shape" value="1"
+        summary="the specified shape value is invalid"/>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the cursor shape device">
+        Destroy the cursor shape device.
+        The device cursor shape remains unchanged.
+      </description>
+    </request>
+    <request name="set_shape">
+      <description summary="set device cursor to the shape">
+        Sets the device cursor to the specified shape. The compositor will
+        change the cursor image based on the specified shape.
+        The cursor actually changes only if the input device focus is one of
+        the requesting client's surfaces. If any, the previous cursor image
+        (surface or shape) is replaced.
+        The "shape" argument must be a valid enum entry, otherwise the
+        invalid_shape protocol error is raised.
+        This is similar to the wl_pointer.set_cursor and
+        zwp_tablet_tool_v2.set_cursor requests, but this request accepts a
+        shape instead of contents in the form of a surface. Clients can mix
+        set_cursor and set_shape requests.
+        The serial parameter must match the latest wl_pointer.enter or
+        zwp_tablet_tool_v2.proximity_in serial number sent to the client.
+        Otherwise the request will be ignored.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the enter event"/>
+      <arg name="shape" type="uint" enum="shape"/>
+    </request>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/fractional-scale-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/fractional-scale-v1.xml
new file mode 100644
index 0000000..350bfc0
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/fractional-scale-v1.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="fractional_scale_v1">
+  <copyright>
+    Copyright © 2022 Kenny Levinsen
+    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 requesting fractional surface scales">
+    This protocol allows a compositor to suggest for surfaces to render at
+    fractional scales.
+    A client can submit scaled content by utilizing wp_viewport. This is done by
+    creating a wp_viewport object for the surface and setting the destination
+    rectangle to the surface size before the scale factor is applied.
+    The buffer size is calculated by multiplying the surface size by the
+    intended scale.
+    The wl_surface buffer scale should remain set to 1.
+    If a surface has a surface-local size of 100 px by 50 px and wishes to
+    submit buffers with a scale of 1.5, then a buffer of 150px by 75 px should
+    be used and the wp_viewport destination rectangle should be 100 px by 50 px.
+    For toplevel surfaces, the size is rounded halfway away from zero. The
+    rounding algorithm for subsurface position and size is not defined.
+  </description>
+  <interface name="wp_fractional_scale_manager_v1" version="1">
+    <description summary="fractional surface scale information">
+      A global interface for requesting surfaces to use fractional scales.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="unbind the fractional surface scale interface">
+        Informs the server that the client will not be using this protocol
+        object anymore. This does not affect any other objects,
+        wp_fractional_scale_v1 objects included.
+      </description>
+    </request>
+    <enum name="error">
+      <entry name="fractional_scale_exists" value="0"
+        summary="the surface already has a fractional_scale object associated"/>
+    </enum>
+    <request name="get_fractional_scale">
+      <description summary="extend surface interface for scale information">
+        Create an add-on object for the the wl_surface to let the compositor
+        request fractional scales. If the given wl_surface already has a
+        wp_fractional_scale_v1 object associated, the fractional_scale_exists
+        protocol error is raised.
+      </description>
+      <arg name="id" type="new_id" interface="wp_fractional_scale_v1"
+           summary="the new surface scale info interface id"/>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="the surface"/>
+    </request>
+  </interface>
+  <interface name="wp_fractional_scale_v1" version="1">
+    <description summary="fractional scale interface to a wl_surface">
+      An additional interface to a wl_surface object which allows the compositor
+      to inform the client of the preferred scale.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="remove surface scale information for surface">
+        Destroy the fractional scale object. When this object is destroyed,
+        preferred_scale events will no longer be sent.
+      </description>
+    </request>
+    <event name="preferred_scale">
+      <description summary="notify of new preferred scale">
+        Notification of a new preferred scale for this surface that the
+        compositor suggests that the client should use.
+        The sent scale is the numerator of a fraction with a denominator of 120.
+      </description>
+      <arg name="scale" type="uint" summary="the new preferred scale"/>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/frog-color-management-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/frog-color-management-v1.xml
new file mode 100644
index 0000000..3d6c2f5
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/frog-color-management-v1.xml
@@ -0,0 +1,356 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="frog_color_management_v1">
+  <copyright>
+    Copyright © 2023 Joshua Ashton for Valve Software
+    Copyright © 2023 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="experimental color management protocol">
+    The aim of this color management extension is to get HDR games working quickly,
+    and have an easy way to test implementations in the wild before the upstream
+    protocol is ready to be merged.
+    For that purpose it's intentionally limited and cut down and does not serve
+    all uses cases.
+  </description>
+  <interface name="frog_color_management_factory_v1" version="1">
+    <description summary="color management factory">
+      The color management factory singleton creates color managed surface objects.
+    </description>
+    <request name="destroy" type="destructor"></request>
+    <request name="get_color_managed_surface">
+      <description summary="create color management interface for surface">
+      </description>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="target surface"/>
+      <arg name="callback" type="new_id" interface="frog_color_managed_surface"
+           summary="new color managed surface object"/>
+    </request>
+  </interface>
+  <interface name="frog_color_managed_surface" version="1">
+    <description summary="color managed surface">
+      Interface for changing surface color management and HDR state.
+      An implementation must: support every part of the version
+      of the frog_color_managed_surface interface it exposes.
+      Including all known enums associated with a given version.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy color managed surface">
+        Destroying the color managed surface resets all known color
+        state for the surface back to 'undefined' implementation-specific
+        values.
+      </description>
+    </request>
+    <enum name="transfer_function">
+      <description summary="known transfer functions">
+        Extended information on the transfer functions described
+        here can be found in the Khronos Data Format specification:
+        https://registry.khronos.org/DataFormat/specs/1.3/dataformat.1.3.html
+      </description>
+      <entry name="undefined" value="0" summary="specifies undefined, implementation-specific handling of the surface's transfer function."/>
+      <entry name="srgb" value="1" summary="specifies the sRGB non-linear EOTF. An implementation may: display this as Gamma 2.2 for the purposes of being consistent with content rendering across displays, rendering_intent and user expectations."/>
+      <entry name="gamma_22" value="2" summary="specifies gamma 2.2 power curve as the EOTF"/>
+      <entry name="st2084_pq" value="3" summary="specifies the SMPTE ST2084 Perceptual Quantizer (PQ) EOTF"/>
+      <entry name="scrgb_linear" value="4" summary="specifies the scRGB (extended sRGB) linear EOTF. Note: Primaries outside the gamut triangle specified can be expressed with negative values for this transfer function."/>
+    </enum>
+    <request name="set_known_transfer_function">
+      <description summary="sets a known transfer function for a surface"/>
+      <arg name="transfer_function" type="uint" enum="transfer_function" summary="transfer function for the surface"/>
+    </request>
+    <enum name="primaries">
+      <description summary="known primaries"/>
+      <entry name="undefined" value="0" summary="specifies undefined, implementation-specific handling"/>
+      <entry name="rec709" value="1" summary="specifies Rec.709/sRGB primaries with D65 white point"/>
+      <entry name="rec2020" value="2" summary="specifies Rec.2020/HDR10 primaries with D65 white point"/>
+    </enum>
+    <request name="set_known_container_color_volume">
+      <description summary="sets the container color volume (primaries) for a surface"/>
+      <arg name="primaries" type="uint" enum="primaries" summary="primaries for the surface"/>
+    </request>
+    <enum name="render_intent">
+      <description summary="known render intents">
+        Extended information on render intents described
+        here can be found in ICC.1:2022:
+        https://www.color.org/specification/ICC.1-2022-05.pdf
+      </description>
+      <entry name="perceptual" value="0" summary="perceptual"/>
+    </enum>
+    <request name="set_render_intent">
+      <description summary="sets the render intent for a surface">
+        NOTE: On a surface with "perceptual" (default) render intent, handling of the container's color volume
+        is implementation-specific, and may differ between different transfer functions it is paired with:
+          ie. sRGB + 709 rendering may have it's primaries widened to more of the available display's gamut
+              to be be more pleasing for the viewer.
+              Compared to scRGB Linear + 709 being treated faithfully as 709
+              (including utilizing negatives out of the 709 gamut triangle)
+      </description>
+      <arg name="render_intent" type="uint" enum="render_intent" summary="render intent for the surface"/>
+    </request>
+    <request name="set_hdr_metadata">
+      <description summary="set HDR metadata for a surface">
+        Forwards HDR metadata from the client to the compositor.
+        HDR Metadata Infoframe as per CTA 861.G spec.
+        Usage of this HDR metadata is implementation specific and
+        outside of the scope of this protocol.
+      </description>
+      <arg name="mastering_display_primary_red_x" type="uint">
+        <description summary="red primary x coordinate">
+          Mastering Red Color Primary X Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="mastering_display_primary_red_y" type="uint">
+        <description summary="red primary y coordinate">
+          Mastering Red Color Primary Y Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="mastering_display_primary_green_x" type="uint">
+        <description summary="green primary x coordinate">
+          Mastering Green Color Primary X Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="mastering_display_primary_green_y" type="uint">
+        <description summary="green primary y coordinate">
+          Mastering Green Color Primary Y Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="mastering_display_primary_blue_x" type="uint">
+        <description summary="blue primary x coordinate">
+          Mastering Blue Color Primary X Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="mastering_display_primary_blue_y" type="uint">
+        <description summary="blue primary y coordinate">
+          Mastering Blue Color Primary Y Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="mastering_white_point_x" type="uint">
+        <description summary="white point x coordinate">
+          Mastering White Point X Coordinate of the Data.
+          These are coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="mastering_white_point_y" type="uint">
+        <description summary="white point y coordinate">
+          Mastering White Point Y Coordinate of the Data.
+          These are coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="max_display_mastering_luminance" type="uint">
+        <description summary="max display mastering luminance">
+          Max Mastering Display Luminance.
+          This value is coded as an unsigned 16-bit value in units of 1 cd/m2,
+          where 0x0001 represents 1 cd/m2 and 0xFFFF represents 65535 cd/m2.
+        </description>
+      </arg>
+      <arg name="min_display_mastering_luminance" type="uint">
+        <description summary="min display mastering luminance">
+          Min Mastering Display Luminance.
+          This value is coded as an unsigned 16-bit value in units of
+          0.0001 cd/m2, where 0x0001 represents 0.0001 cd/m2 and 0xFFFF
+          represents 6.5535 cd/m2.
+        </description>
+      </arg>
+      <arg name="max_cll" type="uint">
+        <description summary="max content light level">
+          Max Content Light Level.
+          This value is coded as an unsigned 16-bit value in units of 1 cd/m2,
+          where 0x0001 represents 1 cd/m2 and 0xFFFF represents 65535 cd/m2.
+        </description>
+      </arg>
+      <arg name="max_fall" type="uint">
+        <description summary="max frame average light level">
+          Max Frame Average Light Level.
+          This value is coded as an unsigned 16-bit value in units of 1 cd/m2,
+          where 0x0001 represents 1 cd/m2 and 0xFFFF represents 65535 cd/m2.
+        </description>
+      </arg>
+    </request>
+    <event name="preferred_metadata">
+      <description summary="preferred metadata for a surface">
+        Current preferred metadata for a surface.
+        The application should use this information to tone-map its buffers
+        to this target before committing.
+        This metadata does not necessarily correspond to any physical output, but
+        rather what the compositor thinks would be best for a given surface.
+      </description>
+      <arg name="transfer_function" type="uint" enum="transfer_function">
+        <description summary="output's current transfer function">
+          Specifies a known transfer function that corresponds to the
+          output the surface is targeting.
+        </description>
+      </arg>
+      <arg name="output_display_primary_red_x" type="uint">
+        <description summary="red primary x coordinate">
+          Output Red Color Primary X Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="output_display_primary_red_y" type="uint">
+        <description summary="red primary y coordinate">
+          Output Red Color Primary Y Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="output_display_primary_green_x" type="uint">
+        <description summary="green primary x coordinate">
+          Output Green Color Primary X Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="output_display_primary_green_y" type="uint">
+        <description summary="green primary y coordinate">
+          Output Green Color Primary Y Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="output_display_primary_blue_x" type="uint">
+        <description summary="blue primary x coordinate">
+          Output Blue Color Primary X Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="output_display_primary_blue_y" type="uint">
+        <description summary="blue primary y coordinate">
+          Output Blue Color Primary Y Coordinate of the Data.
+          Coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="output_white_point_x" type="uint">
+        <description summary="white point x coordinate">
+          Output White Point X Coordinate of the Data.
+          These are coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="output_white_point_y" type="uint">
+        <description summary="white point y coordinate">
+          Output White Point Y Coordinate of the Data.
+          These are coded as unsigned 16-bit values in units of
+          0.00002, where 0x0000 represents zero and 0xC350
+          represents 1.0000.
+        </description>
+      </arg>
+      <arg name="max_luminance" type="uint">
+        <description summary="maximum luminance">
+          Max Output Luminance
+          The max luminance in nits that the output is capable of rendering in small areas.
+          Content should: not exceed this value to avoid clipping.
+          This value is coded as an unsigned 16-bit value in units of 1 cd/m2,
+          where 0x0001 represents 1 cd/m2 and 0xFFFF represents 65535 cd/m2.
+        </description>
+      </arg>
+      <arg name="min_luminance" type="uint">
+        <description summary="minimum luminance">
+          Min Output Luminance
+          The min luminance that the output is capable of rendering.
+          Content should: not exceed this value to avoid clipping.
+          This value is coded as an unsigned 16-bit value in units of
+          0.0001 cd/m2, where 0x0001 represents 0.0001 cd/m2 and 0xFFFF
+          represents 6.5535 cd/m2.
+        </description>
+      </arg>
+      <arg name="max_full_frame_luminance" type="uint">
+        <description summary="maximum full frame luminance">
+          Max Full Frame Luminance
+          The max luminance in nits that the output is capable of rendering for the
+          full frame sustained.
+          This value is coded as an unsigned 16-bit value in units of 1 cd/m2,
+          where 0x0001 represents 1 cd/m2 and 0xFFFF represents 65535 cd/m2.
+        </description>
+      </arg>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/idle-inhibit-unstable-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/idle-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..9c06cdc
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/idle-inhibit-unstable-v1.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+  <copyright>
+    Copyright © 2015 Samsung Electronics Co., Ltd
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+  <interface name="zwp_idle_inhibit_manager_v1" version="1">
+    <description summary="control behavior when display idles">
+      This interface permits inhibiting the idle behavior such as screen
+      blanking, locking, and screensaving.  The client binds the idle manager
+      globally, then creates idle-inhibitor objects for each surface.
+      Warning! The protocol described in this file is experimental and
+      backward incompatible changes may be made. Backward compatible changes
+      may be added together with the corresponding interface version bump.
+      Backward incompatible changes are done by bumping the version number in
+      the protocol and interface names and resetting the interface version.
+      Once the protocol is to be declared stable, the 'z' prefix and the
+      version number in the protocol and interface names are removed and the
+      interface version number is reset.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the idle inhibitor object">
+        Destroy the inhibit manager.
+      </description>
+    </request>
+    <request name="create_inhibitor">
+      <description summary="create a new inhibitor object">
+        Create a new inhibitor object associated with the given surface.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="the surface that inhibits the idle behavior"/>
+    </request>
+  </interface>
+  <interface name="zwp_idle_inhibitor_v1" version="1">
+    <description summary="context object for inhibiting idle behavior">
+      An idle inhibitor prevents the output that the associated surface is
+      visible on from being set to a state where it is not visually usable due
+      to lack of user interaction (e.g. blanked, dimmed, locked, set to power
+      save, etc.)  Any screensaver processes are also blocked from displaying.
+      If the surface is destroyed, unmapped, becomes occluded, loses
+      visibility, or otherwise becomes not visually relevant for the user, the
+      idle inhibitor will not be honored by the compositor; if the surface
+      subsequently regains visibility the inhibitor takes effect once again.
+      Likewise, the inhibitor isn't honored if the system was already idled at
+      the time the inhibitor was established, although if the system later
+      de-idles and re-idles the inhibitor will take effect.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the idle inhibitor object">
+        Remove the inhibitor effect from the associated wl_surface.
+      </description>
+    </request>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/input-timestamps-unstable-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/input-timestamps-unstable-v1.xml
new file mode 100644
index 0000000..7c5e082
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/input-timestamps-unstable-v1.xml
@@ -0,0 +1,145 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="input_timestamps_unstable_v1">
+  <copyright>
+    Copyright © 2017 Collabora, Ltd.
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+  <description summary="High-resolution timestamps for input events">
+    This protocol specifies a way for a client to request and receive
+    high-resolution timestamps for input events.
+    Warning! The protocol described in this file is experimental and
+    backward incompatible changes may be made. Backward compatible changes
+    may be added together with the corresponding interface version bump.
+    Backward incompatible changes are done by bumping the version number in
+    the protocol and interface names and resetting the interface version.
+    Once the protocol is to be declared stable, the 'z' prefix and the
+    version number in the protocol and interface names are removed and the
+    interface version number is reset.
+  </description>
+  <interface name="zwp_input_timestamps_manager_v1" version="1">
+    <description summary="context object for high-resolution input timestamps">
+      A global interface used for requesting high-resolution timestamps
+      for input events.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the input timestamps manager object">
+        Informs the server that the client will no longer be using this
+        protocol object. Existing objects created by this object are not
+        affected.
+      </description>
+    </request>
+    <request name="get_keyboard_timestamps">
+      <description summary="subscribe to high-resolution keyboard timestamp events">
+        Creates a new input timestamps object that represents a subscription
+        to high-resolution timestamp events for all wl_keyboard events that
+        carry a timestamp.
+        If the associated wl_keyboard object is invalidated, either through
+        client action (e.g. release) or server-side changes, the input
+        timestamps object becomes inert and the client should destroy it
+        by calling zwp_input_timestamps_v1.destroy.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_input_timestamps_v1"/>
+      <arg name="keyboard" type="object" interface="wl_keyboard"
+           summary="the wl_keyboard object for which to get timestamp events"/>
+    </request>
+    <request name="get_pointer_timestamps">
+      <description summary="subscribe to high-resolution pointer timestamp events">
+        Creates a new input timestamps object that represents a subscription
+        to high-resolution timestamp events for all wl_pointer events that
+        carry a timestamp.
+        If the associated wl_pointer object is invalidated, either through
+        client action (e.g. release) or server-side changes, the input
+        timestamps object becomes inert and the client should destroy it
+        by calling zwp_input_timestamps_v1.destroy.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_input_timestamps_v1"/>
+      <arg name="pointer" type="object" interface="wl_pointer"
+           summary="the wl_pointer object for which to get timestamp events"/>
+    </request>
+    <request name="get_touch_timestamps">
+      <description summary="subscribe to high-resolution touch timestamp events">
+        Creates a new input timestamps object that represents a subscription
+        to high-resolution timestamp events for all wl_touch events that
+        carry a timestamp.
+        If the associated wl_touch object becomes invalid, either through
+        client action (e.g. release) or server-side changes, the input
+        timestamps object becomes inert and the client should destroy it
+        by calling zwp_input_timestamps_v1.destroy.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_input_timestamps_v1"/>
+      <arg name="touch" type="object" interface="wl_touch"
+           summary="the wl_touch object for which to get timestamp events"/>
+    </request>
+  </interface>
+  <interface name="zwp_input_timestamps_v1" version="1">
+    <description summary="context object for input timestamps">
+      Provides high-resolution timestamp events for a set of subscribed input
+      events. The set of subscribed input events is determined by the
+      zwp_input_timestamps_manager_v1 request used to create this object.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the input timestamps object">
+        Informs the server that the client will no longer be using this
+        protocol object. After the server processes the request, no more
+        timestamp events will be emitted.
+      </description>
+    </request>
+    <event name="timestamp">
+      <description summary="high-resolution timestamp event">
+        The timestamp event is associated with the first subsequent input event
+        carrying a timestamp which belongs to the set of input events this
+        object is subscribed to.
+        The timestamp provided by this event is a high-resolution version of
+        the timestamp argument of the associated input event. The provided
+        timestamp is in the same clock domain and is at least as accurate as
+        the associated input event timestamp.
+        The timestamp is expressed as tv_sec_hi, tv_sec_lo, tv_nsec triples,
+        each component being an unsigned 32-bit value. Whole seconds are in
+        tv_sec which is a 64-bit value combined from tv_sec_hi and tv_sec_lo,
+        and the additional fractional part in tv_nsec as nanoseconds. Hence,
+        for valid timestamps tv_nsec must be in [0, 999999999].
+      </description>
+      <arg name="tv_sec_hi" type="uint"
+           summary="high 32 bits of the seconds part of the timestamp"/>
+      <arg name="tv_sec_lo" type="uint"
+           summary="low 32 bits of the seconds part of the timestamp"/>
+      <arg name="tv_nsec" type="uint"
+           summary="nanoseconds part of the timestamp"/>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/keyboard-shortcuts-inhibit-unstable-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/keyboard-shortcuts-inhibit-unstable-v1.xml
new file mode 100644
index 0000000..2774876
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/keyboard-shortcuts-inhibit-unstable-v1.xml
@@ -0,0 +1,143 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="keyboard_shortcuts_inhibit_unstable_v1">
+  <copyright>
+    Copyright © 2017 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 inhibiting the compositor keyboard shortcuts">
+    This protocol specifies a way for a client to request the compositor
+    to ignore its own keyboard shortcuts for a given seat, so that all
+    key events from that seat get forwarded to a surface.
+    Warning! The protocol described in this file is experimental and
+    backward incompatible changes may be made. Backward compatible
+    changes may be added together with the corresponding interface
+    version bump.
+    Backward incompatible changes are done by bumping the version
+    number in the protocol and interface names and resetting the
+    interface version. Once the protocol is to be declared stable,
+    the 'z' prefix and the version number in the protocol and
+    interface names are removed and the interface version number is
+    reset.
+  </description>
+  <interface name="zwp_keyboard_shortcuts_inhibit_manager_v1" version="1">
+    <description summary="context object for keyboard grab_manager">
+      A global interface used for inhibiting the compositor keyboard shortcuts.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the keyboard shortcuts inhibitor object">
+        Destroy the keyboard shortcuts inhibitor manager.
+      </description>
+    </request>
+    <request name="inhibit_shortcuts">
+      <description summary="create a new keyboard shortcuts inhibitor object">
+        Create a new keyboard shortcuts inhibitor object associated with
+        the given surface for the given seat.
+        If shortcuts are already inhibited for the specified seat and surface,
+        a protocol error "already_inhibited" is raised by the compositor.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_keyboard_shortcuts_inhibitor_v1"/>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="the surface that inhibits the keyboard shortcuts behavior"/>
+      <arg name="seat" type="object" interface="wl_seat"
+           summary="the wl_seat for which keyboard shortcuts should be disabled"/>
+    </request>
+    <enum name="error">
+      <entry name="already_inhibited"
+             value="0"
+             summary="the shortcuts are already inhibited for this surface"/>
+    </enum>
+  </interface>
+  <interface name="zwp_keyboard_shortcuts_inhibitor_v1" version="1">
+    <description summary="context object for keyboard shortcuts inhibitor">
+      A keyboard shortcuts inhibitor instructs the compositor to ignore
+      its own keyboard shortcuts when the associated surface has keyboard
+      focus. As a result, when the surface has keyboard focus on the given
+      seat, it will receive all key events originating from the specified
+      seat, even those which would normally be caught by the compositor for
+      its own shortcuts.
+      The Wayland compositor is however under no obligation to disable
+      all of its shortcuts, and may keep some special key combo for its own
+      use, including but not limited to one allowing the user to forcibly
+      restore normal keyboard events routing in the case of an unwilling
+      client. The compositor may also use the same key combo to reactivate
+      an existing shortcut inhibitor that was previously deactivated on
+      user request.
+      When the compositor restores its own keyboard shortcuts, an
+      "inactive" event is emitted to notify the client that the keyboard
+      shortcuts inhibitor is not effectively active for the surface and
+      seat any more, and the client should not expect to receive all
+      keyboard events.
+      When the keyboard shortcuts inhibitor is inactive, the client has
+      no way to forcibly reactivate the keyboard shortcuts inhibitor.
+      The user can chose to re-enable a previously deactivated keyboard
+      shortcuts inhibitor using any mechanism the compositor may offer,
+      in which case the compositor will send an "active" event to notify
+      the client.
+      If the surface is destroyed, unmapped, or loses the seat's keyboard
+      focus, the keyboard shortcuts inhibitor becomes irrelevant and the
+      compositor will restore its own keyboard shortcuts but no "inactive"
+      event is emitted in this case.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the keyboard shortcuts inhibitor object">
+        Remove the keyboard shortcuts inhibitor from the associated wl_surface.
+      </description>
+    </request>
+    <event name="active">
+      <description summary="shortcuts are inhibited">
+        This event indicates that the shortcut inhibitor is active.
+        The compositor sends this event every time compositor shortcuts
+        are inhibited on behalf of the surface. When active, the client
+        may receive input events normally reserved by the compositor
+        (see zwp_keyboard_shortcuts_inhibitor_v1).
+        This occurs typically when the initial request "inhibit_shortcuts"
+        first becomes active or when the user instructs the compositor to
+        re-enable and existing shortcuts inhibitor using any mechanism
+        offered by the compositor.
+      </description>
+    </event>
+    <event name="inactive">
+      <description summary="shortcuts are restored">
+        This event indicates that the shortcuts inhibitor is inactive,
+        normal shortcuts processing is restored by the compositor.
+       </description>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/pointer-constraints-unstable-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/pointer-constraints-unstable-v1.xml
new file mode 100644
index 0000000..4e67a13
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/pointer-constraints-unstable-v1.xml
@@ -0,0 +1,339 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="pointer_constraints_unstable_v1">
+  <copyright>
+    Copyright © 2014      Jonas Ådahl
+    Copyright © 2015      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 constraining pointer motions">
+    This protocol specifies a set of interfaces used for adding constraints to
+    the motion of a pointer. Possible constraints include confining pointer
+    motions to a given region, or locking it to its current position.
+    In order to constrain the pointer, a client must first bind the global
+    interface "wp_pointer_constraints" which, if a compositor supports pointer
+    constraints, is exposed by the registry. Using the bound global object, the
+    client uses the request that corresponds to the type of constraint it wants
+    to make. See wp_pointer_constraints for more details.
+    Warning! The protocol described in this file is experimental and backward
+    incompatible changes may be made. Backward compatible changes may be added
+    together with the corresponding interface version bump. Backward
+    incompatible changes are done by bumping the version number in the protocol
+    and interface names and resetting the interface version. Once the protocol
+    is to be declared stable, the 'z' prefix and the version number in the
+    protocol and interface names are removed and the interface version number is
+    reset.
+  </description>
+  <interface name="zwp_pointer_constraints_v1" version="1">
+    <description summary="constrain the movement of a pointer">
+      The global interface exposing pointer constraining functionality. It
+      exposes two requests: lock_pointer for locking the pointer to its
+      position, and confine_pointer for locking the pointer to a region.
+      The lock_pointer and confine_pointer requests create the objects
+      wp_locked_pointer and wp_confined_pointer respectively, and the client can
+      use these objects to interact with the lock.
+      For any surface, only one lock or confinement may be active across all
+      wl_pointer objects of the same seat. If a lock or confinement is requested
+      when another lock or confinement is active or requested on the same surface
+      and with any of the wl_pointer objects of the same seat, an
+      'already_constrained' error will be raised.
+    </description>
+    <enum name="error">
+      <description summary="wp_pointer_constraints error values">
+        These errors can be emitted in response to wp_pointer_constraints
+        requests.
+      </description>
+      <entry name="already_constrained" value="1"
+             summary="pointer constraint already requested on that surface"/>
+    </enum>
+    <enum name="lifetime">
+      <description summary="constraint lifetime">
+        These values represent different lifetime semantics. They are passed
+        as arguments to the factory requests to specify how the constraint
+        lifetimes should be managed.
+      </description>
+      <entry name="oneshot" value="1">
+        <description summary="the pointer constraint is defunct once deactivated">
+          A oneshot pointer constraint will never reactivate once it has been
+          deactivated. See the corresponding deactivation event
+          (wp_locked_pointer.unlocked and wp_confined_pointer.unconfined) for
+          details.
+        </description>
+      </entry>
+      <entry name="persistent" value="2">
+        <description summary="the pointer constraint may reactivate">
+          A persistent pointer constraint may again reactivate once it has
+          been deactivated. See the corresponding deactivation event
+          (wp_locked_pointer.unlocked and wp_confined_pointer.unconfined) for
+          details.
+        </description>
+      </entry>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the pointer constraints manager object">
+        Used by the client to notify the server that it will no longer use this
+        pointer constraints object.
+      </description>
+    </request>
+    <request name="lock_pointer">
+      <description summary="lock pointer to a position">
+        The lock_pointer request lets the client request to disable movements of
+        the virtual pointer (i.e. the cursor), effectively locking the pointer
+        to a position. This request may not take effect immediately; in the
+        future, when the compositor deems implementation-specific constraints
+        are satisfied, the pointer lock will be activated and the compositor
+        sends a locked event.
+        The protocol provides no guarantee that the constraints are ever
+        satisfied, and does not require the compositor to send an error if the
+        constraints cannot ever be satisfied. It is thus possible to request a
+        lock that will never activate.
+        There may not be another pointer constraint of any kind requested or
+        active on the surface for any of the wl_pointer objects of the seat of
+        the passed pointer when requesting a lock. If there is, an error will be
+        raised. See general pointer lock documentation for more details.
+        The intersection of the region passed with this request and the input
+        region of the surface is used to determine where the pointer must be
+        in order for the lock to activate. It is up to the compositor whether to
+        warp the pointer or require some kind of user interaction for the lock
+        to activate. If the region is null the surface input region is used.
+        A surface may receive pointer focus without the lock being activated.
+        The request creates a new object wp_locked_pointer which is used to
+        interact with the lock as well as receive updates about its state. See
+        the the description of wp_locked_pointer for further information.
+        Note that while a pointer is locked, the wl_pointer objects of the
+        corresponding seat will not emit any wl_pointer.motion events, but
+        relative motion events will still be emitted via wp_relative_pointer
+        objects of the same seat. wl_pointer.axis and wl_pointer.button events
+        are unaffected.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_locked_pointer_v1"/>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="surface to lock pointer to"/>
+      <arg name="pointer" type="object" interface="wl_pointer"
+           summary="the pointer that should be locked"/>
+      <arg name="region" type="object" interface="wl_region" allow-null="true"
+           summary="region of surface"/>
+      <arg name="lifetime" type="uint" summary="lock lifetime"/>
+    </request>
+    <request name="confine_pointer">
+      <description summary="confine pointer to a region">
+        The confine_pointer request lets the client request to confine the
+        pointer cursor to a given region. This request may not take effect
+        immediately; in the future, when the compositor deems implementation-
+        specific constraints are satisfied, the pointer confinement will be
+        activated and the compositor sends a confined event.
+        The intersection of the region passed with this request and the input
+        region of the surface is used to determine where the pointer must be
+        in order for the confinement to activate. It is up to the compositor
+        whether to warp the pointer or require some kind of user interaction for
+        the confinement to activate. If the region is null the surface input
+        region is used.
+        The request will create a new object wp_confined_pointer which is used
+        to interact with the confinement as well as receive updates about its
+        state. See the the description of wp_confined_pointer for further
+        information.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_confined_pointer_v1"/>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="surface to lock pointer to"/>
+      <arg name="pointer" type="object" interface="wl_pointer"
+           summary="the pointer that should be confined"/>
+      <arg name="region" type="object" interface="wl_region" allow-null="true"
+           summary="region of surface"/>
+      <arg name="lifetime" type="uint" summary="confinement lifetime"/>
+    </request>
+  </interface>
+  <interface name="zwp_locked_pointer_v1" version="1">
+    <description summary="receive relative pointer motion events">
+      The wp_locked_pointer interface represents a locked pointer state.
+      While the lock of this object is active, the wl_pointer objects of the
+      associated seat will not emit any wl_pointer.motion events.
+      This object will send the event 'locked' when the lock is activated.
+      Whenever the lock is activated, it is guaranteed that the locked surface
+      will already have received pointer focus and that the pointer will be
+      within the region passed to the request creating this object.
+      To unlock the pointer, send the destroy request. This will also destroy
+      the wp_locked_pointer object.
+      If the compositor decides to unlock the pointer the unlocked event is
+      sent. See wp_locked_pointer.unlock for details.
+      When unlocking, the compositor may warp the cursor position to the set
+      cursor position hint. If it does, it will not result in any relative
+      motion events emitted via wp_relative_pointer.
+      If the surface the lock was requested on is destroyed and the lock is not
+      yet activated, the wp_locked_pointer object is now defunct and must be
+      destroyed.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the locked pointer object">
+        Destroy the locked pointer object. If applicable, the compositor will
+        unlock the pointer.
+      </description>
+    </request>
+    <request name="set_cursor_position_hint">
+      <description summary="set the pointer cursor position hint">
+        Set the cursor position hint relative to the top left corner of the
+        surface.
+        If the client is drawing its own cursor, it should update the position
+        hint to the position of its own cursor. A compositor may use this
+        information to warp the pointer upon unlock in order to avoid pointer
+        jumps.
+        The cursor position hint is double buffered. The new hint will only take
+        effect when the associated surface gets it pending state applied. See
+        wl_surface.commit for details.
+      </description>
+      <arg name="surface_x" type="fixed"
+           summary="surface-local x coordinate"/>
+      <arg name="surface_y" type="fixed"
+           summary="surface-local y coordinate"/>
+    </request>
+    <request name="set_region">
+      <description summary="set a new lock region">
+        Set a new region used to lock the pointer.
+        The new lock region is double-buffered. The new lock region will
+        only take effect when the associated surface gets its pending state
+        applied. See wl_surface.commit for details.
+        For details about the lock region, see wp_locked_pointer.
+      </description>
+      <arg name="region" type="object" interface="wl_region" allow-null="true"
+           summary="region of surface"/>
+    </request>
+    <event name="locked">
+      <description summary="lock activation event">
+        Notification that the pointer lock of the seat's pointer is activated.
+      </description>
+    </event>
+    <event name="unlocked">
+      <description summary="lock deactivation event">
+        Notification that the pointer lock of the seat's pointer is no longer
+        active. If this is a oneshot pointer lock (see
+        wp_pointer_constraints.lifetime) this object is now defunct and should
+        be destroyed. If this is a persistent pointer lock (see
+        wp_pointer_constraints.lifetime) this pointer lock may again
+        reactivate in the future.
+      </description>
+    </event>
+  </interface>
+  <interface name="zwp_confined_pointer_v1" version="1">
+    <description summary="confined pointer object">
+      The wp_confined_pointer interface represents a confined pointer state.
+      This object will send the event 'confined' when the confinement is
+      activated. Whenever the confinement is activated, it is guaranteed that
+      the surface the pointer is confined to will already have received pointer
+      focus and that the pointer will be within the region passed to the request
+      creating this object. It is up to the compositor to decide whether this
+      requires some user interaction and if the pointer will warp to within the
+      passed region if outside.
+      To unconfine the pointer, send the destroy request. This will also destroy
+      the wp_confined_pointer object.
+      If the compositor decides to unconfine the pointer the unconfined event is
+      sent. The wp_confined_pointer object is at this point defunct and should
+      be destroyed.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the confined pointer object">
+        Destroy the confined pointer object. If applicable, the compositor will
+        unconfine the pointer.
+      </description>
+    </request>
+    <request name="set_region">
+      <description summary="set a new confine region">
+        Set a new region used to confine the pointer.
+        The new confine region is double-buffered. The new confine region will
+        only take effect when the associated surface gets its pending state
+        applied. See wl_surface.commit for details.
+        If the confinement is active when the new confinement region is applied
+        and the pointer ends up outside of newly applied region, the pointer may
+        warped to a position within the new confinement region. If warped, a
+        wl_pointer.motion event will be emitted, but no
+        wp_relative_pointer.relative_motion event.
+        The compositor may also, instead of using the new region, unconfine the
+        pointer.
+        For details about the confine region, see wp_confined_pointer.
+      </description>
+      <arg name="region" type="object" interface="wl_region" allow-null="true"
+           summary="region of surface"/>
+    </request>
+    <event name="confined">
+      <description summary="pointer confined">
+        Notification that the pointer confinement of the seat's pointer is
+        activated.
+      </description>
+    </event>
+    <event name="unconfined">
+      <description summary="pointer unconfined">
+        Notification that the pointer confinement of the seat's pointer is no
+        longer active. If this is a oneshot pointer confinement (see
+        wp_pointer_constraints.lifetime) this object is now defunct and should
+        be destroyed. If this is a persistent pointer confinement (see
+        wp_pointer_constraints.lifetime) this pointer confinement may again
+        reactivate in the future.
+      </description>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/primary-selection-unstable-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/primary-selection-unstable-v1.xml
new file mode 100644
index 0000000..e5a39e3
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/primary-selection-unstable-v1.xml
@@ -0,0 +1,225 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="wp_primary_selection_unstable_v1">
+  <copyright>
+    Copyright © 2015, 2016 Red Hat
+    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="Primary selection protocol">
+    This protocol provides the ability to have a primary selection device to
+    match that of the X server. This primary selection is a shortcut to the
+    common clipboard selection, where text just needs to be selected in order
+    to allow copying it elsewhere. The de facto way to perform this action
+    is the middle mouse button, although it is not limited to this one.
+    Clients wishing to honor primary selection should create a primary
+    selection source and set it as the selection through
+    wp_primary_selection_device.set_selection whenever the text selection
+    changes. In order to minimize calls in pointer-driven text selection,
+    it should happen only once after the operation finished. Similarly,
+    a NULL source should be set when text is unselected.
+    wp_primary_selection_offer objects are first announced through the
+    wp_primary_selection_device.data_offer event. Immediately after this event,
+    the primary data offer will emit wp_primary_selection_offer.offer events
+    to let know of the mime types being offered.
+    When the primary selection changes, the client with the keyboard focus
+    will receive wp_primary_selection_device.selection events. Only the client
+    with the keyboard focus will receive such events with a non-NULL
+    wp_primary_selection_offer. Across keyboard focus changes, previously
+    focused clients will receive wp_primary_selection_device.events with a
+    NULL wp_primary_selection_offer.
+    In order to request the primary selection data, the client must pass
+    a recent serial pertaining to the press event that is triggering the
+    operation, if the compositor deems the serial valid and recent, the
+    wp_primary_selection_source.send event will happen in the other end
+    to let the transfer begin. The client owning the primary selection
+    should write the requested data, and close the file descriptor
+    immediately.
+    If the primary selection owner client disappeared during the transfer,
+    the client reading the data will receive a
+    wp_primary_selection_device.selection event with a NULL
+    wp_primary_selection_offer, the client should take this as a hint
+    to finish the reads related to the no longer existing offer.
+    The primary selection owner should be checking for errors during
+    writes, merely cancelling the ongoing transfer if any happened.
+  </description>
+  <interface name="zwp_primary_selection_device_manager_v1" version="1">
+    <description summary="X primary selection emulation">
+      The primary selection device manager is a singleton global object that
+      provides access to the primary selection. It allows to create
+      wp_primary_selection_source objects, as well as retrieving the per-seat
+      wp_primary_selection_device objects.
+    </description>
+    <request name="create_source">
+      <description summary="create a new primary selection source">
+        Create a new primary selection source.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_primary_selection_source_v1"/>
+    </request>
+    <request name="get_device">
+      <description summary="create a new primary selection device">
+        Create a new data device for a given seat.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_primary_selection_device_v1"/>
+      <arg name="seat" type="object" interface="wl_seat"/>
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the primary selection device manager">
+        Destroy the primary selection device manager.
+      </description>
+    </request>
+  </interface>
+  <interface name="zwp_primary_selection_device_v1" version="1">
+    <request name="set_selection">
+      <description summary="set the primary selection">
+        Replaces the current selection. The previous owner of the primary
+        selection will receive a wp_primary_selection_source.cancelled event.
+        To unset the selection, set the source to NULL.
+      </description>
+      <arg name="source" type="object" interface="zwp_primary_selection_source_v1" allow-null="true"/>
+      <arg name="serial" type="uint" summary="serial of the event that triggered this request"/>
+    </request>
+    <event name="data_offer">
+      <description summary="introduce a new wp_primary_selection_offer">
+        Introduces a new wp_primary_selection_offer object that may be used
+        to receive the current primary selection. Immediately following this
+        event, the new wp_primary_selection_offer object will send
+        wp_primary_selection_offer.offer events to describe the offered mime
+        types.
+      </description>
+      <arg name="offer" type="new_id" interface="zwp_primary_selection_offer_v1"/>
+    </event>
+    <event name="selection">
+      <description summary="advertise a new primary selection">
+        The wp_primary_selection_device.selection event is sent to notify the
+        client of a new primary selection. This event is sent after the
+        wp_primary_selection.data_offer event introducing this object, and after
+        the offer has announced its mimetypes through
+        wp_primary_selection_offer.offer.
+        The data_offer is valid until a new offer or NULL is received
+        or until the client loses keyboard focus. The client must destroy the
+        previous selection data_offer, if any, upon receiving this event.
+      </description>
+      <arg name="id" type="object" interface="zwp_primary_selection_offer_v1" allow-null="true"/>
+    </event>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the primary selection device">
+        Destroy the primary selection device.
+      </description>
+    </request>
+  </interface>
+  <interface name="zwp_primary_selection_offer_v1" version="1">
+    <description summary="offer to transfer primary selection contents">
+      A wp_primary_selection_offer represents an offer to transfer the contents
+      of the primary selection clipboard to the client. Similar to
+      wl_data_offer, the offer also describes the mime types that the data can
+      be converted to and provides the mechanisms for transferring the data
+      directly to the client.
+    </description>
+    <request name="receive">
+      <description summary="request that the data is transferred">
+        To transfer the contents of the primary selection clipboard, the client
+        issues this request and indicates the mime type that it wants to
+        receive. The transfer happens through the passed file descriptor
+        (typically created with the pipe system call). The source client writes
+        the data in the mime type representation requested and then closes the
+        file descriptor.
+        The receiving client reads from the read end of the pipe until EOF and
+        closes its end, at which point the transfer is complete.
+      </description>
+      <arg name="mime_type" type="string"/>
+      <arg name="fd" type="fd"/>
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the primary selection offer">
+        Destroy the primary selection offer.
+      </description>
+    </request>
+    <event name="offer">
+      <description summary="advertise offered mime type">
+        Sent immediately after creating announcing the
+        wp_primary_selection_offer through
+        wp_primary_selection_device.data_offer. One event is sent per offered
+        mime type.
+      </description>
+      <arg name="mime_type" type="string"/>
+    </event>
+  </interface>
+  <interface name="zwp_primary_selection_source_v1" version="1">
+    <description summary="offer to replace the contents of the primary selection">
+      The source side of a wp_primary_selection_offer, it provides a way to
+      describe the offered data and respond to requests to transfer the
+      requested contents of the primary selection clipboard.
+    </description>
+    <request name="offer">
+      <description summary="add an offered mime type">
+        This request adds a mime type to the set of mime types advertised to
+        targets. Can be called several times to offer multiple types.
+      </description>
+      <arg name="mime_type" type="string"/>
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the primary selection source">
+        Destroy the primary selection source.
+      </description>
+    </request>
+    <event name="send">
+      <description summary="send the primary selection contents">
+        Request for the current primary selection contents from the client.
+        Send the specified mime type over the passed file descriptor, then
+        close it.
+      </description>
+      <arg name="mime_type" type="string"/>
+      <arg name="fd" type="fd"/>
+    </event>
+    <event name="cancelled">
+      <description summary="request for primary selection contents was canceled">
+        This primary selection source is no longer valid. The client should
+        clean up and destroy this primary selection source.
+      </description>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/relative-pointer-unstable-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/relative-pointer-unstable-v1.xml
new file mode 100644
index 0000000..ca6f81d
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/relative-pointer-unstable-v1.xml
@@ -0,0 +1,136 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="relative_pointer_unstable_v1">
+  <copyright>
+    Copyright © 2014      Jonas Ådahl
+    Copyright © 2015      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 relative pointer motion events">
+    This protocol specifies a set of interfaces used for making clients able to
+    receive relative pointer events not obstructed by barriers (such as the
+    monitor edge or other pointer barriers).
+    To start receiving relative pointer events, a client must first bind the
+    global interface "wp_relative_pointer_manager" which, if a compositor
+    supports relative pointer motion events, is exposed by the registry. After
+    having created the relative pointer manager proxy object, the client uses
+    it to create the actual relative pointer object using the
+    "get_relative_pointer" request given a wl_pointer. The relative pointer
+    motion events will then, when applicable, be transmitted via the proxy of
+    the newly created relative pointer object. See the documentation of the
+    relative pointer interface for more details.
+    Warning! The protocol described in this file is experimental and backward
+    incompatible changes may be made. Backward compatible changes may be added
+    together with the corresponding interface version bump. Backward
+    incompatible changes are done by bumping the version number in the protocol
+    and interface names and resetting the interface version. Once the protocol
+    is to be declared stable, the 'z' prefix and the version number in the
+    protocol and interface names are removed and the interface version number is
+    reset.
+  </description>
+  <interface name="zwp_relative_pointer_manager_v1" version="1">
+    <description summary="get relative pointer objects">
+      A global interface used for getting the relative pointer object for a
+      given pointer.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the relative pointer manager object">
+        Used by the client to notify the server that it will no longer use this
+        relative pointer manager object.
+      </description>
+    </request>
+    <request name="get_relative_pointer">
+      <description summary="get a relative pointer object">
+        Create a relative pointer interface given a wl_pointer object. See the
+        wp_relative_pointer interface for more details.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_relative_pointer_v1"/>
+      <arg name="pointer" type="object" interface="wl_pointer"/>
+    </request>
+  </interface>
+  <interface name="zwp_relative_pointer_v1" version="1">
+    <description summary="relative pointer object">
+      A wp_relative_pointer object is an extension to the wl_pointer interface
+      used for emitting relative pointer events. It shares the same focus as
+      wl_pointer objects of the same seat and will only emit events when it has
+      focus.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="release the relative pointer object"/>
+    </request>
+    <event name="relative_motion">
+      <description summary="relative pointer motion">
+        Relative x/y pointer motion from the pointer of the seat associated with
+        this object.
+        A relative motion is in the same dimension as regular wl_pointer motion
+        events, except they do not represent an absolute position. For example,
+        moving a pointer from (x, y) to (x', y') would have the equivalent
+        relative motion (x' - x, y' - y). If a pointer motion caused the
+        absolute pointer position to be clipped by for example the edge of the
+        monitor, the relative motion is unaffected by the clipping and will
+        represent the unclipped motion.
+        This event also contains non-accelerated motion deltas. The
+        non-accelerated delta is, when applicable, the regular pointer motion
+        delta as it was before having applied motion acceleration and other
+        transformations such as normalization.
+        Note that the non-accelerated delta does not represent 'raw' events as
+        they were read from some device. Pointer motion acceleration is device-
+        and configuration-specific and non-accelerated deltas and accelerated
+        deltas may have the same value on some devices.
+        Relative motions are not coupled to wl_pointer.motion events, and can be
+        sent in combination with such events, but also independently. There may
+        also be scenarios where wl_pointer.motion is sent, but there is no
+        relative motion. The order of an absolute and relative motion event
+        originating from the same physical motion is not guaranteed.
+        If the client needs button events or focus state, it can receive them
+        from a wl_pointer object of the same seat that the wp_relative_pointer
+        object is associated with.
+      </description>
+      <arg name="utime_hi" type="uint"
+           summary="high 32 bits of a 64 bit timestamp with microsecond granularity"/>
+      <arg name="utime_lo" type="uint"
+           summary="low 32 bits of a 64 bit timestamp with microsecond granularity"/>
+      <arg name="dx" type="fixed"
+           summary="the x component of the motion vector"/>
+      <arg name="dy" type="fixed"
+           summary="the y component of the motion vector"/>
+      <arg name="dx_unaccel" type="fixed"
+           summary="the x component of the unaccelerated motion vector"/>
+      <arg name="dy_unaccel" type="fixed"
+           summary="the y component of the unaccelerated motion vector"/>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/tablet-v2.xml b/src/contrib/SDL-3.2.20/wayland-protocols/tablet-v2.xml
new file mode 100644
index 0000000..55cd78e
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/tablet-v2.xml
@@ -0,0 +1,1178 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="tablet_v2">
+  <copyright>
+    Copyright 2014 © Stephen "Lyude" Chandler Paul
+    Copyright 2015-2016 © 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="Wayland protocol for graphics tablets">
+    This description provides a high-level overview of the interplay between
+    the interfaces defined this protocol. For details, see the protocol
+    specification.
+    More than one tablet may exist, and device-specifics matter. Tablets are
+    not represented by a single virtual device like wl_pointer. A client
+    binds to the tablet manager object which is just a proxy object. From
+    that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat)
+    and that returns the actual interface that has all the tablets. With
+    this indirection, we can avoid merging wp_tablet into the actual Wayland
+    protocol, a long-term benefit.
+    The wp_tablet_seat sends a "tablet added" event for each tablet
+    connected. That event is followed by descriptive events about the
+    hardware; currently that includes events for name, vid/pid and
+    a wp_tablet.path event that describes a local path. This path can be
+    used to uniquely identify a tablet or get more information through
+    libwacom. Emulated or nested tablets can skip any of those, e.g. a
+    virtual tablet may not have a vid/pid. The sequence of descriptive
+    events is terminated by a wp_tablet.done event to signal that a client
+    may now finalize any initialization for that tablet.
+    Events from tablets require a tool in proximity. Tools are also managed
+    by the tablet seat; a "tool added" event is sent whenever a tool is new
+    to the compositor. That event is followed by a number of descriptive
+    events about the hardware; currently that includes capabilities,
+    hardware id and serial number, and tool type. Similar to the tablet
+    interface, a wp_tablet_tool.done event is sent to terminate that initial
+    sequence.
+    Any event from a tool happens on the wp_tablet_tool interface. When the
+    tool gets into proximity of the tablet, a proximity_in event is sent on
+    the wp_tablet_tool interface, listing the tablet and the surface. That
+    event is followed by a motion event with the coordinates. After that,
+    it's the usual motion, axis, button, etc. events. The protocol's
+    serialisation means events are grouped by wp_tablet_tool.frame events.
+    Two special events (that don't exist in X) are down and up. They signal
+    "tip touching the surface". For tablets without real proximity
+    detection, the sequence is: proximity_in, motion, down, frame.
+    When the tool leaves proximity, a proximity_out event is sent. If any
+    button is still down, a button release event is sent before this
+    proximity event. These button events are sent in the same frame as the
+    proximity event to signal to the client that the buttons were held when
+    the tool left proximity.
+    If the tool moves out of the surface but stays in proximity (i.e.
+    between windows), compositor-specific grab policies apply. This usually
+    means that the proximity-out is delayed until all buttons are released.
+    Moving a tool physically from one tablet to the other has no real effect
+    on the protocol, since we already have the tool object from the "tool
+    added" event. All the information is already there and the proximity
+    events on both tablets are all a client needs to reconstruct what
+    happened.
+    Some extra axes are normalized, i.e. the client knows the range as
+    specified in the protocol (e.g. [0, 65535]), the granularity however is
+    unknown. The current normalized axes are pressure, distance, and slider.
+    Other extra axes are in physical units as specified in the protocol.
+    The current extra axes with physical units are tilt, rotation and
+    wheel rotation.
+    Since tablets work independently of the pointer controlled by the mouse,
+    the focus handling is independent too and controlled by proximity.
+    The wp_tablet_tool.set_cursor request sets a tool-specific cursor.
+    This cursor surface may be the same as the mouse cursor, and it may be
+    the same across tools but it is possible to be more fine-grained. For
+    example, a client may set different cursors for the pen and eraser.
+    Tools are generally independent of tablets and it is
+    compositor-specific policy when a tool can be removed. Common approaches
+    will likely include some form of removing a tool when all tablets the
+    tool was used on are removed.
+  </description>
+  <interface name="zwp_tablet_manager_v2" version="1">
+    <description summary="controller object for graphic tablet devices">
+      An object that provides access to the graphics tablets available on this
+      system. All tablets are associated with a seat, to get access to the
+      actual tablets, use wp_tablet_manager.get_tablet_seat.
+    </description>
+    <request name="get_tablet_seat">
+      <description summary="get the tablet seat">
+        Get the wp_tablet_seat object for the given seat. This object
+        provides access to all graphics tablets in this seat.
+      </description>
+      <arg name="tablet_seat" type="new_id" interface="zwp_tablet_seat_v2"/>
+      <arg name="seat" type="object" interface="wl_seat" summary="The wl_seat object to retrieve the tablets for" />
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="release the memory for the tablet manager object">
+        Destroy the wp_tablet_manager object. Objects created from this
+        object are unaffected and should be destroyed separately.
+      </description>
+    </request>
+  </interface>
+  <interface name="zwp_tablet_seat_v2" version="1">
+    <description summary="controller object for graphic tablet devices of a seat">
+      An object that provides access to the graphics tablets available on this
+      seat. After binding to this interface, the compositor sends a set of
+      wp_tablet_seat.tablet_added and wp_tablet_seat.tool_added events.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="release the memory for the tablet seat object">
+        Destroy the wp_tablet_seat object. Objects created from this
+        object are unaffected and should be destroyed separately.
+      </description>
+    </request>
+    <event name="tablet_added">
+      <description summary="new device notification">
+        This event is sent whenever a new tablet becomes available on this
+        seat. This event only provides the object id of the tablet, any
+        static information about the tablet (device name, vid/pid, etc.) is
+        sent through the wp_tablet interface.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_tablet_v2" summary="the newly added graphics tablet"/>
+    </event>
+    <event name="tool_added">
+      <description summary="a new tool has been used with a tablet">
+        This event is sent whenever a tool that has not previously been used
+        with a tablet comes into use. This event only provides the object id
+        of the tool; any static information about the tool (capabilities,
+        type, etc.) is sent through the wp_tablet_tool interface.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_tablet_tool_v2" summary="the newly added tablet tool"/>
+    </event>
+    <event name="pad_added">
+      <description summary="new pad notification">
+        This event is sent whenever a new pad is known to the system. Typically,
+        pads are physically attached to tablets and a pad_added event is
+        sent immediately after the wp_tablet_seat.tablet_added.
+        However, some standalone pad devices logically attach to tablets at
+        runtime, and the client must wait for wp_tablet_pad.enter to know
+        the tablet a pad is attached to.
+        This event only provides the object id of the pad. All further
+        features (buttons, strips, rings) are sent through the wp_tablet_pad
+        interface.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_tablet_pad_v2" summary="the newly added pad"/>
+    </event>
+  </interface>
+  <interface name="zwp_tablet_tool_v2" version="1">
+    <description summary="a physical tablet tool">
+      An object that represents a physical tool that has been, or is
+      currently in use with a tablet in this seat. Each wp_tablet_tool
+      object stays valid until the client destroys it; the compositor
+      reuses the wp_tablet_tool object to indicate that the object's
+      respective physical tool has come into proximity of a tablet again.
+      A wp_tablet_tool object's relation to a physical tool depends on the
+      tablet's ability to report serial numbers. If the tablet supports
+      this capability, then the object represents a specific physical tool
+      and can be identified even when used on multiple tablets.
+      A tablet tool has a number of static characteristics, e.g. tool type,
+      hardware_serial and capabilities. These capabilities are sent in an
+      event sequence after the wp_tablet_seat.tool_added event before any
+      actual events from this tool. This initial event sequence is
+      terminated by a wp_tablet_tool.done event.
+      Tablet tool events are grouped by wp_tablet_tool.frame events.
+      Any events received before a wp_tablet_tool.frame event should be
+      considered part of the same hardware state change.
+    </description>
+    <request name="set_cursor">
+      <description summary="set the tablet tool's surface">
+        Sets the surface of the cursor used for this tool on the given
+        tablet. This request only takes effect if the tool is in proximity
+        of one of the requesting client's surfaces or the surface parameter
+        is the current pointer surface. If there was a previous surface set
+        with this request it is replaced. If surface is NULL, the cursor
+        image is hidden.
+        The parameters hotspot_x and hotspot_y define the position of the
+        pointer surface relative to the pointer location. Its top-left corner
+        is always at (x, y) - (hotspot_x, hotspot_y), where (x, y) are the
+        coordinates of the pointer location, in surface-local coordinates.
+        On surface.attach requests to the pointer surface, hotspot_x and
+        hotspot_y are decremented by the x and y parameters passed to the
+        request. Attach must be confirmed by wl_surface.commit as usual.
+        The hotspot can also be updated by passing the currently set pointer
+        surface to this request with new values for hotspot_x and hotspot_y.
+        The current and pending input regions of the wl_surface are cleared,
+        and wl_surface.set_input_region is ignored until the wl_surface is no
+        longer used as the cursor. When the use as a cursor ends, the current
+        and pending input regions become undefined, and the wl_surface is
+        unmapped.
+        This request gives the surface the role of a wp_tablet_tool cursor. A
+        surface may only ever be used as the cursor surface for one
+        wp_tablet_tool. If the surface already has another role or has
+        previously been used as cursor surface for a different tool, a
+        protocol error is raised.
+      </description>
+      <arg name="serial" type="uint" summary="serial of the proximity_in event"/>
+      <arg name="surface" type="object" interface="wl_surface" allow-null="true"/>
+      <arg name="hotspot_x" type="int" summary="surface-local x coordinate"/>
+      <arg name="hotspot_y" type="int" summary="surface-local y coordinate"/>
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the tool object">
+        This destroys the client's resource for this tool object.
+      </description>
+    </request>
+    <enum name="type">
+      <description summary="a physical tool type">
+        Describes the physical type of a tool. The physical type of a tool
+        generally defines its base usage.
+        The mouse tool represents a mouse-shaped tool that is not a relative
+        device but bound to the tablet's surface, providing absolute
+        coordinates.
+        The lens tool is a mouse-shaped tool with an attached lens to
+        provide precision focus.
+      </description>
+      <entry name="pen" value="0x140" summary="Pen"/>
+      <entry name="eraser" value="0x141" summary="Eraser"/>
+      <entry name="brush" value="0x142" summary="Brush"/>
+      <entry name="pencil" value="0x143" summary="Pencil"/>
+      <entry name="airbrush" value="0x144" summary="Airbrush"/>
+      <entry name="finger" value="0x145" summary="Finger"/>
+      <entry name="mouse" value="0x146" summary="Mouse"/>
+      <entry name="lens" value="0x147" summary="Lens"/>
+    </enum>
+    <event name="type">
+      <description summary="tool type">
+        The tool type is the high-level type of the tool and usually decides
+        the interaction expected from this tool.
+        This event is sent in the initial burst of events before the
+        wp_tablet_tool.done event.
+      </description>
+      <arg name="tool_type" type="uint" enum="type" summary="the physical tool type"/>
+    </event>
+    <event name="hardware_serial">
+      <description summary="unique hardware serial number of the tool">
+        If the physical tool can be identified by a unique 64-bit serial
+        number, this event notifies the client of this serial number.
+        If multiple tablets are available in the same seat and the tool is
+        uniquely identifiable by the serial number, that tool may move
+        between tablets.
+        Otherwise, if the tool has no serial number and this event is
+        missing, the tool is tied to the tablet it first comes into
+        proximity with. Even if the physical tool is used on multiple
+        tablets, separate wp_tablet_tool objects will be created, one per
+        tablet.
+        This event is sent in the initial burst of events before the
+        wp_tablet_tool.done event.
+      </description>
+      <arg name="hardware_serial_hi" type="uint" summary="the unique serial number of the tool, most significant bits"/>
+      <arg name="hardware_serial_lo" type="uint" summary="the unique serial number of the tool, least significant bits"/>
+    </event>
+    <event name="hardware_id_wacom">
+      <description summary="hardware id notification in Wacom's format">
+        This event notifies the client of a hardware id available on this tool.
+        The hardware id is a device-specific 64-bit id that provides extra
+        information about the tool in use, beyond the wl_tool.type
+        enumeration. The format of the id is specific to tablets made by
+        Wacom Inc. For example, the hardware id of a Wacom Grip
+        Pen (a stylus) is 0x802.
+        This event is sent in the initial burst of events before the
+        wp_tablet_tool.done event.
+      </description>
+      <arg name="hardware_id_hi" type="uint" summary="the hardware id, most significant bits"/>
+      <arg name="hardware_id_lo" type="uint" summary="the hardware id, least significant bits"/>
+    </event>
+    <enum name="capability">
+      <description summary="capability flags for a tool">
+        Describes extra capabilities on a tablet.
+        Any tool must provide x and y values, extra axes are
+        device-specific.
+      </description>
+      <entry name="tilt" value="1" summary="Tilt axes"/>
+      <entry name="pressure" value="2" summary="Pressure axis"/>
+      <entry name="distance" value="3" summary="Distance axis"/>
+      <entry name="rotation" value="4" summary="Z-rotation axis"/>
+      <entry name="slider" value="5" summary="Slider axis"/>
+      <entry name="wheel" value="6" summary="Wheel axis"/>
+    </enum>
+    <event name="capability">
+      <description summary="tool capability notification">
+        This event notifies the client of any capabilities of this tool,
+        beyond the main set of x/y axes and tip up/down detection.
+        One event is sent for each extra capability available on this tool.
+        This event is sent in the initial burst of events before the
+        wp_tablet_tool.done event.
+      </description>
+      <arg name="capability" type="uint" enum="capability" summary="the capability"/>
+    </event>
+    <event name="done">
+      <description summary="tool description events sequence complete">
+        This event signals the end of the initial burst of descriptive
+        events. A client may consider the static description of the tool to
+        be complete and finalize initialization of the tool.
+      </description>
+    </event>
+    <event name="removed">
+      <description summary="tool removed">
+        This event is sent when the tool is removed from the system and will
+        send no further events. Should the physical tool come back into
+        proximity later, a new wp_tablet_tool object will be created.
+        It is compositor-dependent when a tool is removed. A compositor may
+        remove a tool on proximity out, tablet removal or any other reason.
+        A compositor may also keep a tool alive until shutdown.
+        If the tool is currently in proximity, a proximity_out event will be
+        sent before the removed event. See wp_tablet_tool.proximity_out for
+        the handling of any buttons logically down.
+        When this event is received, the client must wp_tablet_tool.destroy
+        the object.
+      </description>
+    </event>
+    <event name="proximity_in">
+      <description summary="proximity in event">
+        Notification that this tool is focused on a certain surface.
+        This event can be received when the tool has moved from one surface to
+        another, or when the tool has come back into proximity above the
+        surface.
+        If any button is logically down when the tool comes into proximity,
+        the respective button event is sent after the proximity_in event but
+        within the same frame as the proximity_in event.
+      </description>
+      <arg name="serial" type="uint"/>
+      <arg name="tablet" type="object" interface="zwp_tablet_v2" summary="The tablet the tool is in proximity of"/>
+      <arg name="surface" type="object" interface="wl_surface" summary="The current surface the tablet tool is over"/>
+    </event>
+    <event name="proximity_out">
+      <description summary="proximity out event">
+        Notification that this tool has either left proximity, or is no
+        longer focused on a certain surface.
+        When the tablet tool leaves proximity of the tablet, button release
+        events are sent for each button that was held down at the time of
+        leaving proximity. These events are sent before the proximity_out
+        event but within the same wp_tablet.frame.
+        If the tool stays within proximity of the tablet, but the focus
+        changes from one surface to another, a button release event may not
+        be sent until the button is actually released or the tool leaves the
+        proximity of the tablet.
+      </description>
+    </event>
+    <event name="down">
+      <description summary="tablet tool is making contact">
+        Sent whenever the tablet tool comes in contact with the surface of the
+        tablet.
+        If the tool is already in contact with the tablet when entering the
+        input region, the client owning said region will receive a
+        wp_tablet.proximity_in event, followed by a wp_tablet.down
+        event and a wp_tablet.frame event.
+        Note that this event describes logical contact, not physical
+        contact. On some devices, a compositor may not consider a tool in
+        logical contact until a minimum physical pressure threshold is
+        exceeded.
+      </description>
+      <arg name="serial" type="uint"/>
+    </event>
+    <event name="up">
+      <description summary="tablet tool is no longer making contact">
+        Sent whenever the tablet tool stops making contact with the surface of
+        the tablet, or when the tablet tool moves out of the input region
+        and the compositor grab (if any) is dismissed.
+        If the tablet tool moves out of the input region while in contact
+        with the surface of the tablet and the compositor does not have an
+        ongoing grab on the surface, the client owning said region will
+        receive a wp_tablet.up event, followed by a wp_tablet.proximity_out
+        event and a wp_tablet.frame event. If the compositor has an ongoing
+        grab on this device, this event sequence is sent whenever the grab
+        is dismissed in the future.
+        Note that this event describes logical contact, not physical
+        contact. On some devices, a compositor may not consider a tool out
+        of logical contact until physical pressure falls below a specific
+        threshold.
+      </description>
+    </event>
+    <event name="motion">
+      <description summary="motion event">
+        Sent whenever a tablet tool moves.
+      </description>
+      <arg name="x" type="fixed" summary="surface-local x coordinate"/>
+      <arg name="y" type="fixed" summary="surface-local y coordinate"/>
+    </event>
+    <event name="pressure">
+      <description summary="pressure change event">
+        Sent whenever the pressure axis on a tool changes. The value of this
+        event is normalized to a value between 0 and 65535.
+        Note that pressure may be nonzero even when a tool is not in logical
+        contact. See the down and up events for more details.
+      </description>
+      <arg name="pressure" type="uint" summary="The current pressure value"/>
+    </event>
+    <event name="distance">
+      <description summary="distance change event">
+        Sent whenever the distance axis on a tool changes. The value of this
+        event is normalized to a value between 0 and 65535.
+        Note that distance may be nonzero even when a tool is not in logical
+        contact. See the down and up events for more details.
+      </description>
+      <arg name="distance" type="uint" summary="The current distance value"/>
+    </event>
+    <event name="tilt">
+      <description summary="tilt change event">
+        Sent whenever one or both of the tilt axes on a tool change. Each tilt
+        value is in degrees, relative to the z-axis of the tablet.
+        The angle is positive when the top of a tool tilts along the
+        positive x or y axis.
+      </description>
+      <arg name="tilt_x" type="fixed" summary="The current value of the X tilt axis"/>
+      <arg name="tilt_y" type="fixed" summary="The current value of the Y tilt axis"/>
+    </event>
+    <event name="rotation">
+      <description summary="z-rotation change event">
+        Sent whenever the z-rotation axis on the tool changes. The
+        rotation value is in degrees clockwise from the tool's
+        logical neutral position.
+      </description>
+      <arg name="degrees" type="fixed" summary="The current rotation of the Z axis"/>
+    </event>
+    <event name="slider">
+      <description summary="Slider position change event">
+        Sent whenever the slider position on the tool changes. The
+        value is normalized between -65535 and 65535, with 0 as the logical
+        neutral position of the slider.
+        The slider is available on e.g. the Wacom Airbrush tool.
+      </description>
+      <arg name="position" type="int" summary="The current position of slider"/>
+    </event>
+    <event name="wheel">
+      <description summary="Wheel delta event">
+        Sent whenever the wheel on the tool emits an event. This event
+        contains two values for the same axis change. The degrees value is
+        in the same orientation as the wl_pointer.vertical_scroll axis. The
+        clicks value is in discrete logical clicks of the mouse wheel. This
+        value may be zero if the movement of the wheel was less
+        than one logical click.
+        Clients should choose either value and avoid mixing degrees and
+        clicks. The compositor may accumulate values smaller than a logical
+        click and emulate click events when a certain threshold is met.
+        Thus, wl_tablet_tool.wheel events with non-zero clicks values may
+        have different degrees values.
+      </description>
+      <arg name="degrees" type="fixed" summary="The wheel delta in degrees"/>
+      <arg name="clicks" type="int" summary="The wheel delta in discrete clicks"/>
+    </event>
+    <enum name="button_state">
+      <description summary="physical button state">
+        Describes the physical state of a button that produced the button event.
+      </description>
+      <entry name="released" value="0" summary="button is not pressed"/>
+      <entry name="pressed" value="1" summary="button is pressed"/>
+    </enum>
+    <event name="button">
+      <description summary="button event">
+        Sent whenever a button on the tool is pressed or released.
+        If a button is held down when the tool moves in or out of proximity,
+        button events are generated by the compositor. See
+        wp_tablet_tool.proximity_in and wp_tablet_tool.proximity_out for
+        details.
+      </description>
+      <arg name="serial" type="uint"/>
+      <arg name="button" type="uint" summary="The button whose state has changed"/>
+      <arg name="state" type="uint" enum="button_state" summary="Whether the button was pressed or released"/>
+    </event>
+    <event name="frame">
+      <description summary="frame event">
+        Marks the end of a series of axis and/or button updates from the
+        tablet. The Wayland protocol requires axis updates to be sent
+        sequentially, however all events within a frame should be considered
+        one hardware event.
+      </description>
+      <arg name="time" type="uint" summary="The time of the event with millisecond granularity"/>
+    </event>
+    <enum name="error">
+      <entry name="role" value="0" summary="given wl_surface has another role"/>
+    </enum>
+  </interface>
+  <interface name="zwp_tablet_v2" version="1">
+    <description summary="graphics tablet device">
+      The wp_tablet interface represents one graphics tablet device. The
+      tablet interface itself does not generate events; all events are
+      generated by wp_tablet_tool objects when in proximity above a tablet.
+      A tablet has a number of static characteristics, e.g. device name and
+      pid/vid. These capabilities are sent in an event sequence after the
+      wp_tablet_seat.tablet_added event. This initial event sequence is
+      terminated by a wp_tablet.done event.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the tablet object">
+        This destroys the client's resource for this tablet object.
+      </description>
+    </request>
+    <event name="name">
+      <description summary="tablet device name">
+        A descriptive name for the tablet device.
+        If the device has no descriptive name, this event is not sent.
+        This event is sent in the initial burst of events before the
+        wp_tablet.done event.
+      </description>
+      <arg name="name" type="string" summary="the device name"/>
+    </event>
+    <event name="id">
+      <description summary="tablet device USB vendor/product id">
+        The USB vendor and product IDs for the tablet device.
+        If the device has no USB vendor/product ID, this event is not sent.
+        This can happen for virtual devices or non-USB devices, for instance.
+        This event is sent in the initial burst of events before the
+        wp_tablet.done event.
+      </description>
+      <arg name="vid" type="uint" summary="USB vendor id"/>
+      <arg name="pid" type="uint" summary="USB product id"/>
+    </event>
+    <event name="path">
+      <description summary="path to the device">
+        A system-specific device path that indicates which device is behind
+        this wp_tablet. This information may be used to gather additional
+        information about the device, e.g. through libwacom.
+        A device may have more than one device path. If so, multiple
+        wp_tablet.path events are sent. A device may be emulated and not
+        have a device path, and in that case this event will not be sent.
+        The format of the path is unspecified, it may be a device node, a
+        sysfs path, or some other identifier. It is up to the client to
+        identify the string provided.
+        This event is sent in the initial burst of events before the
+        wp_tablet.done event.
+      </description>
+      <arg name="path" type="string" summary="path to local device"/>
+    </event>
+    <event name="done">
+      <description summary="tablet description events sequence complete">
+        This event is sent immediately to signal the end of the initial
+        burst of descriptive events. A client may consider the static
+        description of the tablet to be complete and finalize initialization
+        of the tablet.
+      </description>
+    </event>
+    <event name="removed">
+      <description summary="tablet removed event">
+        Sent when the tablet has been removed from the system. When a tablet
+        is removed, some tools may be removed.
+        When this event is received, the client must wp_tablet.destroy
+        the object.
+      </description>
+    </event>
+  </interface>
+  <interface name="zwp_tablet_pad_ring_v2" version="1">
+    <description summary="pad ring">
+      A circular interaction area, such as the touch ring on the Wacom Intuos
+      Pro series tablets.
+      Events on a ring are logically grouped by the wl_tablet_pad_ring.frame
+      event.
+    </description>
+    <request name="set_feedback">
+      <description summary="set compositor feedback">
+        Request that the compositor use the provided feedback string
+        associated with this ring. This request should be issued immediately
+        after a wp_tablet_pad_group.mode_switch event from the corresponding
+        group is received, or whenever the ring is mapped to a different
+        action. See wp_tablet_pad_group.mode_switch for more details.
+        Clients are encouraged to provide context-aware descriptions for
+        the actions associated with the ring; compositors may use this
+        information to offer visual feedback about the button layout
+        (eg. on-screen displays).
+        The provided string 'description' is a UTF-8 encoded string to be
+        associated with this ring, and is considered user-visible; general
+        internationalization rules apply.
+        The serial argument will be that of the last
+        wp_tablet_pad_group.mode_switch event received for the group of this
+        ring. Requests providing other serials than the most recent one will be
+        ignored.
+      </description>
+      <arg name="description" type="string" summary="ring description"/>
+      <arg name="serial" type="uint" summary="serial of the mode switch event"/>
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the ring object">
+        This destroys the client's resource for this ring object.
+      </description>
+    </request>
+    <enum name="source">
+      <description summary="ring axis source">
+        Describes the source types for ring events. This indicates to the
+        client how a ring event was physically generated; a client may
+        adjust the user interface accordingly. For example, events
+        from a "finger" source may trigger kinetic scrolling.
+      </description>
+      <entry name="finger" value="1" summary="finger"/>
+    </enum>
+    <event name="source">
+      <description summary="ring event source">
+        Source information for ring events.
+        This event does not occur on its own. It is sent before a
+        wp_tablet_pad_ring.frame event and carries the source information
+        for all events within that frame.
+        The source specifies how this event was generated. If the source is
+        wp_tablet_pad_ring.source.finger, a wp_tablet_pad_ring.stop event
+        will be sent when the user lifts the finger off the device.
+        This event is optional. If the source is unknown for an interaction,
+        no event is sent.
+      </description>
+      <arg name="source" type="uint" enum="source" summary="the event source"/>
+    </event>
+    <event name="angle">
+      <description summary="angle changed">
+        Sent whenever the angle on a ring changes.
+        The angle is provided in degrees clockwise from the logical
+        north of the ring in the pad's current rotation.
+      </description>
+      <arg name="degrees" type="fixed" summary="the current angle in degrees"/>
+    </event>
+    <event name="stop">
+      <description summary="interaction stopped">
+        Stop notification for ring events.
+        For some wp_tablet_pad_ring.source types, a wp_tablet_pad_ring.stop
+        event is sent to notify a client that the interaction with the ring
+        has terminated. This enables the client to implement kinetic scrolling.
+        See the wp_tablet_pad_ring.source documentation for information on
+        when this event may be generated.
+        Any wp_tablet_pad_ring.angle events with the same source after this
+        event should be considered as the start of a new interaction.
+      </description>
+    </event>
+    <event name="frame">
+      <description summary="end of a ring event sequence">
+        Indicates the end of a set of ring events that logically belong
+        together. A client is expected to accumulate the data in all events
+        within the frame before proceeding.
+        All wp_tablet_pad_ring events before a wp_tablet_pad_ring.frame event belong
+        logically together. For example, on termination of a finger interaction
+        on a ring the compositor will send a wp_tablet_pad_ring.source event,
+        a wp_tablet_pad_ring.stop event and a wp_tablet_pad_ring.frame event.
+        A wp_tablet_pad_ring.frame event is sent for every logical event
+        group, even if the group only contains a single wp_tablet_pad_ring
+        event. Specifically, a client may get a sequence: angle, frame,
+        angle, frame, etc.
+      </description>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+    </event>
+  </interface>
+  <interface name="zwp_tablet_pad_strip_v2" version="1">
+    <description summary="pad strip">
+      A linear interaction area, such as the strips found in Wacom Cintiq
+      models.
+      Events on a strip are logically grouped by the wl_tablet_pad_strip.frame
+      event.
+    </description>
+    <request name="set_feedback">
+      <description summary="set compositor feedback">
+        Requests the compositor to use the provided feedback string
+        associated with this strip. This request should be issued immediately
+        after a wp_tablet_pad_group.mode_switch event from the corresponding
+        group is received, or whenever the strip is mapped to a different
+        action. See wp_tablet_pad_group.mode_switch for more details.
+        Clients are encouraged to provide context-aware descriptions for
+        the actions associated with the strip, and compositors may use this
+        information to offer visual feedback about the button layout
+        (eg. on-screen displays).
+        The provided string 'description' is a UTF-8 encoded string to be
+        associated with this ring, and is considered user-visible; general
+        internationalization rules apply.
+        The serial argument will be that of the last
+        wp_tablet_pad_group.mode_switch event received for the group of this
+        strip. Requests providing other serials than the most recent one will be
+        ignored.
+      </description>
+      <arg name="description" type="string" summary="strip description"/>
+      <arg name="serial" type="uint" summary="serial of the mode switch event"/>
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the strip object">
+        This destroys the client's resource for this strip object.
+      </description>
+    </request>
+    <enum name="source">
+      <description summary="strip axis source">
+        Describes the source types for strip events. This indicates to the
+        client how a strip event was physically generated; a client may
+        adjust the user interface accordingly. For example, events
+        from a "finger" source may trigger kinetic scrolling.
+      </description>
+      <entry name="finger" value="1" summary="finger"/>
+    </enum>
+    <event name="source">
+      <description summary="strip event source">
+        Source information for strip events.
+        This event does not occur on its own. It is sent before a
+        wp_tablet_pad_strip.frame event and carries the source information
+        for all events within that frame.
+        The source specifies how this event was generated. If the source is
+        wp_tablet_pad_strip.source.finger, a wp_tablet_pad_strip.stop event
+        will be sent when the user lifts their finger off the device.
+        This event is optional. If the source is unknown for an interaction,
+        no event is sent.
+      </description>
+      <arg name="source" type="uint" enum="source" summary="the event source"/>
+    </event>
+    <event name="position">
+      <description summary="position changed">
+        Sent whenever the position on a strip changes.
+        The position is normalized to a range of [0, 65535], the 0-value
+        represents the top-most and/or left-most position of the strip in
+        the pad's current rotation.
+      </description>
+      <arg name="position" type="uint" summary="the current position"/>
+    </event>
+    <event name="stop">
+      <description summary="interaction stopped">
+        Stop notification for strip events.
+        For some wp_tablet_pad_strip.source types, a wp_tablet_pad_strip.stop
+        event is sent to notify a client that the interaction with the strip
+        has terminated. This enables the client to implement kinetic
+        scrolling. See the wp_tablet_pad_strip.source documentation for
+        information on when this event may be generated.
+        Any wp_tablet_pad_strip.position events with the same source after this
+        event should be considered as the start of a new interaction.
+      </description>
+    </event>
+    <event name="frame">
+      <description summary="end of a strip event sequence">
+        Indicates the end of a set of events that represent one logical
+        hardware strip event. A client is expected to accumulate the data
+        in all events within the frame before proceeding.
+        All wp_tablet_pad_strip events before a wp_tablet_pad_strip.frame event belong
+        logically together. For example, on termination of a finger interaction
+        on a strip the compositor will send a wp_tablet_pad_strip.source event,
+        a wp_tablet_pad_strip.stop event and a wp_tablet_pad_strip.frame
+        event.
+        A wp_tablet_pad_strip.frame event is sent for every logical event
+        group, even if the group only contains a single wp_tablet_pad_strip
+        event. Specifically, a client may get a sequence: position, frame,
+        position, frame, etc.
+      </description>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+    </event>
+  </interface>
+  <interface name="zwp_tablet_pad_group_v2" version="1">
+    <description summary="a set of buttons, rings and strips">
+      A pad group describes a distinct (sub)set of buttons, rings and strips
+      present in the tablet. The criteria of this grouping is usually positional,
+      eg. if a tablet has buttons on the left and right side, 2 groups will be
+      presented. The physical arrangement of groups is undisclosed and may
+      change on the fly.
+      Pad groups will announce their features during pad initialization. Between
+      the corresponding wp_tablet_pad.group event and wp_tablet_pad_group.done, the
+      pad group will announce the buttons, rings and strips contained in it,
+      plus the number of supported modes.
+      Modes are a mechanism to allow multiple groups of actions for every element
+      in the pad group. The number of groups and available modes in each is
+      persistent across device plugs. The current mode is user-switchable, it
+      will be announced through the wp_tablet_pad_group.mode_switch event both
+      whenever it is switched, and after wp_tablet_pad.enter.
+      The current mode logically applies to all elements in the pad group,
+      although it is at clients' discretion whether to actually perform different
+      actions, and/or issue the respective .set_feedback requests to notify the
+      compositor. See the wp_tablet_pad_group.mode_switch event for more details.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the pad object">
+        Destroy the wp_tablet_pad_group object. Objects created from this object
+        are unaffected and should be destroyed separately.
+      </description>
+    </request>
+    <event name="buttons">
+      <description summary="buttons announced">
+        Sent on wp_tablet_pad_group initialization to announce the available
+        buttons in the group. Button indices start at 0, a button may only be
+        in one group at a time.
+        This event is first sent in the initial burst of events before the
+        wp_tablet_pad_group.done event.
+        Some buttons are reserved by the compositor. These buttons may not be
+        assigned to any wp_tablet_pad_group. Compositors may broadcast this
+        event in the case of changes to the mapping of these reserved buttons.
+        If the compositor happens to reserve all buttons in a group, this event
+        will be sent with an empty array.
+      </description>
+      <arg name="buttons" type="array" summary="buttons in this group"/>
+    </event>
+    <event name="ring">
+      <description summary="ring announced">
+        Sent on wp_tablet_pad_group initialization to announce available rings.
+        One event is sent for each ring available on this pad group.
+        This event is sent in the initial burst of events before the
+        wp_tablet_pad_group.done event.
+      </description>
+      <arg name="ring" type="new_id" interface="zwp_tablet_pad_ring_v2"/>
+    </event>
+    <event name="strip">
+      <description summary="strip announced">
+        Sent on wp_tablet_pad initialization to announce available strips.
+        One event is sent for each strip available on this pad group.
+        This event is sent in the initial burst of events before the
+        wp_tablet_pad_group.done event.
+      </description>
+      <arg name="strip" type="new_id" interface="zwp_tablet_pad_strip_v2"/>
+    </event>
+    <event name="modes">
+      <description summary="mode-switch ability announced">
+        Sent on wp_tablet_pad_group initialization to announce that the pad
+        group may switch between modes. A client may use a mode to store a
+        specific configuration for buttons, rings and strips and use the
+        wl_tablet_pad_group.mode_switch event to toggle between these
+        configurations. Mode indices start at 0.
+        Switching modes is compositor-dependent. See the
+        wp_tablet_pad_group.mode_switch event for more details.
+        This event is sent in the initial burst of events before the
+        wp_tablet_pad_group.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"/>
+    </event>
+    <event name="done">
+      <description summary="tablet group description events sequence complete">
+        This event is sent immediately to signal the end of the initial
+        burst of descriptive events. A client may consider the static
+        description of the tablet to be complete and finalize initialization
+        of the tablet group.
+      </description>
+    </event>
+    <event name="mode_switch">
+      <description summary="mode switch event">
+        Notification that the mode was switched.
+        A mode applies to all buttons, rings and strips in a group
+        simultaneously, but a client is not required to assign different actions
+        for each mode. For example, a client may have mode-specific button
+        mappings but map the ring to vertical scrolling in all modes. Mode
+        indices start at 0.
+        Switching modes is compositor-dependent. The compositor may provide
+        visual cues to the client about the mode, e.g. by toggling LEDs on
+        the tablet device. Mode-switching may be software-controlled or
+        controlled by one or more physical buttons. For example, on a Wacom
+        Intuos Pro, the button inside the ring may be assigned to switch
+        between modes.
+        The compositor will also send this event after wp_tablet_pad.enter on
+        each group in order to notify of the current mode. Groups that only
+        feature one mode will use mode=0 when emitting this event.
+        If a button action in the new mode differs from the action in the
+        previous mode, the client should immediately issue a
+        wp_tablet_pad.set_feedback request for each changed button.
+        If a ring or strip action in the new mode differs from the action
+        in the previous mode, the client should immediately issue a
+        wp_tablet_ring.set_feedback or wp_tablet_strip.set_feedback request
+        for each changed ring or strip.
+      </description>
+      <arg name="time" type="uint" summary="the time of the event with millisecond granularity"/>
+      <arg name="serial" type="uint"/>
+      <arg name="mode" type="uint" summary="the new mode of the pad"/>
+    </event>
+  </interface>
+  <interface name="zwp_tablet_pad_v2" version="1">
+    <description summary="a set of buttons, rings and strips">
+      A pad device is a set of buttons, rings and strips
+      usually physically present on the tablet device itself. Some
+      exceptions exist where the pad device is physically detached, e.g. the
+      Wacom ExpressKey Remote.
+      Pad devices have no axes that control the cursor and are generally
+      auxiliary devices to the tool devices used on the tablet surface.
+      A pad device has a number of static characteristics, e.g. the number
+      of rings. These capabilities are sent in an event sequence after the
+      wp_tablet_seat.pad_added event before any actual events from this pad.
+      This initial event sequence is terminated by a wp_tablet_pad.done
+      event.
+      All pad features (buttons, rings and strips) are logically divided into
+      groups and all pads have at least one group. The available groups are
+      notified through the wp_tablet_pad.group event; the compositor will
+      emit one event per group before emitting wp_tablet_pad.done.
+      Groups may have multiple modes. Modes allow clients to map multiple
+      actions to a single pad feature. Only one mode can be active per group,
+      although different groups may have different active modes.
+    </description>
+    <request name="set_feedback">
+      <description summary="set compositor feedback">
+        Requests the compositor to use the provided feedback string
+        associated with this button. This request should be issued immediately
+        after a wp_tablet_pad_group.mode_switch event from the corresponding
+        group is received, or whenever a button is mapped to a different
+        action. See wp_tablet_pad_group.mode_switch for more details.
+        Clients are encouraged to provide context-aware descriptions for
+        the actions associated with each button, and compositors may use
+        this information to offer visual feedback on the button layout
+        (e.g. on-screen displays).
+        Button indices start at 0. Setting the feedback string on a button
+        that is reserved by the compositor (i.e. not belonging to any
+        wp_tablet_pad_group) does not generate an error but the compositor
+        is free to ignore the request.
+        The provided string 'description' is a UTF-8 encoded string to be
+        associated with this ring, and is considered user-visible; general
+        internationalization rules apply.
+        The serial argument will be that of the last
+        wp_tablet_pad_group.mode_switch event received for the group of this
+        button. Requests providing other serials than the most recent one will
+        be ignored.
+      </description>
+      <arg name="button" type="uint" summary="button index"/>
+      <arg name="description" type="string" summary="button description"/>
+      <arg name="serial" type="uint" summary="serial of the mode switch event"/>
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the pad object">
+        Destroy the wp_tablet_pad object. Objects created from this object
+        are unaffected and should be destroyed separately.
+      </description>
+    </request>
+    <event name="group">
+      <description summary="group announced">
+        Sent on wp_tablet_pad initialization to announce available groups.
+        One event is sent for each pad group available.
+        This event is sent in the initial burst of events before the
+        wp_tablet_pad.done event. At least one group will be announced.
+      </description>
+      <arg name="pad_group" type="new_id" interface="zwp_tablet_pad_group_v2"/>
+    </event>
+    <event name="path">
+      <description summary="path to the device">
+        A system-specific device path that indicates which device is behind
+        this wp_tablet_pad. This information may be used to gather additional
+        information about the device, e.g. through libwacom.
+        The format of the path is unspecified, it may be a device node, a
+        sysfs path, or some other identifier. It is up to the client to
+        identify the string provided.
+        This event is sent in the initial burst of events before the
+        wp_tablet_pad.done event.
+      </description>
+      <arg name="path" type="string" summary="path to local device"/>
+    </event>
+    <event name="buttons">
+      <description summary="buttons announced">
+        Sent on wp_tablet_pad initialization to announce the available
+        buttons.
+        This event is sent in the initial burst of events before the
+        wp_tablet_pad.done event. This event is only sent when at least one
+        button is available.
+      </description>
+      <arg name="buttons" type="uint" summary="the number of buttons"/>
+    </event>
+    <event name="done">
+      <description summary="pad description event sequence complete">
+        This event signals the end of the initial burst of descriptive
+        events. A client may consider the static description of the pad to
+        be complete and finalize initialization of the pad.
+      </description>
+    </event>
+    <enum name="button_state">
+      <description summary="physical button state">
+        Describes the physical state of a button that caused the button
+        event.
+      </description>
+      <entry name="released" value="0" summary="the button is not pressed"/>
+      <entry name="pressed" value="1" summary="the button is pressed"/>
+    </enum>
+    <event name="button">
+      <description summary="physical button state">
+        Sent whenever the physical state of a button changes.
+      </description>
+      <arg name="time" type="uint" summary="the time of the event with millisecond granularity"/>
+      <arg name="button" type="uint" summary="the index of the button that changed state"/>
+      <arg name="state" type="uint" enum="button_state"/>
+    </event>
+    <event name="enter">
+      <description summary="enter event">
+        Notification that this pad is focused on the specified surface.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the enter event"/>
+      <arg name="tablet" type="object" interface="zwp_tablet_v2" summary="the tablet the pad is attached to"/>
+      <arg name="surface" type="object" interface="wl_surface" summary="surface the pad is focused on"/>
+    </event>
+    <event name="leave">
+      <description summary="leave event">
+        Notification that this pad is no longer focused on the specified
+        surface.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the leave event"/>
+      <arg name="surface" type="object" interface="wl_surface" summary="surface the pad is no longer focused on"/>
+    </event>
+    <event name="removed">
+      <description summary="pad removed event">
+        Sent when the pad has been removed from the system. When a tablet
+        is removed its pad(s) will be removed too.
+        When this event is received, the client must destroy all rings, strips
+        and groups that were offered by this pad, and issue wp_tablet_pad.destroy
+        the pad itself.
+      </description>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/text-input-unstable-v3.xml b/src/contrib/SDL-3.2.20/wayland-protocols/text-input-unstable-v3.xml
new file mode 100644
index 0000000..d5f6322
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/text-input-unstable-v3.xml
@@ -0,0 +1,452 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="text_input_unstable_v3">
+  <copyright>
+    Copyright © 2012, 2013 Intel Corporation
+    Copyright © 2015, 2016 Jan Arne Petersen
+    Copyright © 2017, 2018 Red Hat, Inc.
+    Copyright © 2018       Purism SPC
+    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>
+  <description summary="Protocol for composing text">
+    This protocol allows compositors to act as input methods and to send text
+    to applications. A text input object is used to manage state of what are
+    typically text entry fields in the application.
+    This document adheres to the RFC 2119 when using words like "must",
+    "should", "may", etc.
+    Warning! The protocol described in this file is experimental and
+    backward incompatible changes may be made. Backward compatible changes
+    may be added together with the corresponding interface version bump.
+    Backward incompatible changes are done by bumping the version number in
+    the protocol and interface names and resetting the interface version.
+    Once the protocol is to be declared stable, the 'z' prefix and the
+    version number in the protocol and interface names are removed and the
+    interface version number is reset.
+  </description>
+  <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
+      text input focus for a seat.
+      Requests are used to enable/disable the text-input object and set
+      state information like surrounding and selected text or the content type.
+      The information about the entered text is sent to the text-input object
+      via the preedit_string and commit_string events.
+      Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+      must not point to middle bytes inside a code point: they must either
+      point to the first byte of a code point or to the end of the buffer.
+      Lengths must be measured between two valid indices.
+      Focus moving throughout surfaces will result in the emission of
+      zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
+      surface must commit zwp_text_input_v3.enable and
+      zwp_text_input_v3.disable requests as the keyboard focus moves across
+      editable and non-editable elements of the UI. Those two requests are not
+      expected to be paired with each other, the compositor must be able to
+      handle consecutive series of the same request.
+      State is sent by the state requests (set_surrounding_text,
+      set_content_type and set_cursor_rectangle) and a commit request. After an
+      enter event or disable request all state information is invalidated and
+      needs to be resent by the client.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="Destroy the wp_text_input">
+        Destroy the wp_text_input object. Also disables all surfaces enabled
+        through this wp_text_input object.
+      </description>
+    </request>
+    <request name="enable">
+      <description summary="Request text input to be enabled">
+        Requests text input on the surface previously obtained from the enter
+        event.
+        This request must be issued every time the active text input changes
+        to a new one, including within the current surface. Use
+        zwp_text_input_v3.disable when there is no longer any input focus on
+        the current surface.
+        Clients must not enable more than one text input on the single seat
+        and should disable the current text input before enabling the new one.
+        At most one instance of text input may be in enabled state per instance,
+        Requests to enable the another text input when some text input is active
+        must be ignored by compositor.
+        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, and delete_surrounding_text events.
+        The set_surrounding_text, set_content_type and set_cursor_rectangle
+        requests must follow if the text input supports the necessary
+        functionality.
+        State set with this request is double-buffered. It will get applied on
+        the next zwp_text_input_v3.commit request, and stay valid until the
+        next committed enable or disable request.
+        The changes must be applied by the compositor after issuing a
+        zwp_text_input_v3.commit request.
+      </description>
+    </request>
+    <request name="disable">
+      <description summary="Disable text input on a surface">
+        Explicitly disable text input on the current surface (typically when
+        there is no focus on any text entry inside the surface).
+        State set with this request is double-buffered. It will get applied on
+        the next zwp_text_input_v3.commit request.
+      </description>
+    </request>
+    <request name="set_surrounding_text">
+      <description summary="sets the surrounding text">
+        Sets the surrounding plain text around the input, excluding the preedit
+        text.
+        The client should notify the compositor of any changes in any of the
+        values carried with this request, including changes caused by handling
+        incoming text-input events as well as changes caused by other
+        mechanisms like keyboard typing.
+        If the client is unaware of the text around the cursor, it should not
+        issue this request, to signify lack of support to the compositor.
+        Text is UTF-8 encoded, and should include the cursor position, the
+        complete selection and additional characters before and after them.
+        There is a maximum length of wayland messages, so text can not be
+        longer than 4000 bytes.
+        Cursor is the byte offset of the cursor within text buffer.
+        Anchor is the byte offset of the selection anchor within text buffer.
+        If there is no selected text, anchor is the same as cursor.
+        If any preedit text is present, it is replaced with a cursor for the
+        purpose of this event.
+        Values set with this request are double-buffered. They will get applied
+        on the next zwp_text_input_v3.commit request, and stay valid until the
+        next committed enable or disable request.
+        The initial state for affected fields is empty, meaning that the text
+        input does not support sending surrounding text. If the empty values
+        get applied, subsequent attempts to change them may have no effect.
+      </description>
+      <arg name="text" type="string"/>
+      <arg name="cursor" type="int"/>
+      <arg name="anchor" type="int"/>
+    </request>
+    <enum name="change_cause">
+      <description summary="text change reason">
+        Reason for the change of surrounding text or cursor posision.
+      </description>
+      <entry name="input_method" value="0" summary="input method caused the change"/>
+      <entry name="other" value="1" summary="something else than the input method caused the change"/>
+    </enum>
+    <request name="set_text_change_cause">
+      <description summary="indicates the cause of surrounding text change">
+        Tells the compositor why the text surrounding the cursor changed.
+        Whenever the client detects an external change in text, cursor, or
+        anchor posision, it must issue this request to the compositor. This
+        request is intended to give the input method a chance to update the
+        preedit text in an appropriate way, e.g. by removing it when the user
+        starts typing with a keyboard.
+        cause describes the source of the change.
+        The value set with this request is double-buffered. It must be applied
+        and reset to initial at the next zwp_text_input_v3.commit request.
+        The initial value of cause is input_method.
+      </description>
+      <arg name="cause" type="uint" enum="change_cause"/>
+    </request>
+    <enum name="content_hint" bitfield="true">
+      <description summary="content hint">
+        Content hint is a bitmask to allow to modify the behavior of the text
+        input.
+      </description>
+      <entry name="none" value="0x0" summary="no special behavior"/>
+      <entry name="completion" value="0x1" summary="suggest word completions"/>
+      <entry name="spellcheck" value="0x2" summary="suggest word corrections"/>
+      <entry name="auto_capitalization" value="0x4" summary="switch to uppercase letters at the start of a sentence"/>
+      <entry name="lowercase" value="0x8" summary="prefer lowercase letters"/>
+      <entry name="uppercase" value="0x10" summary="prefer uppercase letters"/>
+      <entry name="titlecase" value="0x20" summary="prefer casing for titles and headings (can be language dependent)"/>
+      <entry name="hidden_text" value="0x40" summary="characters should be hidden"/>
+      <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"/>
+    </enum>
+    <enum name="content_purpose">
+      <description summary="content purpose">
+        The content purpose allows to specify the primary purpose of a text
+        input.
+        This allows an input method to show special purpose input panels with
+        extra characters or to disallow some characters.
+      </description>
+      <entry name="normal" value="0" summary="default input, allowing all characters"/>
+      <entry name="alpha" value="1" summary="allow only alphabetic characters"/>
+      <entry name="digits" value="2" summary="allow only digits"/>
+      <entry name="number" value="3" summary="input a number (including decimal separator and sign)"/>
+      <entry name="phone" value="4" summary="input a phone number"/>
+      <entry name="url" value="5" summary="input an URL"/>
+      <entry name="email" value="6" summary="input an email address"/>
+      <entry name="name" value="7" summary="input a name of a person"/>
+      <entry name="password" value="8" summary="input a password (combine with sensitive_data hint)"/>
+      <entry name="pin" value="9" summary="input is a numeric password (combine with sensitive_data hint)"/>
+      <entry name="date" value="10" summary="input a date"/>
+      <entry name="time" value="11" summary="input a time"/>
+      <entry name="datetime" value="12" summary="input a date and time"/>
+      <entry name="terminal" value="13" summary="input for a terminal"/>
+    </enum>
+    <request name="set_content_type">
+      <description summary="set content purpose and hint">
+        Sets the content purpose and content hint. While the purpose is the
+        basic purpose of an input field, the hint flags allow to modify some of
+        the behavior.
+        Values set with this request are double-buffered. They will get applied
+        on the next zwp_text_input_v3.commit request.
+        Subsequent attempts to update them may have no effect. The values
+        remain valid until the next committed enable or disable request.
+        The initial value for hint is none, and the initial value for purpose
+        is normal.
+      </description>
+      <arg name="hint" type="uint" enum="content_hint"/>
+      <arg name="purpose" type="uint" enum="content_purpose"/>
+    </request>
+    <request name="set_cursor_rectangle">
+      <description summary="set cursor position">
+        Marks an area around the cursor as a x, y, width, height rectangle in
+        surface local coordinates.
+        Allows the compositor to put a window with word suggestions near the
+        cursor, without obstructing the text being input.
+        If the client is unaware of the position of edited text, it should not
+        issue this request, to signify lack of support to the compositor.
+        Values set with this request are double-buffered. They will get applied
+        on the next zwp_text_input_v3.commit request, and stay valid until the
+        next committed enable or disable request.
+        The initial values describing a cursor rectangle are empty. That means
+        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.
+      </description>
+      <arg name="x" type="int"/>
+      <arg name="y" type="int"/>
+      <arg name="width" type="int"/>
+      <arg name="height" type="int"/>
+    </request>
+    <request name="commit">
+      <description summary="commit state">
+        Atomically applies state changes recently sent to the compositor.
+        The commit request establishes and updates the state of the client, and
+        must be issued after any changes to apply them.
+        Text input state (enabled status, content purpose, content hint,
+        surrounding text and change cause, cursor rectangle) is conceptually
+        double-buffered within the context of a text input, i.e. between a
+        committed enable request and the following committed enable or disable
+        request.
+        Protocol requests modify the pending state, as opposed to the current
+        state in use by the input method. A commit request atomically applies
+        all pending state, replacing the current state. After commit, the new
+        pending state is as documented for each related request.
+        Requests are applied in the order of arrival.
+        Neither current nor pending state are modified unless noted otherwise.
+        The compositor must count the number of commit requests coming from
+        each zwp_text_input_v3 object and use the count as the serial in done
+        events.
+      </description>
+    </request>
+    <event name="enter">
+      <description summary="enter event">
+        Notification that this seat's text-input focus is on a certain surface.
+        If client has created multiple text input objects, compositor must send
+        this event to all of them.
+        When the seat has the keyboard capability the text-input focus follows
+        the keyboard focus. This event sets the current surface for the
+        text-input object.
+      </description>
+      <arg name="surface" type="object" interface="wl_surface"/>
+    </event>
+    <event name="leave">
+      <description summary="leave event">
+        Notification that this seat's text-input focus is no longer on a
+        certain surface. The client should reset any preedit string previously
+        set.
+        The leave notification clears the current surface. It is sent before
+        the enter notification for the new focus. After leave event, compositor
+        must ignore requests from any text input instances until next enter
+        event.
+        When the seat has the keyboard capability the text-input focus follows
+        the keyboard focus.
+      </description>
+      <arg name="surface" type="object" interface="wl_surface"/>
+    </event>
+    <event name="preedit_string">
+      <description summary="pre-edit">
+        Notify when a new composing text (pre-edit) should be set at the
+        current cursor position. Any previously set composing text must be
+        removed. Any previously existing selected text must be removed.
+        The argument text contains the pre-edit string buffer.
+        The parameters cursor_begin and cursor_end are counted in bytes
+        relative to the beginning of the submitted text buffer. Cursor should
+        be hidden when both are equal to -1.
+        They could be represented by the client as a line if both values are
+        the same, or as a text highlight otherwise.
+        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 text is an empty string, and cursor_begin,
+        cursor_end and cursor_hidden are all 0.
+      </description>
+      <arg name="text" type="string" allow-null="true"/>
+      <arg name="cursor_begin" type="int"/>
+      <arg name="cursor_end" type="int"/>
+    </event>
+    <event name="commit_string">
+      <description summary="text commit">
+        Notify when text should be inserted into the editor widget. The text to
+        commit could be either just a single character after a key press or the
+        result of some composing (pre-edit).
+        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 text is an empty string.
+      </description>
+      <arg name="text" type="string" allow-null="true"/>
+    </event>
+    <event name="delete_surrounding_text">
+      <description summary="delete surrounding text">
+        Notify when the text around the current cursor position should be
+        deleted.
+        Before_length and after_length are the number of bytes before and after
+        the current cursor index (excluding the selection) to delete.
+        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).
+        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 values of both before_length and after_length are 0.
+      </description>
+      <arg name="before_length" type="uint" summary="length of text before current cursor position"/>
+      <arg name="after_length" type="uint" summary="length of text after current cursor position"/>
+    </event>
+    <event name="done">
+      <description summary="apply changes">
+        Instruct the application to apply changes to state requested by the
+        preedit_string, commit_string and delete_surrounding_text events. 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.
+        The application must proceed by evaluating the changes in the following
+        order:
+        1. Replace existing preedit string with the cursor.
+        2. Delete requested surrounding text.
+        3. Insert commit string with the cursor at its end.
+        4. Calculate surrounding text to send.
+        5. Insert new preedit text in cursor position.
+        6. Place cursor inside preedit text.
+        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
+        be equal to the number of commit requests already issued on that object.
+        When the client receives a done event with a serial different than the
+        number of past commit requests, it must proceed as normal, except it
+        should not change the current state of the zwp_text_input_v3 object.
+      </description>
+      <arg name="serial" type="uint"/>
+    </event>
+  </interface>
+  <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>
+    <request name="destroy" type="destructor">
+      <description summary="Destroy the wp_text_input_manager">
+        Destroy the wp_text_input_manager object.
+      </description>
+    </request>
+    <request name="get_text_input">
+      <description summary="create a new text input object">
+        Creates a new text-input object for a given seat.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_text_input_v3"/>
+      <arg name="seat" type="object" interface="wl_seat"/>
+    </request>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/viewporter.xml b/src/contrib/SDL-3.2.20/wayland-protocols/viewporter.xml
new file mode 100644
index 0000000..c732d8c
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/viewporter.xml
@@ -0,0 +1,186 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="viewporter">
+  <copyright>
+    Copyright © 2013-2016 Collabora, Ltd.
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+  <interface name="wp_viewporter" version="1">
+    <description summary="surface cropping and scaling">
+      The global interface exposing surface cropping and scaling
+      capabilities is used to instantiate an interface extension for a
+      wl_surface object. This extended interface will then allow
+      cropping and scaling the surface contents, effectively
+      disconnecting the direct relationship between the buffer and the
+      surface size.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="unbind from the cropping and scaling interface">
+        Informs the server that the client will not be using this
+        protocol object anymore. This does not affect any other objects,
+        wp_viewport objects included.
+      </description>
+    </request>
+    <enum name="error">
+      <entry name="viewport_exists" value="0"
+             summary="the surface already has a viewport object associated"/>
+    </enum>
+    <request name="get_viewport">
+      <description summary="extend surface interface for crop and scale">
+        Instantiate an interface extension for the given wl_surface to
+        crop and scale its content. If the given wl_surface already has
+        a wp_viewport object associated, the viewport_exists
+        protocol error is raised.
+      </description>
+      <arg name="id" type="new_id" interface="wp_viewport"
+           summary="the new viewport interface id"/>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="the surface"/>
+    </request>
+  </interface>
+  <interface name="wp_viewport" version="1">
+    <description summary="crop and scale interface to a wl_surface">
+      An additional interface to a wl_surface object, which allows the
+      client to specify the cropping and scaling of the surface
+      contents.
+      This interface works with two concepts: the source rectangle (src_x,
+      src_y, src_width, src_height), and the destination size (dst_width,
+      dst_height). The contents of the source rectangle are scaled to the
+      destination size, and content outside the source rectangle is ignored.
+      This state is double-buffered, and is applied on the next
+      wl_surface.commit.
+      The two parts of crop and scale state are independent: the source
+      rectangle, and the destination size. Initially both are unset, that
+      is, no scaling is applied. The whole of the current wl_buffer is
+      used as the source, and the surface size is as defined in
+      wl_surface.attach.
+      If the destination size is set, it causes the surface size to become
+      dst_width, dst_height. The source (rectangle) is scaled to exactly
+      this size. This overrides whatever the attached wl_buffer size is,
+      unless the wl_buffer is NULL. If the wl_buffer is NULL, the surface
+      has no content and therefore no size. Otherwise, the size is always
+      at least 1x1 in surface local coordinates.
+      If the source rectangle is set, it defines what area of the wl_buffer is
+      taken as the source. If the source rectangle is set and the destination
+      size is not set, then src_width and src_height must be integers, and the
+      surface size becomes the source rectangle size. This results in cropping
+      without scaling. If src_width or src_height are not integers and
+      destination size is not set, the bad_size protocol error is raised when
+      the surface state is applied.
+      The coordinate transformations from buffer pixel coordinates up to
+      the surface-local coordinates happen in the following order:
+        1. buffer_transform (wl_surface.set_buffer_transform)
+        2. buffer_scale (wl_surface.set_buffer_scale)
+        3. crop and scale (wp_viewport.set*)
+      This means, that the source rectangle coordinates of crop and scale
+      are given in the coordinates after the buffer transform and scale,
+      i.e. in the coordinates that would be the surface-local coordinates
+      if the crop and scale was not applied.
+      If src_x or src_y are negative, the bad_value protocol error is raised.
+      Otherwise, if the source rectangle is partially or completely outside of
+      the non-NULL wl_buffer, then the out_of_buffer protocol error is raised
+      when the surface state is applied. A NULL wl_buffer does not raise the
+      out_of_buffer error.
+      The x, y arguments of wl_surface.attach are applied as normal to
+      the surface. They indicate how many pixels to remove from the
+      surface size from the left and the top. In other words, they are
+      still in the surface-local coordinate system, just like dst_width
+      and dst_height are.
+      If the wl_surface associated with the wp_viewport is destroyed,
+      all wp_viewport requests except 'destroy' raise the protocol error
+      no_surface.
+      If the wp_viewport object is destroyed, the crop and scale
+      state is removed from the wl_surface. The change will be applied
+      on the next wl_surface.commit.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="remove scaling and cropping from the surface">
+        The associated wl_surface's crop and scale state is removed.
+        The change is applied on the next wl_surface.commit.
+      </description>
+    </request>
+    <enum name="error">
+      <entry name="bad_value" value="0"
+             summary="negative or zero values in width or height"/>
+      <entry name="bad_size" value="1"
+             summary="destination size is not integer"/>
+      <entry name="out_of_buffer" value="2"
+             summary="source rectangle extends outside of the content area"/>
+      <entry name="no_surface" value="3"
+             summary="the wl_surface was destroyed"/>
+    </enum>
+    <request name="set_source">
+      <description summary="set the source rectangle for cropping">
+        Set the source rectangle of the associated wl_surface. See
+        wp_viewport for the description, and relation to the wl_buffer
+        size.
+        If all of x, y, width and height are -1.0, the source rectangle is
+        unset instead. Any other set of values where width or height are zero
+        or negative, or x or y are negative, raise the bad_value protocol
+        error.
+        The crop and scale state is double-buffered state, and will be
+        applied on the next wl_surface.commit.
+      </description>
+      <arg name="x" type="fixed" summary="source rectangle x"/>
+      <arg name="y" type="fixed" summary="source rectangle y"/>
+      <arg name="width" type="fixed" summary="source rectangle width"/>
+      <arg name="height" type="fixed" summary="source rectangle height"/>
+    </request>
+    <request name="set_destination">
+      <description summary="set the surface size for scaling">
+        Set the destination size of the associated wl_surface. See
+        wp_viewport for the description, and relation to the wl_buffer
+        size.
+        If width is -1 and height is -1, the destination size is unset
+        instead. Any other pair of values for width and height that
+        contains zero or negative values raises the bad_value protocol
+        error.
+        The crop and scale state is double-buffered state, and will be
+        applied on the next wl_surface.commit.
+      </description>
+      <arg name="width" type="int" summary="surface width"/>
+      <arg name="height" type="int" summary="surface height"/>
+    </request>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/wayland.xml b/src/contrib/SDL-3.2.20/wayland-protocols/wayland.xml
new file mode 100644
index 0000000..10e039d
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/wayland.xml
@@ -0,0 +1,3151 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="wayland">
+  <copyright>
+    Copyright © 2008-2011 Kristian Høgsberg
+    Copyright © 2010-2011 Intel Corporation
+    Copyright © 2012-2013 Collabora, Ltd.
+    Permission is hereby granted, free of charge, to any person
+    obtaining a copy of this software and associated documentation files
+    (the "Software"), to deal in the Software without restriction,
+    including without limitation the rights to use, copy, modify, merge,
+    publish, distribute, sublicense, and/or sell copies of the Software,
+    and to permit persons to whom the Software is furnished to do so,
+    subject to the following conditions:
+    The above copyright notice and this permission notice (including the
+    next paragraph) shall be included in all copies or substantial
+    portions of the Software.
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+    NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+    BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+    ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+    CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+    SOFTWARE.
+  </copyright>
+  <interface name="wl_display" version="1">
+    <description summary="core global object">
+      The core global object.  This is a special singleton object.  It
+      is used for internal Wayland protocol features.
+    </description>
+    <request name="sync">
+      <description summary="asynchronous roundtrip">
+        The sync request asks the server to emit the 'done' event
+        on the returned wl_callback object.  Since requests are
+        handled in-order and events are delivered in-order, this can
+        be used as a barrier to ensure all previous requests and the
+        resulting events have been handled.
+        The object returned by this request will be destroyed by the
+        compositor after the callback is fired and as such the client must not
+        attempt to use it after that point.
+        The callback_data passed in the callback is the event serial.
+      </description>
+      <arg name="callback" type="new_id" interface="wl_callback"
+           summary="callback object for the sync request"/>
+    </request>
+    <request name="get_registry">
+      <description summary="get global registry object">
+        This request creates a registry object that allows the client
+        to list and bind the global objects available from the
+        compositor.
+        It should be noted that the server side resources consumed in
+        response to a get_registry request can only be released when the
+        client disconnects, not when the client side proxy is destroyed.
+        Therefore, clients should invoke get_registry as infrequently as
+        possible to avoid wasting memory.
+      </description>
+      <arg name="registry" type="new_id" interface="wl_registry"
+           summary="global registry object"/>
+    </request>
+    <event name="error">
+      <description summary="fatal error event">
+        The error event is sent out when a fatal (non-recoverable)
+        error has occurred.  The object_id argument is the object
+        where the error occurred, most often in response to a request
+        to that object.  The code identifies the error and is defined
+        by the object interface.  As such, each interface defines its
+        own set of error codes.  The message is a brief description
+        of the error, for (debugging) convenience.
+      </description>
+      <arg name="object_id" type="object" summary="object where the error occurred"/>
+      <arg name="code" type="uint" summary="error code"/>
+      <arg name="message" type="string" summary="error description"/>
+    </event>
+    <enum name="error">
+      <description summary="global error values">
+        These errors are global and can be emitted in response to any
+        server request.
+      </description>
+      <entry name="invalid_object" value="0"
+             summary="server couldn't find object"/>
+      <entry name="invalid_method" value="1"
+             summary="method doesn't exist on the specified interface or malformed request"/>
+      <entry name="no_memory" value="2"
+             summary="server is out of memory"/>
+      <entry name="implementation" value="3"
+             summary="implementation error in compositor"/>
+    </enum>
+    <event name="delete_id">
+      <description summary="acknowledge object ID deletion">
+        This event is used internally by the object ID management
+        logic. When a client deletes an object that it had created,
+        the server will send this event to acknowledge that it has
+        seen the delete request. When the client receives this event,
+        it will know that it can safely reuse the object ID.
+      </description>
+      <arg name="id" type="uint" summary="deleted object ID"/>
+    </event>
+  </interface>
+  <interface name="wl_registry" version="1">
+    <description summary="global registry object">
+      The singleton global registry object.  The server has a number of
+      global objects that are available to all clients.  These objects
+      typically represent an actual object in the server (for example,
+      an input device) or they are singleton objects that provide
+      extension functionality.
+      When a client creates a registry object, the registry object
+      will emit a global event for each global currently in the
+      registry.  Globals come and go as a result of device or
+      monitor hotplugs, reconfiguration or other events, and the
+      registry will send out global and global_remove events to
+      keep the client up to date with the changes.  To mark the end
+      of the initial burst of events, the client can use the
+      wl_display.sync request immediately after calling
+      wl_display.get_registry.
+      A client can bind to a global object by using the bind
+      request.  This creates a client-side handle that lets the object
+      emit events to the client and lets the client invoke requests on
+      the object.
+    </description>
+    <request name="bind">
+      <description summary="bind an object to the display">
+        Binds a new, client-created object to the server using the
+        specified name as the identifier.
+      </description>
+      <arg name="name" type="uint" summary="unique numeric name of the object"/>
+      <arg name="id" type="new_id" summary="bounded object"/>
+    </request>
+    <event name="global">
+      <description summary="announce global object">
+        Notify the client of global objects.
+        The event notifies the client that a global object with
+        the given name is now available, and it implements the
+        given version of the given interface.
+      </description>
+      <arg name="name" type="uint" summary="numeric name of the global object"/>
+      <arg name="interface" type="string" summary="interface implemented by the object"/>
+      <arg name="version" type="uint" summary="interface version"/>
+    </event>
+    <event name="global_remove">
+      <description summary="announce removal of global object">
+        Notify the client of removed global objects.
+        This event notifies the client that the global identified
+        by name is no longer available.  If the client bound to
+        the global using the bind request, the client should now
+        destroy that object.
+        The object remains valid and requests to the object will be
+        ignored until the client destroys it, to avoid races between
+        the global going away and a client sending a request to it.
+      </description>
+      <arg name="name" type="uint" summary="numeric name of the global object"/>
+    </event>
+  </interface>
+  <interface name="wl_callback" version="1">
+    <description summary="callback object">
+      Clients can handle the 'done' event to get notified when
+      the related request is done.
+      Note, because wl_callback objects are created from multiple independent
+      factory interfaces, the wl_callback interface is frozen at version 1.
+    </description>
+    <event name="done" type="destructor">
+      <description summary="done event">
+        Notify the client when the related request is done.
+      </description>
+      <arg name="callback_data" type="uint" summary="request-specific data for the callback"/>
+    </event>
+  </interface>
+  <interface name="wl_compositor" version="6">
+    <description summary="the compositor singleton">
+      A compositor.  This object is a singleton global.  The
+      compositor is in charge of combining the contents of multiple
+      surfaces into one displayable output.
+    </description>
+    <request name="create_surface">
+      <description summary="create new surface">
+        Ask the compositor to create a new surface.
+      </description>
+      <arg name="id" type="new_id" interface="wl_surface" summary="the new surface"/>
+    </request>
+    <request name="create_region">
+      <description summary="create new region">
+        Ask the compositor to create a new region.
+      </description>
+      <arg name="id" type="new_id" interface="wl_region" summary="the new region"/>
+    </request>
+  </interface>
+  <interface name="wl_shm_pool" version="1">
+    <description summary="a shared memory pool">
+      The wl_shm_pool object encapsulates a piece of memory shared
+      between the compositor and client.  Through the wl_shm_pool
+      object, the client can allocate shared memory wl_buffer objects.
+      All objects created through the same pool share the same
+      underlying mapped memory. Reusing the mapped memory avoids the
+      setup/teardown overhead and is useful when interactively resizing
+      a surface or for many small buffers.
+    </description>
+    <request name="create_buffer">
+      <description summary="create a buffer from the pool">
+        Create a wl_buffer object from the pool.
+        The buffer is created offset bytes into the pool and has
+        width and height as specified.  The stride argument specifies
+        the number of bytes from the beginning of one row to the beginning
+        of the next.  The format is the pixel format of the buffer and
+        must be one of those advertised through the wl_shm.format event.
+        A buffer will keep a reference to the pool it was created from
+        so it is valid to destroy the pool immediately after creating
+        a buffer from it.
+      </description>
+      <arg name="id" type="new_id" interface="wl_buffer" summary="buffer to create"/>
+      <arg name="offset" type="int" summary="buffer byte offset within the pool"/>
+      <arg name="width" type="int" summary="buffer width, in pixels"/>
+      <arg name="height" type="int" summary="buffer height, in pixels"/>
+      <arg name="stride" type="int" summary="number of bytes from the beginning of one row to the beginning of the next row"/>
+      <arg name="format" type="uint" enum="wl_shm.format" summary="buffer pixel format"/>
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the pool">
+        Destroy the shared memory pool.
+        The mmapped memory will be released when all
+        buffers that have been created from this pool
+        are gone.
+      </description>
+    </request>
+    <request name="resize">
+      <description summary="change the size of the pool mapping">
+        This request will cause the server to remap the backing memory
+        for the pool from the file descriptor passed when the pool was
+        created, but using the new size.  This request can only be
+        used to make the pool bigger.
+        This request only changes the amount of bytes that are mmapped
+        by the server and does not touch the file corresponding to the
+        file descriptor passed at creation time. It is the client's
+        responsibility to ensure that the file is at least as big as
+        the new pool size.
+      </description>
+      <arg name="size" type="int" summary="new size of the pool, in bytes"/>
+    </request>
+  </interface>
+  <interface name="wl_shm" version="1">
+    <description summary="shared memory support">
+      A singleton global object that provides support for shared
+      memory.
+      Clients can create wl_shm_pool objects using the create_pool
+      request.
+      On binding the wl_shm object one or more format events
+      are emitted to inform clients about the valid pixel formats
+      that can be used for buffers.
+    </description>
+    <enum name="error">
+      <description summary="wl_shm error values">
+        These errors can be emitted in response to wl_shm requests.
+      </description>
+      <entry name="invalid_format" value="0" summary="buffer format is not known"/>
+      <entry name="invalid_stride" value="1" summary="invalid size or stride during pool or buffer creation"/>
+      <entry name="invalid_fd" value="2" summary="mmapping the file descriptor failed"/>
+    </enum>
+    <enum name="format">
+      <description summary="pixel formats">
+        This describes the memory layout of an individual pixel.
+        All renderers should support argb8888 and xrgb8888 but any other
+        formats are optional and may not be supported by the particular
+        renderer in use.
+        The drm format codes match the macros defined in drm_fourcc.h, except
+        argb8888 and xrgb8888. The formats actually supported by the compositor
+        will be reported by the format event.
+        For all wl_shm formats and unless specified in another protocol
+        extension, pre-multiplied alpha is used for pixel values.
+      </description>
+      <!-- Note to protocol writers: don't update this list manually, instead
+           run the automated script that keeps it in sync with drm_fourcc.h. -->
+      <entry name="argb8888" value="0" summary="32-bit ARGB format, [31:0] A:R:G:B 8:8:8:8 little endian"/>
+      <entry name="xrgb8888" value="1" summary="32-bit RGB format, [31:0] x:R:G:B 8:8:8:8 little endian"/>
+      <entry name="c8" value="0x20203843" summary="8-bit color index format, [7:0] C"/>
+      <entry name="rgb332" value="0x38424752" summary="8-bit RGB format, [7:0] R:G:B 3:3:2"/>
+      <entry name="bgr233" value="0x38524742" summary="8-bit BGR format, [7:0] B:G:R 2:3:3"/>
+      <entry name="xrgb4444" value="0x32315258" summary="16-bit xRGB format, [15:0] x:R:G:B 4:4:4:4 little endian"/>
+      <entry name="xbgr4444" value="0x32314258" summary="16-bit xBGR format, [15:0] x:B:G:R 4:4:4:4 little endian"/>
+      <entry name="rgbx4444" value="0x32315852" summary="16-bit RGBx format, [15:0] R:G:B:x 4:4:4:4 little endian"/>
+      <entry name="bgrx4444" value="0x32315842" summary="16-bit BGRx format, [15:0] B:G:R:x 4:4:4:4 little endian"/>
+      <entry name="argb4444" value="0x32315241" summary="16-bit ARGB format, [15:0] A:R:G:B 4:4:4:4 little endian"/>
+      <entry name="abgr4444" value="0x32314241" summary="16-bit ABGR format, [15:0] A:B:G:R 4:4:4:4 little endian"/>
+      <entry name="rgba4444" value="0x32314152" summary="16-bit RBGA format, [15:0] R:G:B:A 4:4:4:4 little endian"/>
+      <entry name="bgra4444" value="0x32314142" summary="16-bit BGRA format, [15:0] B:G:R:A 4:4:4:4 little endian"/>
+      <entry name="xrgb1555" value="0x35315258" summary="16-bit xRGB format, [15:0] x:R:G:B 1:5:5:5 little endian"/>
+      <entry name="xbgr1555" value="0x35314258" summary="16-bit xBGR 1555 format, [15:0] x:B:G:R 1:5:5:5 little endian"/>
+      <entry name="rgbx5551" value="0x35315852" summary="16-bit RGBx 5551 format, [15:0] R:G:B:x 5:5:5:1 little endian"/>
+      <entry name="bgrx5551" value="0x35315842" summary="16-bit BGRx 5551 format, [15:0] B:G:R:x 5:5:5:1 little endian"/>
+      <entry name="argb1555" value="0x35315241" summary="16-bit ARGB 1555 format, [15:0] A:R:G:B 1:5:5:5 little endian"/>
+      <entry name="abgr1555" value="0x35314241" summary="16-bit ABGR 1555 format, [15:0] A:B:G:R 1:5:5:5 little endian"/>
+      <entry name="rgba5551" value="0x35314152" summary="16-bit RGBA 5551 format, [15:0] R:G:B:A 5:5:5:1 little endian"/>
+      <entry name="bgra5551" value="0x35314142" summary="16-bit BGRA 5551 format, [15:0] B:G:R:A 5:5:5:1 little endian"/>
+      <entry name="rgb565" value="0x36314752" summary="16-bit RGB 565 format, [15:0] R:G:B 5:6:5 little endian"/>
+      <entry name="bgr565" value="0x36314742" summary="16-bit BGR 565 format, [15:0] B:G:R 5:6:5 little endian"/>
+      <entry name="rgb888" value="0x34324752" summary="24-bit RGB format, [23:0] R:G:B little endian"/>
+      <entry name="bgr888" value="0x34324742" summary="24-bit BGR format, [23:0] B:G:R little endian"/>
+      <entry name="xbgr8888" value="0x34324258" summary="32-bit xBGR format, [31:0] x:B:G:R 8:8:8:8 little endian"/>
+      <entry name="rgbx8888" value="0x34325852" summary="32-bit RGBx format, [31:0] R:G:B:x 8:8:8:8 little endian"/>
+      <entry name="bgrx8888" value="0x34325842" summary="32-bit BGRx format, [31:0] B:G:R:x 8:8:8:8 little endian"/>
+      <entry name="abgr8888" value="0x34324241" summary="32-bit ABGR format, [31:0] A:B:G:R 8:8:8:8 little endian"/>
+      <entry name="rgba8888" value="0x34324152" summary="32-bit RGBA format, [31:0] R:G:B:A 8:8:8:8 little endian"/>
+      <entry name="bgra8888" value="0x34324142" summary="32-bit BGRA format, [31:0] B:G:R:A 8:8:8:8 little endian"/>
+      <entry name="xrgb2101010" value="0x30335258" summary="32-bit xRGB format, [31:0] x:R:G:B 2:10:10:10 little endian"/>
+      <entry name="xbgr2101010" value="0x30334258" summary="32-bit xBGR format, [31:0] x:B:G:R 2:10:10:10 little endian"/>
+      <entry name="rgbx1010102" value="0x30335852" summary="32-bit RGBx format, [31:0] R:G:B:x 10:10:10:2 little endian"/>
+      <entry name="bgrx1010102" value="0x30335842" summary="32-bit BGRx format, [31:0] B:G:R:x 10:10:10:2 little endian"/>
+      <entry name="argb2101010" value="0x30335241" summary="32-bit ARGB format, [31:0] A:R:G:B 2:10:10:10 little endian"/>
+      <entry name="abgr2101010" value="0x30334241" summary="32-bit ABGR format, [31:0] A:B:G:R 2:10:10:10 little endian"/>
+      <entry name="rgba1010102" value="0x30334152" summary="32-bit RGBA format, [31:0] R:G:B:A 10:10:10:2 little endian"/>
+      <entry name="bgra1010102" value="0x30334142" summary="32-bit BGRA format, [31:0] B:G:R:A 10:10:10:2 little endian"/>
+      <entry name="yuyv" value="0x56595559" summary="packed YCbCr format, [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian"/>
+      <entry name="yvyu" value="0x55595659" summary="packed YCbCr format, [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian"/>
+      <entry name="uyvy" value="0x59565955" summary="packed YCbCr format, [31:0] Y1:Cr0:Y0:Cb0 8:8:8:8 little endian"/>
+      <entry name="vyuy" value="0x59555956" summary="packed YCbCr format, [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian"/>
+      <entry name="ayuv" value="0x56555941" summary="packed AYCbCr format, [31:0] A:Y:Cb:Cr 8:8:8:8 little endian"/>
+      <entry name="nv12" value="0x3231564e" summary="2 plane YCbCr Cr:Cb format, 2x2 subsampled Cr:Cb plane"/>
+      <entry name="nv21" value="0x3132564e" summary="2 plane YCbCr Cb:Cr format, 2x2 subsampled Cb:Cr plane"/>
+      <entry name="nv16" value="0x3631564e" summary="2 plane YCbCr Cr:Cb format, 2x1 subsampled Cr:Cb plane"/>
+      <entry name="nv61" value="0x3136564e" summary="2 plane YCbCr Cb:Cr format, 2x1 subsampled Cb:Cr plane"/>
+      <entry name="yuv410" value="0x39565559" summary="3 plane YCbCr format, 4x4 subsampled Cb (1) and Cr (2) planes"/>
+      <entry name="yvu410" value="0x39555659" summary="3 plane YCbCr format, 4x4 subsampled Cr (1) and Cb (2) planes"/>
+      <entry name="yuv411" value="0x31315559" summary="3 plane YCbCr format, 4x1 subsampled Cb (1) and Cr (2) planes"/>
+      <entry name="yvu411" value="0x31315659" summary="3 plane YCbCr format, 4x1 subsampled Cr (1) and Cb (2) planes"/>
+      <entry name="yuv420" value="0x32315559" summary="3 plane YCbCr format, 2x2 subsampled Cb (1) and Cr (2) planes"/>
+      <entry name="yvu420" value="0x32315659" summary="3 plane YCbCr format, 2x2 subsampled Cr (1) and Cb (2) planes"/>
+      <entry name="yuv422" value="0x36315559" summary="3 plane YCbCr format, 2x1 subsampled Cb (1) and Cr (2) planes"/>
+      <entry name="yvu422" value="0x36315659" summary="3 plane YCbCr format, 2x1 subsampled Cr (1) and Cb (2) planes"/>
+      <entry name="yuv444" value="0x34325559" summary="3 plane YCbCr format, non-subsampled Cb (1) and Cr (2) planes"/>
+      <entry name="yvu444" value="0x34325659" summary="3 plane YCbCr format, non-subsampled Cr (1) and Cb (2) planes"/>
+      <entry name="r8" value="0x20203852" summary="[7:0] R"/>
+      <entry name="r16" value="0x20363152" summary="[15:0] R little endian"/>
+      <entry name="rg88" value="0x38384752" summary="[15:0] R:G 8:8 little endian"/>
+      <entry name="gr88" value="0x38385247" summary="[15:0] G:R 8:8 little endian"/>
+      <entry name="rg1616" value="0x32334752" summary="[31:0] R:G 16:16 little endian"/>
+      <entry name="gr1616" value="0x32335247" summary="[31:0] G:R 16:16 little endian"/>
+      <entry name="xrgb16161616f" value="0x48345258" summary="[63:0] x:R:G:B 16:16:16:16 little endian"/>
+      <entry name="xbgr16161616f" value="0x48344258" summary="[63:0] x:B:G:R 16:16:16:16 little endian"/>
+      <entry name="argb16161616f" value="0x48345241" summary="[63:0] A:R:G:B 16:16:16:16 little endian"/>
+      <entry name="abgr16161616f" value="0x48344241" summary="[63:0] A:B:G:R 16:16:16:16 little endian"/>
+      <entry name="xyuv8888" value="0x56555958" summary="[31:0] X:Y:Cb:Cr 8:8:8:8 little endian"/>
+      <entry name="vuy888" value="0x34325556" summary="[23:0] Cr:Cb:Y 8:8:8 little endian"/>
+      <entry name="vuy101010" value="0x30335556" summary="Y followed by U then V, 10:10:10. Non-linear modifier only"/>
+      <entry name="y210" value="0x30313259" summary="[63:0] Cr0:0:Y1:0:Cb0:0:Y0:0 10:6:10:6:10:6:10:6 little endian per 2 Y pixels"/>
+      <entry name="y212" value="0x32313259" summary="[63:0] Cr0:0:Y1:0:Cb0:0:Y0:0 12:4:12:4:12:4:12:4 little endian per 2 Y pixels"/>
+      <entry name="y216" value="0x36313259" summary="[63:0] Cr0:Y1:Cb0:Y0 16:16:16:16 little endian per 2 Y pixels"/>
+      <entry name="y410" value="0x30313459" summary="[31:0] A:Cr:Y:Cb 2:10:10:10 little endian"/>
+      <entry name="y412" value="0x32313459" summary="[63:0] A:0:Cr:0:Y:0:Cb:0 12:4:12:4:12:4:12:4 little endian"/>
+      <entry name="y416" value="0x36313459" summary="[63:0] A:Cr:Y:Cb 16:16:16:16 little endian"/>
+      <entry name="xvyu2101010" value="0x30335658" summary="[31:0] X:Cr:Y:Cb 2:10:10:10 little endian"/>
+      <entry name="xvyu12_16161616" value="0x36335658" summary="[63:0] X:0:Cr:0:Y:0:Cb:0 12:4:12:4:12:4:12:4 little endian"/>
+      <entry name="xvyu16161616" value="0x38345658" summary="[63:0] X:Cr:Y:Cb 16:16:16:16 little endian"/>
+      <entry name="y0l0" value="0x304c3059" summary="[63:0]   A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0  1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian"/>
+      <entry name="x0l0" value="0x304c3058" summary="[63:0]   X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0  1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian"/>
+      <entry name="y0l2" value="0x324c3059" summary="[63:0]   A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0  1:1:10:10:10:1:1:10:10:10 little endian"/>
+      <entry name="x0l2" value="0x324c3058" summary="[63:0]   X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0  1:1:10:10:10:1:1:10:10:10 little endian"/>
+      <entry name="yuv420_8bit" value="0x38305559"/>
+      <entry name="yuv420_10bit" value="0x30315559"/>
+      <entry name="xrgb8888_a8" value="0x38415258"/>
+      <entry name="xbgr8888_a8" value="0x38414258"/>
+      <entry name="rgbx8888_a8" value="0x38415852"/>
+      <entry name="bgrx8888_a8" value="0x38415842"/>
+      <entry name="rgb888_a8" value="0x38413852"/>
+      <entry name="bgr888_a8" value="0x38413842"/>
+      <entry name="rgb565_a8" value="0x38413552"/>
+      <entry name="bgr565_a8" value="0x38413542"/>
+      <entry name="nv24" value="0x3432564e" summary="non-subsampled Cr:Cb plane"/>
+      <entry name="nv42" value="0x3234564e" summary="non-subsampled Cb:Cr plane"/>
+      <entry name="p210" value="0x30313250" summary="2x1 subsampled Cr:Cb plane, 10 bit per channel"/>
+      <entry name="p010" value="0x30313050" summary="2x2 subsampled Cr:Cb plane 10 bits per channel"/>
+      <entry name="p012" value="0x32313050" summary="2x2 subsampled Cr:Cb plane 12 bits per channel"/>
+      <entry name="p016" value="0x36313050" summary="2x2 subsampled Cr:Cb plane 16 bits per channel"/>
+      <entry name="axbxgxrx106106106106" value="0x30314241" summary="[63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian"/>
+      <entry name="nv15" value="0x3531564e" summary="2x2 subsampled Cr:Cb plane"/>
+      <entry name="q410" value="0x30313451"/>
+      <entry name="q401" value="0x31303451"/>
+      <entry name="xrgb16161616" value="0x38345258" summary="[63:0] x:R:G:B 16:16:16:16 little endian"/>
+      <entry name="xbgr16161616" value="0x38344258" summary="[63:0] x:B:G:R 16:16:16:16 little endian"/>
+      <entry name="argb16161616" value="0x38345241" summary="[63:0] A:R:G:B 16:16:16:16 little endian"/>
+      <entry name="abgr16161616" value="0x38344241" summary="[63:0] A:B:G:R 16:16:16:16 little endian"/>
+    </enum>
+    <request name="create_pool">
+      <description summary="create a shm pool">
+        Create a new wl_shm_pool object.
+        The pool can be used to create shared memory based buffer
+        objects.  The server will mmap size bytes of the passed file
+        descriptor, to use as backing memory for the pool.
+      </description>
+      <arg name="id" type="new_id" interface="wl_shm_pool" summary="pool to create"/>
+      <arg name="fd" type="fd" summary="file descriptor for the pool"/>
+      <arg name="size" type="int" summary="pool size, in bytes"/>
+    </request>
+    <event name="format">
+      <description summary="pixel format description">
+        Informs the client about a valid pixel format that
+        can be used for buffers. Known formats include
+        argb8888 and xrgb8888.
+      </description>
+      <arg name="format" type="uint" enum="format" summary="buffer pixel format"/>
+    </event>
+  </interface>
+  <interface name="wl_buffer" version="1">
+    <description summary="content for a wl_surface">
+      A buffer provides the content for a wl_surface. Buffers are
+      created through factory interfaces such as wl_shm, wp_linux_buffer_params
+      (from the linux-dmabuf protocol extension) or similar. It has a width and
+      a height and can be attached to a wl_surface, but the mechanism by which a
+      client provides and updates the contents is defined by the buffer factory
+      interface.
+      If the buffer uses a format that has an alpha channel, the alpha channel
+      is assumed to be premultiplied in the color channels unless otherwise
+      specified.
+      Note, because wl_buffer objects are created from multiple independent
+      factory interfaces, the wl_buffer interface is frozen at version 1.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy a buffer">
+        Destroy a buffer. If and how you need to release the backing
+        storage is defined by the buffer factory interface.
+        For possible side-effects to a surface, see wl_surface.attach.
+      </description>
+    </request>
+    <event name="release">
+      <description summary="compositor releases buffer">
+        Sent when this wl_buffer is no longer used by the compositor.
+        The client is now free to reuse or destroy this buffer and its
+        backing storage.
+        If a client receives a release event before the frame callback
+        requested in the same wl_surface.commit that attaches this
+        wl_buffer to a surface, then the client is immediately free to
+        reuse the buffer and its backing storage, and does not need a
+        second buffer for the next surface content update. Typically
+        this is possible, when the compositor maintains a copy of the
+        wl_surface contents, e.g. as a GL texture. This is an important
+        optimization for GL(ES) compositors with wl_shm clients.
+      </description>
+    </event>
+  </interface>
+  <interface name="wl_data_offer" version="3">
+    <description summary="offer to transfer data">
+      A wl_data_offer represents a piece of data offered for transfer
+      by another client (the source client).  It is used by the
+      copy-and-paste and drag-and-drop mechanisms.  The offer
+      describes the different mime types that the data can be
+      converted to and provides the mechanism for transferring the
+      data directly from the source client.
+    </description>
+    <enum name="error">
+      <entry name="invalid_finish" value="0"
+             summary="finish request was called untimely"/>
+      <entry name="invalid_action_mask" value="1"
+             summary="action mask contains invalid values"/>
+      <entry name="invalid_action" value="2"
+             summary="action argument has an invalid value"/>
+      <entry name="invalid_offer" value="3"
+             summary="offer doesn't accept this request"/>
+    </enum>
+    <request name="accept">
+      <description summary="accept one of the offered mime types">
+        Indicate that the client can accept the given mime type, or
+        NULL for not accepted.
+        For objects of version 2 or older, this request is used by the
+        client to give feedback whether the client can receive the given
+        mime type, or NULL if none is accepted; the feedback does not
+        determine whether the drag-and-drop operation succeeds or not.
+        For objects of version 3 or newer, this request determines the
+        final result of the drag-and-drop operation. If the end result
+        is that no mime types were accepted, the drag-and-drop operation
+        will be cancelled and the corresponding drag source will receive
+        wl_data_source.cancelled. Clients may still use this event in
+        conjunction with wl_data_source.action for feedback.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the accept request"/>
+      <arg name="mime_type" type="string" allow-null="true" summary="mime type accepted by the client"/>
+    </request>
+    <request name="receive">
+      <description summary="request that the data is transferred">
+        To transfer the offered data, the client issues this request
+        and indicates the mime type it wants to receive.  The transfer
+        happens through the passed file descriptor (typically created
+        with the pipe system call).  The source client writes the data
+        in the mime type representation requested and then closes the
+        file descriptor.
+        The receiving client reads from the read end of the pipe until
+        EOF and then closes its end, at which point the transfer is
+        complete.
+        This request may happen multiple times for different mime types,
+        both before and after wl_data_device.drop. Drag-and-drop destination
+        clients may preemptively fetch data or examine it more closely to
+        determine acceptance.
+      </description>
+      <arg name="mime_type" type="string" summary="mime type desired by receiver"/>
+      <arg name="fd" type="fd" summary="file descriptor for data transfer"/>
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="destroy data offer">
+        Destroy the data offer.
+      </description>
+    </request>
+    <event name="offer">
+      <description summary="advertise offered mime type">
+        Sent immediately after creating the wl_data_offer object.  One
+        event per offered mime type.
+      </description>
+      <arg name="mime_type" type="string" summary="offered mime type"/>
+    </event>
+    <!-- Version 3 additions -->
+    <request name="finish" since="3">
+      <description summary="the offer will no longer be used">
+        Notifies the compositor that the drag destination successfully
+        finished the drag-and-drop operation.
+        Upon receiving this request, the compositor will emit
+        wl_data_source.dnd_finished on the drag source client.
+        It is a client error to perform other requests than
+        wl_data_offer.destroy after this one. It is also an error to perform
+        this request after a NULL mime type has been set in
+        wl_data_offer.accept or no action was received through
+        wl_data_offer.action.
+        If wl_data_offer.finish request is received for a non drag and drop
+        operation, the invalid_finish protocol error is raised.
+      </description>
+    </request>
+    <request name="set_actions" since="3">
+      <description summary="set the available/preferred drag-and-drop actions">
+        Sets the actions that the destination side client supports for
+        this operation. This request may trigger the emission of
+        wl_data_source.action and wl_data_offer.action events if the compositor
+        needs to change the selected action.
+        This request can be called multiple times throughout the
+        drag-and-drop operation, typically in response to wl_data_device.enter
+        or wl_data_device.motion events.
+        This request determines the final result of the drag-and-drop
+        operation. If the end result is that no action is accepted,
+        the drag source will receive wl_data_source.cancelled.
+        The dnd_actions argument must contain only values expressed in the
+        wl_data_device_manager.dnd_actions enum, and the preferred_action
+        argument must only contain one of those values set, otherwise it
+        will result in a protocol error.
+        While managing an "ask" action, the destination drag-and-drop client
+        may perform further wl_data_offer.receive requests, and is expected
+        to perform one last wl_data_offer.set_actions request with a preferred
+        action other than "ask" (and optionally wl_data_offer.accept) before
+        requesting wl_data_offer.finish, in order to convey the action selected
+        by the user. If the preferred action is not in the
+        wl_data_offer.source_actions mask, an error will be raised.
+        If the "ask" action is dismissed (e.g. user cancellation), the client
+        is expected to perform wl_data_offer.destroy right away.
+        This request can only be made on drag-and-drop offers, a protocol error
+        will be raised otherwise.
+      </description>
+      <arg name="dnd_actions" type="uint" summary="actions supported by the destination client"
+           enum="wl_data_device_manager.dnd_action"/>
+      <arg name="preferred_action" type="uint" summary="action preferred by the destination client"
+           enum="wl_data_device_manager.dnd_action"/>
+    </request>
+    <event name="source_actions" since="3">
+      <description summary="notify the source-side available actions">
+        This event indicates the actions offered by the data source. It
+        will be sent immediately after creating the wl_data_offer object,
+        or anytime the source side changes its offered actions through
+        wl_data_source.set_actions.
+      </description>
+      <arg name="source_actions" type="uint" summary="actions offered by the data source"
+           enum="wl_data_device_manager.dnd_action"/>
+    </event>
+    <event name="action" since="3">
+      <description summary="notify the selected action">
+        This event indicates the action selected by the compositor after
+        matching the source/destination side actions. Only one action (or
+        none) will be offered here.
+        This event can be emitted multiple times during the drag-and-drop
+        operation in response to destination side action changes through
+        wl_data_offer.set_actions.
+        This event will no longer be emitted after wl_data_device.drop
+        happened on the drag-and-drop destination, the client must
+        honor the last action received, or the last preferred one set
+        through wl_data_offer.set_actions when handling an "ask" action.
+        Compositors may also change the selected action on the fly, mainly
+        in response to keyboard modifier changes during the drag-and-drop
+        operation.
+        The most recent action received is always the valid one. Prior to
+        receiving wl_data_device.drop, the chosen action may change (e.g.
+        due to keyboard modifiers being pressed). At the time of receiving
+        wl_data_device.drop the drag-and-drop destination must honor the
+        last action received.
+        Action changes may still happen after wl_data_device.drop,
+        especially on "ask" actions, where the drag-and-drop destination
+        may choose another action afterwards. Action changes happening
+        at this stage are always the result of inter-client negotiation, the
+        compositor shall no longer be able to induce a different action.
+        Upon "ask" actions, it is expected that the drag-and-drop destination
+        may potentially choose a different action and/or mime type,
+        based on wl_data_offer.source_actions and finally chosen by the
+        user (e.g. popping up a menu with the available options). The
+        final wl_data_offer.set_actions and wl_data_offer.accept requests
+        must happen before the call to wl_data_offer.finish.
+      </description>
+      <arg name="dnd_action" type="uint" summary="action selected by the compositor"
+           enum="wl_data_device_manager.dnd_action"/>
+    </event>
+  </interface>
+  <interface name="wl_data_source" version="3">
+    <description summary="offer to transfer data">
+      The wl_data_source object is the source side of a wl_data_offer.
+      It is created by the source client in a data transfer and
+      provides a way to describe the offered data and a way to respond
+      to requests to transfer the data.
+    </description>
+    <enum name="error">
+      <entry name="invalid_action_mask" value="0"
+             summary="action mask contains invalid values"/>
+      <entry name="invalid_source" value="1"
+             summary="source doesn't accept this request"/>
+    </enum>
+    <request name="offer">
+      <description summary="add an offered mime type">
+        This request adds a mime type to the set of mime types
+        advertised to targets.  Can be called several times to offer
+        multiple types.
+      </description>
+      <arg name="mime_type" type="string" summary="mime type offered by the data source"/>
+    </request>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the data source">
+        Destroy the data source.
+      </description>
+    </request>
+    <event name="target">
+      <description summary="a target accepts an offered mime type">
+        Sent when a target accepts pointer_focus or motion events.  If
+        a target does not accept any of the offered types, type is NULL.
+        Used for feedback during drag-and-drop.
+      </description>
+      <arg name="mime_type" type="string" allow-null="true" summary="mime type accepted by the target"/>
+    </event>
+    <event name="send">
+      <description summary="send the data">
+        Request for data from the client.  Send the data as the
+        specified mime type over the passed file descriptor, then
+        close it.
+      </description>
+      <arg name="mime_type" type="string" summary="mime type for the data"/>
+      <arg name="fd" type="fd" summary="file descriptor for the data"/>
+    </event>
+    <event name="cancelled">
+      <description summary="selection was cancelled">
+        This data source is no longer valid. There are several reasons why
+        this could happen:
+        - The data source has been replaced by another data source.
+        - The drag-and-drop operation was performed, but the drop destination
+          did not accept any of the mime types offered through
+          wl_data_source.target.
+        - The drag-and-drop operation was performed, but the drop destination
+          did not select any of the actions present in the mask offered through
+          wl_data_source.action.
+        - The drag-and-drop operation was performed but didn't happen over a
+          surface.
+        - The compositor cancelled the drag-and-drop operation (e.g. compositor
+          dependent timeouts to avoid stale drag-and-drop transfers).
+        The client should clean up and destroy this data source.
+        For objects of version 2 or older, wl_data_source.cancelled will
+        only be emitted if the data source was replaced by another data
+        source.
+      </description>
+    </event>
+    <!-- Version 3 additions -->
+    <request name="set_actions" since="3">
+      <description summary="set the available drag-and-drop actions">
+        Sets the actions that the source side client supports for this
+        operation. This request may trigger wl_data_source.action and
+        wl_data_offer.action events if the compositor needs to change the
+        selected action.
+        The dnd_actions argument must contain only values expressed in the
+        wl_data_device_manager.dnd_actions enum, otherwise it will result
+        in a protocol error.
+        This request must be made once only, and can only be made on sources
+        used in drag-and-drop, so it must be performed before
+        wl_data_device.start_drag. Attempting to use the source other than
+        for drag-and-drop will raise a protocol error.
+      </description>
+      <arg name="dnd_actions" type="uint" summary="actions supported by the data source"
+           enum="wl_data_device_manager.dnd_action"/>
+    </request>
+    <event name="dnd_drop_performed" since="3">
+      <description summary="the drag-and-drop operation physically finished">
+        The user performed the drop action. This event does not indicate
+        acceptance, wl_data_source.cancelled may still be emitted afterwards
+        if the drop destination does not accept any mime type.
+        However, this event might however not be received if the compositor
+        cancelled the drag-and-drop operation before this event could happen.
+        Note that the data_source may still be used in the future and should
+        not be destroyed here.
+      </description>
+    </event>
+    <event name="dnd_finished" since="3">
+      <description summary="the drag-and-drop operation concluded">
+        The drop destination finished interoperating with this data
+        source, so the client is now free to destroy this data source and
+        free all associated data.
+        If the action used to perform the operation was "move", the
+        source can now delete the transferred data.
+      </description>
+    </event>
+    <event name="action" since="3">
+      <description summary="notify the selected action">
+        This event indicates the action selected by the compositor after
+        matching the source/destination side actions. Only one action (or
+        none) will be offered here.
+        This event can be emitted multiple times during the drag-and-drop
+        operation, mainly in response to destination side changes through
+        wl_data_offer.set_actions, and as the data device enters/leaves
+        surfaces.
+        It is only possible to receive this event after
+        wl_data_source.dnd_drop_performed if the drag-and-drop operation
+        ended in an "ask" action, in which case the final wl_data_source.action
+        event will happen immediately before wl_data_source.dnd_finished.
+        Compositors may also change the selected action on the fly, mainly
+        in response to keyboard modifier changes during the drag-and-drop
+        operation.
+        The most recent action received is always the valid one. The chosen
+        action may change alongside negotiation (e.g. an "ask" action can turn
+        into a "move" operation), so the effects of the final action must
+        always be applied in wl_data_offer.dnd_finished.
+        Clients can trigger cursor surface changes from this point, so
+        they reflect the current action.
+      </description>
+      <arg name="dnd_action" type="uint" summary="action selected by the compositor"
+           enum="wl_data_device_manager.dnd_action"/>
+    </event>
+  </interface>
+  <interface name="wl_data_device" version="3">
+    <description summary="data transfer device">
+      There is one wl_data_device per seat which can be obtained
+      from the global wl_data_device_manager singleton.
+      A wl_data_device provides access to inter-client data transfer
+      mechanisms such as copy-and-paste and drag-and-drop.
+    </description>
+    <enum name="error">
+      <entry name="role" value="0" summary="given wl_surface has another role"/>
+    </enum>
+    <request name="start_drag">
+      <description summary="start drag-and-drop operation">
+        This request asks the compositor to start a drag-and-drop
+        operation on behalf of the client.
+        The source argument is the data source that provides the data
+        for the eventual data transfer. If source is NULL, enter, leave
+        and motion events are sent only to the client that initiated the
+        drag and the client is expected to handle the data passing
+        internally. If source is destroyed, the drag-and-drop session will be
+        cancelled.
+        The origin surface is the surface where the drag originates and
+        the client must have an active implicit grab that matches the
+        serial.
+        The icon surface is an optional (can be NULL) surface that
+        provides an icon to be moved around with the cursor.  Initially,
+        the top-left corner of the icon surface is placed at the cursor
+        hotspot, but subsequent wl_surface.attach request can move the
+        relative position. Attach requests must be confirmed with
+        wl_surface.commit as usual. The icon surface is given the role of
+        a drag-and-drop icon. If the icon surface already has another role,
+        it raises a protocol error.
+        The input region is ignored for wl_surfaces with the role of a
+        drag-and-drop icon.
+      </description>
+      <arg name="source" type="object" interface="wl_data_source" allow-null="true" summary="data source for the eventual transfer"/>
+      <arg name="origin" type="object" interface="wl_surface" summary="surface where the drag originates"/>
+      <arg name="icon" type="object" interface="wl_surface" allow-null="true" summary="drag-and-drop icon surface"/>
+      <arg name="serial" type="uint" summary="serial number of the implicit grab on the origin"/>
+    </request>
+    <request name="set_selection">
+      <description summary="copy data to the selection">
+        This request asks the compositor to set the selection
+        to the data from the source on behalf of the client.
+        To unset the selection, set the source to NULL.
+      </description>
+      <arg name="source" type="object" interface="wl_data_source" allow-null="true" summary="data source for the selection"/>
+      <arg name="serial" type="uint" summary="serial number of the event that triggered this request"/>
+    </request>
+    <event name="data_offer">
+      <description summary="introduce a new wl_data_offer">
+        The data_offer event introduces a new wl_data_offer object,
+        which will subsequently be used in either the
+        data_device.enter event (for drag-and-drop) or the
+        data_device.selection event (for selections).  Immediately
+        following the data_device.data_offer event, the new data_offer
+        object will send out data_offer.offer events to describe the
+        mime types it offers.
+      </description>
+      <arg name="id" type="new_id" interface="wl_data_offer" summary="the new data_offer object"/>
+    </event>
+    <event name="enter">
+      <description summary="initiate drag-and-drop session">
+        This event is sent when an active drag-and-drop pointer enters
+        a surface owned by the client.  The position of the pointer at
+        enter time is provided by the x and y arguments, in surface-local
+        coordinates.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the enter event"/>
+      <arg name="surface" type="object" interface="wl_surface" summary="client surface entered"/>
+      <arg name="x" type="fixed" summary="surface-local x coordinate"/>
+      <arg name="y" type="fixed" summary="surface-local y coordinate"/>
+      <arg name="id" type="object" interface="wl_data_offer" allow-null="true"
+           summary="source data_offer object"/>
+    </event>
+    <event name="leave">
+      <description summary="end drag-and-drop session">
+        This event is sent when the drag-and-drop pointer leaves the
+        surface and the session ends.  The client must destroy the
+        wl_data_offer introduced at enter time at this point.
+      </description>
+    </event>
+    <event name="motion">
+      <description summary="drag-and-drop session motion">
+        This event is sent when the drag-and-drop pointer moves within
+        the currently focused surface. The new position of the pointer
+        is provided by the x and y arguments, in surface-local
+        coordinates.
+      </description>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+      <arg name="x" type="fixed" summary="surface-local x coordinate"/>
+      <arg name="y" type="fixed" summary="surface-local y coordinate"/>
+    </event>
+    <event name="drop">
+      <description summary="end drag-and-drop session successfully">
+        The event is sent when a drag-and-drop operation is ended
+        because the implicit grab is removed.
+        The drag-and-drop destination is expected to honor the last action
+        received through wl_data_offer.action, if the resulting action is
+        "copy" or "move", the destination can still perform
+        wl_data_offer.receive requests, and is expected to end all
+        transfers with a wl_data_offer.finish request.
+        If the resulting action is "ask", the action will not be considered
+        final. The drag-and-drop destination is expected to perform one last
+        wl_data_offer.set_actions request, or wl_data_offer.destroy in order
+        to cancel the operation.
+      </description>
+    </event>
+    <event name="selection">
+      <description summary="advertise new selection">
+        The selection event is sent out to notify the client of a new
+        wl_data_offer for the selection for this device.  The
+        data_device.data_offer and the data_offer.offer events are
+        sent out immediately before this event to introduce the data
+        offer object.  The selection event is sent to a client
+        immediately before receiving keyboard focus and when a new
+        selection is set while the client has keyboard focus.  The
+        data_offer is valid until a new data_offer or NULL is received
+        or until the client loses keyboard focus.  Switching surface with
+        keyboard focus within the same client doesn't mean a new selection
+        will be sent.  The client must destroy the previous selection
+        data_offer, if any, upon receiving this event.
+      </description>
+      <arg name="id" type="object" interface="wl_data_offer" allow-null="true"
+           summary="selection data_offer object"/>
+    </event>
+    <!-- Version 2 additions -->
+    <request name="release" type="destructor" since="2">
+      <description summary="destroy data device">
+        This request destroys the data device.
+      </description>
+    </request>
+  </interface>
+  <interface name="wl_data_device_manager" version="3">
+    <description summary="data transfer interface">
+      The wl_data_device_manager is a singleton global object that
+      provides access to inter-client data transfer mechanisms such as
+      copy-and-paste and drag-and-drop.  These mechanisms are tied to
+      a wl_seat and this interface lets a client get a wl_data_device
+      corresponding to a wl_seat.
+      Depending on the version bound, the objects created from the bound
+      wl_data_device_manager object will have different requirements for
+      functioning properly. See wl_data_source.set_actions,
+      wl_data_offer.accept and wl_data_offer.finish for details.
+    </description>
+    <request name="create_data_source">
+      <description summary="create a new data source">
+        Create a new data source.
+      </description>
+      <arg name="id" type="new_id" interface="wl_data_source" summary="data source to create"/>
+    </request>
+    <request name="get_data_device">
+      <description summary="create a new data device">
+        Create a new data device for a given seat.
+      </description>
+      <arg name="id" type="new_id" interface="wl_data_device" summary="data device to create"/>
+      <arg name="seat" type="object" interface="wl_seat" summary="seat associated with the data device"/>
+    </request>
+    <!-- Version 3 additions -->
+    <enum name="dnd_action" bitfield="true" since="3">
+      <description summary="drag and drop actions">
+        This is a bitmask of the available/preferred actions in a
+        drag-and-drop operation.
+        In the compositor, the selected action is a result of matching the
+        actions offered by the source and destination sides.  "action" events
+        with a "none" action will be sent to both source and destination if
+        there is no match. All further checks will effectively happen on
+        (source actions ∩ destination actions).
+        In addition, compositors may also pick different actions in
+        reaction to key modifiers being pressed. One common design that
+        is used in major toolkits (and the behavior recommended for
+        compositors) is:
+        - If no modifiers are pressed, the first match (in bit order)
+          will be used.
+        - Pressing Shift selects "move", if enabled in the mask.
+        - Pressing Control selects "copy", if enabled in the mask.
+        Behavior beyond that is considered implementation-dependent.
+        Compositors may for example bind other modifiers (like Alt/Meta)
+        or drags initiated with other buttons than BTN_LEFT to specific
+        actions (e.g. "ask").
+      </description>
+      <entry name="none" value="0" summary="no action"/>
+      <entry name="copy" value="1" summary="copy action"/>
+      <entry name="move" value="2" summary="move action"/>
+      <entry name="ask" value="4" summary="ask action"/>
+    </enum>
+  </interface>
+  <interface name="wl_shell" version="1">
+    <description summary="create desktop-style surfaces">
+      This interface is implemented by servers that provide
+      desktop-style user interfaces.
+      It allows clients to associate a wl_shell_surface with
+      a basic surface.
+      Note! This protocol is deprecated and not intended for production use.
+      For desktop-style user interfaces, use xdg_shell. Compositors and clients
+      should not implement this interface.
+    </description>
+    <enum name="error">
+      <entry name="role" value="0" summary="given wl_surface has another role"/>
+    </enum>
+    <request name="get_shell_surface">
+      <description summary="create a shell surface from a surface">
+        Create a shell surface for an existing surface. This gives
+        the wl_surface the role of a shell surface. If the wl_surface
+        already has another role, it raises a protocol error.
+        Only one shell surface can be associated with a given surface.
+      </description>
+      <arg name="id" type="new_id" interface="wl_shell_surface" summary="shell surface to create"/>
+      <arg name="surface" type="object" interface="wl_surface" summary="surface to be given the shell surface role"/>
+    </request>
+  </interface>
+  <interface name="wl_shell_surface" version="1">
+    <description summary="desktop-style metadata interface">
+      An interface that may be implemented by a wl_surface, for
+      implementations that provide a desktop-style user interface.
+      It provides requests to treat surfaces like toplevel, fullscreen
+      or popup windows, move, resize or maximize them, associate
+      metadata like title and class, etc.
+      On the server side the object is automatically destroyed when
+      the related wl_surface is destroyed. On the client side,
+      wl_shell_surface_destroy() must be called before destroying
+      the wl_surface object.
+    </description>
+    <request name="pong">
+      <description summary="respond to a ping event">
+        A client must respond to a ping event with a pong request or
+        the client may be deemed unresponsive.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the ping event"/>
+    </request>
+    <request name="move">
+      <description summary="start an interactive move">
+        Start a pointer-driven move of the surface.
+        This request must be used in response to a button press event.
+        The server may ignore move requests depending on the state of
+        the surface (e.g. fullscreen or maximized).
+      </description>
+      <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>
+      <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>
+    </request>
+    <enum name="resize" bitfield="true">
+      <description summary="edge values for resizing">
+        These values are used to indicate which edge of a surface
+        is being dragged in a resize operation. The server may
+        use this information to adapt its behavior, e.g. choose
+        an appropriate cursor image.
+      </description>
+      <entry name="none" value="0" summary="no edge"/>
+      <entry name="top" value="1" summary="top edge"/>
+      <entry name="bottom" value="2" summary="bottom edge"/>
+      <entry name="left" value="4" summary="left edge"/>
+      <entry name="top_left" value="5" summary="top and left edges"/>
+      <entry name="bottom_left" value="6" summary="bottom and left edges"/>
+      <entry name="right" value="8" summary="right edge"/>
+      <entry name="top_right" value="9" summary="top and right edges"/>
+      <entry name="bottom_right" value="10" summary="bottom and right edges"/>
+    </enum>
+    <request name="resize">
+      <description summary="start an interactive resize">
+        Start a pointer-driven resizing of the surface.
+        This request must be used in response to a button press event.
+        The server may ignore resize requests depending on the state of
+        the surface (e.g. fullscreen or maximized).
+      </description>
+      <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>
+      <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>
+      <arg name="edges" type="uint" enum="resize" summary="which edge or corner is being dragged"/>
+    </request>
+    <request name="set_toplevel">
+      <description summary="make the surface a toplevel surface">
+        Map the surface as a toplevel surface.
+        A toplevel surface is not fullscreen, maximized or transient.
+      </description>
+    </request>
+    <enum name="transient" bitfield="true">
+      <description summary="details of transient behaviour">
+        These flags specify details of the expected behaviour
+        of transient surfaces. Used in the set_transient request.
+      </description>
+      <entry name="inactive" value="0x1" summary="do not set keyboard focus"/>
+    </enum>
+    <request name="set_transient">
+      <description summary="make the surface a transient surface">
+        Map the surface relative to an existing surface.
+        The x and y arguments specify the location of the upper left
+        corner of the surface relative to the upper left corner of the
+        parent surface, in surface-local coordinates.
+        The flags argument controls details of the transient behaviour.
+      </description>
+      <arg name="parent" type="object" interface="wl_surface" summary="parent surface"/>
+      <arg name="x" type="int" summary="surface-local x coordinate"/>
+      <arg name="y" type="int" summary="surface-local y coordinate"/>
+      <arg name="flags" type="uint" enum="transient" summary="transient surface behavior"/>
+    </request>
+    <enum name="fullscreen_method">
+      <description summary="different method to set the surface fullscreen">
+        Hints to indicate to the compositor how to deal with a conflict
+        between the dimensions of the surface and the dimensions of the
+        output. The compositor is free to ignore this parameter.
+      </description>
+      <entry name="default" value="0" summary="no preference, apply default policy"/>
+      <entry name="scale" value="1" summary="scale, preserve the surface's aspect ratio and center on output"/>
+      <entry name="driver" value="2" summary="switch output mode to the smallest mode that can fit the surface, add black borders to compensate size mismatch"/>
+      <entry name="fill" value="3" summary="no upscaling, center on output and add black borders to compensate size mismatch"/>
+    </enum>
+    <request name="set_fullscreen">
+      <description summary="make the surface a fullscreen surface">
+        Map the surface as a fullscreen surface.
+        If an output parameter is given then the surface will be made
+        fullscreen on that output. If the client does not specify the
+        output then the compositor will apply its policy - usually
+        choosing the output on which the surface has the biggest surface
+        area.
+        The client may specify a method to resolve a size conflict
+        between the output size and the surface size - this is provided
+        through the method parameter.
+        The framerate parameter is used only when the method is set
+        to "driver", to indicate the preferred framerate. A value of 0
+        indicates that the client does not care about framerate.  The
+        framerate is specified in mHz, that is framerate of 60000 is 60Hz.
+        A method of "scale" or "driver" implies a scaling operation of
+        the surface, either via a direct scaling operation or a change of
+        the output mode. This will override any kind of output scaling, so
+        that mapping a surface with a buffer size equal to the mode can
+        fill the screen independent of buffer_scale.
+        A method of "fill" means we don't scale up the buffer, however
+        any output scale is applied. This means that you may run into
+        an edge case where the application maps a buffer with the same
+        size of the output mode but buffer_scale 1 (thus making a
+        surface larger than the output). In this case it is allowed to
+        downscale the results to fit the screen.
+        The compositor must reply to this request with a configure event
+        with the dimensions for the output on which the surface will
+        be made fullscreen.
+      </description>
+      <arg name="method" type="uint" enum="fullscreen_method" summary="method for resolving size conflict"/>
+      <arg name="framerate" type="uint" summary="framerate in mHz"/>
+      <arg name="output" type="object" interface="wl_output" allow-null="true"
+           summary="output on which the surface is to be fullscreen"/>
+    </request>
+    <request name="set_popup">
+      <description summary="make the surface a popup surface">
+        Map the surface as a popup.
+        A popup surface is a transient surface with an added pointer
+        grab.
+        An existing implicit grab will be changed to owner-events mode,
+        and the popup grab will continue after the implicit grab ends
+        (i.e. releasing the mouse button does not cause the popup to
+        be unmapped).
+        The popup grab continues until the window is destroyed or a
+        mouse button is pressed in any other client's window. A click
+        in any of the client's surfaces is reported as normal, however,
+        clicks in other clients' surfaces will be discarded and trigger
+        the callback.
+        The x and y arguments specify the location of the upper left
+        corner of the surface relative to the upper left corner of the
+        parent surface, in surface-local coordinates.
+      </description>
+      <arg name="seat" type="object" interface="wl_seat" summary="seat whose pointer is used"/>
+      <arg name="serial" type="uint" summary="serial number of the implicit grab on the pointer"/>
+      <arg name="parent" type="object" interface="wl_surface" summary="parent surface"/>
+      <arg name="x" type="int" summary="surface-local x coordinate"/>
+      <arg name="y" type="int" summary="surface-local y coordinate"/>
+      <arg name="flags" type="uint" enum="transient" summary="transient surface behavior"/>
+    </request>
+    <request name="set_maximized">
+      <description summary="make the surface a maximized surface">
+        Map the surface as a maximized surface.
+        If an output parameter is given then the surface will be
+        maximized on that output. If the client does not specify the
+        output then the compositor will apply its policy - usually
+        choosing the output on which the surface has the biggest surface
+        area.
+        The compositor will reply with a configure event telling
+        the expected new surface size. The operation is completed
+        on the next buffer attach to this surface.
+        A maximized surface typically fills the entire output it is
+        bound to, except for desktop elements such as panels. This is
+        the main difference between a maximized shell surface and a
+        fullscreen shell surface.
+        The details depend on the compositor implementation.
+      </description>
+      <arg name="output" type="object" interface="wl_output" allow-null="true"
+           summary="output on which the surface is to be maximized"/>
+    </request>
+    <request name="set_title">
+      <description summary="set surface title">
+        Set a short title for the surface.
+        This string may be used to identify the surface in a task bar,
+        window list, or other user interface elements provided by the
+        compositor.
+        The string must be encoded in UTF-8.
+      </description>
+      <arg name="title" type="string" summary="surface title"/>
+    </request>
+    <request name="set_class">
+      <description summary="set surface class">
+        Set a class for the surface.
+        The surface class identifies the general class of applications
+        to which the surface belongs. A common convention is to use the
+        file name (or the full path if it is a non-standard location) of
+        the application's .desktop file as the class.
+      </description>
+      <arg name="class_" type="string" summary="surface class"/>
+    </request>
+    <event name="ping">
+      <description summary="ping client">
+        Ping a client to check if it is receiving events and sending
+        requests. A client is expected to reply with a pong request.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the ping"/>
+    </event>
+    <event name="configure">
+      <description summary="suggest resize">
+        The configure event asks the client to resize its surface.
+        The size is a hint, in the sense that the client is free to
+        ignore it if it doesn't resize, pick a smaller size (to
+        satisfy aspect ratio or resize in steps of NxM pixels).
+        The edges parameter provides a hint about how the surface
+        was resized. The client may use this information to decide
+        how to adjust its content to the new size (e.g. a scrolling
+        area might adjust its content position to leave the viewable
+        content unmoved).
+        The client is free to dismiss all but the last configure
+        event it received.
+        The width and height arguments specify the size of the window
+        in surface-local coordinates.
+      </description>
+      <arg name="edges" type="uint" enum="resize" summary="how the surface was resized"/>
+      <arg name="width" type="int" summary="new width of the surface"/>
+      <arg name="height" type="int" summary="new height of the surface"/>
+    </event>
+    <event name="popup_done">
+      <description summary="popup interaction is done">
+        The popup_done event is sent out when a popup grab is broken,
+        that is, when the user clicks a surface that doesn't belong
+        to the client owning the popup surface.
+      </description>
+    </event>
+  </interface>
+  <interface name="wl_surface" version="6">
+    <description summary="an onscreen surface">
+      A surface is a rectangular area that may be displayed on zero
+      or more outputs, and shown any number of times at the compositor's
+      discretion. They can present wl_buffers, receive user input, and
+      define a local coordinate system.
+      The size of a surface (and relative positions on it) is described
+      in surface-local coordinates, which may differ from the buffer
+      coordinates of the pixel content, in case a buffer_transform
+      or a buffer_scale is used.
+      A surface without a "role" is fairly useless: a compositor does
+      not know where, when or how to present it. The role is the
+      purpose of a wl_surface. Examples of roles are a cursor for a
+      pointer (as set by wl_pointer.set_cursor), a drag icon
+      (wl_data_device.start_drag), a sub-surface
+      (wl_subcompositor.get_subsurface), and a window as defined by a
+      shell protocol (e.g. wl_shell.get_shell_surface).
+      A surface can have only one role at a time. Initially a
+      wl_surface does not have a role. Once a wl_surface is given a
+      role, it is set permanently for the whole lifetime of the
+      wl_surface object. Giving the current role again is allowed,
+      unless explicitly forbidden by the relevant interface
+      specification.
+      Surface roles are given by requests in other interfaces such as
+      wl_pointer.set_cursor. The request should explicitly mention
+      that this request gives a role to a wl_surface. Often, this
+      request also creates a new protocol object that represents the
+      role and adds additional functionality to wl_surface. When a
+      client wants to destroy a wl_surface, they must destroy this role
+      object before the wl_surface, otherwise a defunct_role_object error is
+      sent.
+      Destroying the role object does not remove the role from the
+      wl_surface, but it may stop the wl_surface from "playing the role".
+      For instance, if a wl_subsurface object is destroyed, the wl_surface
+      it was created for will be unmapped and forget its position and
+      z-order. It is allowed to create a wl_subsurface for the same
+      wl_surface again, but it is not allowed to use the wl_surface as
+      a cursor (cursor is a different role than sub-surface, and role
+      switching is not allowed).
+    </description>
+    <enum name="error">
+      <description summary="wl_surface error values">
+        These errors can be emitted in response to wl_surface requests.
+      </description>
+      <entry name="invalid_scale" value="0" summary="buffer scale value is invalid"/>
+      <entry name="invalid_transform" value="1" summary="buffer transform value is invalid"/>
+      <entry name="invalid_size" value="2" summary="buffer size is invalid"/>
+      <entry name="invalid_offset" value="3" summary="buffer offset is invalid"/>
+      <entry name="defunct_role_object" value="4"
+             summary="surface was destroyed before its role object"/>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="delete surface">
+        Deletes the surface and invalidates its object ID.
+      </description>
+    </request>
+    <request name="attach">
+      <description summary="set the surface contents">
+        Set a buffer as the content of this surface.
+        The new size of the surface is calculated based on the buffer
+        size transformed by the inverse buffer_transform and the
+        inverse buffer_scale. This means that at commit time the supplied
+        buffer size must be an integer multiple of the buffer_scale. If
+        that's not the case, an invalid_size error is sent.
+        The x and y arguments specify the location of the new pending
+        buffer's upper left corner, relative to the current buffer's upper
+        left corner, in surface-local coordinates. In other words, the
+        x and y, combined with the new surface size define in which
+        directions the surface's size changes. Setting anything other than 0
+        as x and y arguments is discouraged, and should instead be replaced
+        with using the separate wl_surface.offset request.
+        When the bound wl_surface version is 5 or higher, passing any
+        non-zero x or y is a protocol violation, and will result in an
+        'invalid_offset' error being raised. The x and y arguments are ignored
+        and do not change the pending state. To achieve equivalent semantics,
+        use wl_surface.offset.
+        Surface contents are double-buffered state, see wl_surface.commit.
+        The initial surface contents are void; there is no content.
+        wl_surface.attach assigns the given wl_buffer as the pending
+        wl_buffer. wl_surface.commit makes the pending wl_buffer the new
+        surface contents, and the size of the surface becomes the size
+        calculated from the wl_buffer, as described above. After commit,
+        there is no pending buffer until the next attach.
+        Committing a pending wl_buffer allows the compositor to read the
+        pixels in the wl_buffer. The compositor may access the pixels at
+        any time after the wl_surface.commit request. When the compositor
+        will not access the pixels anymore, it will send the
+        wl_buffer.release event. Only after receiving wl_buffer.release,
+        the client may reuse the wl_buffer. A wl_buffer that has been
+        attached and then replaced by another attach instead of committed
+        will not receive a release event, and is not used by the
+        compositor.
+        If a pending wl_buffer has been committed to more than one wl_surface,
+        the delivery of wl_buffer.release events becomes undefined. A well
+        behaved client should not rely on wl_buffer.release events in this
+        case. Alternatively, a client could create multiple wl_buffer objects
+        from the same backing storage or use wp_linux_buffer_release.
+        Destroying the wl_buffer after wl_buffer.release does not change
+        the surface contents. Destroying the wl_buffer before wl_buffer.release
+        is allowed as long as the underlying buffer storage isn't re-used (this
+        can happen e.g. on client process termination). However, if the client
+        destroys the wl_buffer before receiving the wl_buffer.release event and
+        mutates the underlying buffer storage, the surface contents become
+        undefined immediately.
+        If wl_surface.attach is sent with a NULL wl_buffer, the
+        following wl_surface.commit will remove the surface content.
+      </description>
+      <arg name="buffer" type="object" interface="wl_buffer" allow-null="true"
+           summary="buffer of surface contents"/>
+      <arg name="x" type="int" summary="surface-local x coordinate"/>
+      <arg name="y" type="int" summary="surface-local y coordinate"/>
+    </request>
+    <request name="damage">
+      <description summary="mark part of the surface damaged">
+        This request is used to describe the regions where the pending
+        buffer is different from the current surface contents, and where
+        the surface therefore needs to be repainted. The compositor
+        ignores the parts of the damage that fall outside of the surface.
+        Damage is double-buffered state, see wl_surface.commit.
+        The damage rectangle is specified in surface-local coordinates,
+        where x and y specify the upper left corner of the damage rectangle.
+        The initial value for pending damage is empty: no damage.
+        wl_surface.damage adds pending damage: the new pending damage
+        is the union of old pending damage and the given rectangle.
+        wl_surface.commit assigns pending damage as the current damage,
+        and clears pending damage. The server will clear the current
+        damage as it repaints the surface.
+        Note! New clients should not use this request. Instead damage can be
+        posted with wl_surface.damage_buffer which uses buffer coordinates
+        instead of surface coordinates.
+      </description>
+      <arg name="x" type="int" summary="surface-local x coordinate"/>
+      <arg name="y" type="int" summary="surface-local y coordinate"/>
+      <arg name="width" type="int" summary="width of damage rectangle"/>
+      <arg name="height" type="int" summary="height of damage rectangle"/>
+    </request>
+    <request name="frame">
+      <description summary="request a frame throttling hint">
+        Request a notification when it is a good time to start drawing a new
+        frame, by creating a frame callback. This is useful for throttling
+        redrawing operations, and driving animations.
+        When a client is animating on a wl_surface, it can use the 'frame'
+        request to get notified when it is a good time to draw and commit the
+        next frame of animation. If the client commits an update earlier than
+        that, it is likely that some updates will not make it to the display,
+        and the client is wasting resources by drawing too often.
+        The frame request will take effect on the next wl_surface.commit.
+        The notification will only be posted for one frame unless
+        requested again. For a wl_surface, the notifications are posted in
+        the order the frame requests were committed.
+        The server must send the notifications so that a client
+        will not send excessive updates, while still allowing
+        the highest possible update rate for clients that wait for the reply
+        before drawing again. The server should give some time for the client
+        to draw and commit after sending the frame callback events to let it
+        hit the next output refresh.
+        A server should avoid signaling the frame callbacks if the
+        surface is not visible in any way, e.g. the surface is off-screen,
+        or completely obscured by other opaque surfaces.
+        The object returned by this request will be destroyed by the
+        compositor after the callback is fired and as such the client must not
+        attempt to use it after that point.
+        The callback_data passed in the callback is the current time, in
+        milliseconds, with an undefined base.
+      </description>
+      <arg name="callback" type="new_id" interface="wl_callback" summary="callback object for the frame request"/>
+    </request>
+    <request name="set_opaque_region">
+      <description summary="set opaque region">
+        This request sets the region of the surface that contains
+        opaque content.
+        The opaque region is an optimization hint for the compositor
+        that lets it optimize the redrawing of content behind opaque
+        regions.  Setting an opaque region is not required for correct
+        behaviour, but marking transparent content as opaque will result
+        in repaint artifacts.
+        The opaque region is specified in surface-local coordinates.
+        The compositor ignores the parts of the opaque region that fall
+        outside of the surface.
+        Opaque region is double-buffered state, see wl_surface.commit.
+        wl_surface.set_opaque_region changes the pending opaque region.
+        wl_surface.commit copies the pending region to the current region.
+        Otherwise, the pending and current regions are never changed.
+        The initial value for an opaque region is empty. Setting the pending
+        opaque region has copy semantics, and the wl_region object can be
+        destroyed immediately. A NULL wl_region causes the pending opaque
+        region to be set to empty.
+      </description>
+      <arg name="region" type="object" interface="wl_region" allow-null="true"
+           summary="opaque region of the surface"/>
+    </request>
+    <request name="set_input_region">
+      <description summary="set input region">
+        This request sets the region of the surface that can receive
+        pointer and touch events.
+        Input events happening outside of this region will try the next
+        surface in the server surface stack. The compositor ignores the
+        parts of the input region that fall outside of the surface.
+        The input region is specified in surface-local coordinates.
+        Input region is double-buffered state, see wl_surface.commit.
+        wl_surface.set_input_region changes the pending input region.
+        wl_surface.commit copies the pending region to the current region.
+        Otherwise the pending and current regions are never changed,
+        except cursor and icon surfaces are special cases, see
+        wl_pointer.set_cursor and wl_data_device.start_drag.
+        The initial value for an input region is infinite. That means the
+        whole surface will accept input. Setting the pending input region
+        has copy semantics, and the wl_region object can be destroyed
+        immediately. A NULL wl_region causes the input region to be set
+        to infinite.
+      </description>
+      <arg name="region" type="object" interface="wl_region" allow-null="true"
+           summary="input region of the surface"/>
+    </request>
+    <request name="commit">
+      <description summary="commit pending surface state">
+        Surface state (input, opaque, and damage regions, attached buffers,
+        etc.) is double-buffered. Protocol requests modify the pending state,
+        as opposed to the current state in use by the compositor. A commit
+        request atomically applies all pending state, replacing the current
+        state. After commit, the new pending state is as documented for each
+        related request.
+        On commit, a pending wl_buffer is applied first, and all other state
+        second. This means that all coordinates in double-buffered state are
+        relative to the new wl_buffer coming into use, except for
+        wl_surface.attach itself. If there is no pending wl_buffer, the
+        coordinates are relative to the current surface contents.
+        All requests that need a commit to become effective are documented
+        to affect double-buffered state.
+        Other interfaces may add further double-buffered surface state.
+      </description>
+    </request>
+    <event name="enter">
+      <description summary="surface enters an output">
+        This is emitted whenever a surface's creation, movement, or resizing
+        results in some part of it being within the scanout region of an
+        output.
+        Note that a surface may be overlapping with zero or more outputs.
+      </description>
+      <arg name="output" type="object" interface="wl_output" summary="output entered by the surface"/>
+    </event>
+    <event name="leave">
+      <description summary="surface leaves an output">
+        This is emitted whenever a surface's creation, movement, or resizing
+        results in it no longer having any part of it within the scanout region
+        of an output.
+        Clients should not use the number of outputs the surface is on for frame
+        throttling purposes. The surface might be hidden even if no leave event
+        has been sent, and the compositor might expect new surface content
+        updates even if no enter event has been sent. The frame event should be
+        used instead.
+      </description>
+      <arg name="output" type="object" interface="wl_output" summary="output left by the surface"/>
+    </event>
+    <!-- Version 2 additions -->
+    <request name="set_buffer_transform" since="2">
+      <description summary="sets the buffer transformation">
+        This request sets an optional transformation on how the compositor
+        interprets the contents of the buffer attached to the surface. The
+        accepted values for the transform parameter are the values for
+        wl_output.transform.
+        Buffer transform is double-buffered state, see wl_surface.commit.
+        A newly created surface has its buffer transformation set to normal.
+        wl_surface.set_buffer_transform changes the pending buffer
+        transformation. wl_surface.commit copies the pending buffer
+        transformation to the current one. Otherwise, the pending and current
+        values are never changed.
+        The purpose of this request is to allow clients to render content
+        according to the output transform, thus permitting the compositor to
+        use certain optimizations even if the display is rotated. Using
+        hardware overlays and scanning out a client buffer for fullscreen
+        surfaces are examples of such optimizations. Those optimizations are
+        highly dependent on the compositor implementation, so the use of this
+        request should be considered on a case-by-case basis.
+        Note that if the transform value includes 90 or 270 degree rotation,
+        the width of the buffer will become the surface height and the height
+        of the buffer will become the surface width.
+        If transform is not one of the values from the
+        wl_output.transform enum the invalid_transform protocol error
+        is raised.
+      </description>
+      <arg name="transform" type="int" enum="wl_output.transform"
+           summary="transform for interpreting buffer contents"/>
+    </request>
+    <!-- Version 3 additions -->
+    <request name="set_buffer_scale" since="3">
+      <description summary="sets the buffer scaling factor">
+        This request sets an optional scaling factor on how the compositor
+        interprets the contents of the buffer attached to the window.
+        Buffer scale is double-buffered state, see wl_surface.commit.
+        A newly created surface has its buffer scale set to 1.
+        wl_surface.set_buffer_scale changes the pending buffer scale.
+        wl_surface.commit copies the pending buffer scale to the current one.
+        Otherwise, the pending and current values are never changed.
+        The purpose of this request is to allow clients to supply higher
+        resolution buffer data for use on high resolution outputs. It is
+        intended that you pick the same buffer scale as the scale of the
+        output that the surface is displayed on. This means the compositor
+        can avoid scaling when rendering the surface on that output.
+        Note that if the scale is larger than 1, then you have to attach
+        a buffer that is larger (by a factor of scale in each dimension)
+        than the desired surface size.
+        If scale is not positive the invalid_scale protocol error is
+        raised.
+      </description>
+      <arg name="scale" type="int"
+           summary="positive scale for interpreting buffer contents"/>
+    </request>
+    <!-- Version 4 additions -->
+    <request name="damage_buffer" since="4">
+      <description summary="mark part of the surface damaged using buffer coordinates">
+        This request is used to describe the regions where the pending
+        buffer is different from the current surface contents, and where
+        the surface therefore needs to be repainted. The compositor
+        ignores the parts of the damage that fall outside of the surface.
+        Damage is double-buffered state, see wl_surface.commit.
+        The damage rectangle is specified in buffer coordinates,
+        where x and y specify the upper left corner of the damage rectangle.
+        The initial value for pending damage is empty: no damage.
+        wl_surface.damage_buffer adds pending damage: the new pending
+        damage is the union of old pending damage and the given rectangle.
+        wl_surface.commit assigns pending damage as the current damage,
+        and clears pending damage. The server will clear the current
+        damage as it repaints the surface.
+        This request differs from wl_surface.damage in only one way - it
+        takes damage in buffer coordinates instead of surface-local
+        coordinates. While this generally is more intuitive than surface
+        coordinates, it is especially desirable when using wp_viewport
+        or when a drawing library (like EGL) is unaware of buffer scale
+        and buffer transform.
+        Note: Because buffer transformation changes and damage requests may
+        be interleaved in the protocol stream, it is impossible to determine
+        the actual mapping between surface and buffer damage until
+        wl_surface.commit time. Therefore, compositors wishing to take both
+        kinds of damage into account will have to accumulate damage from the
+        two requests separately and only transform from one to the other
+        after receiving the wl_surface.commit.
+      </description>
+      <arg name="x" type="int" summary="buffer-local x coordinate"/>
+      <arg name="y" type="int" summary="buffer-local y coordinate"/>
+      <arg name="width" type="int" summary="width of damage rectangle"/>
+      <arg name="height" type="int" summary="height of damage rectangle"/>
+    </request>
+    <!-- Version 5 additions -->
+    <request name="offset" since="5">
+      <description summary="set the surface contents offset">
+        The x and y arguments specify the location of the new pending
+        buffer's upper left corner, relative to the current buffer's upper
+        left corner, in surface-local coordinates. In other words, the
+        x and y, combined with the new surface size define in which
+        directions the surface's size changes.
+        Surface location offset is double-buffered state, see
+        wl_surface.commit.
+        This request is semantically equivalent to and the replaces the x and y
+        arguments in the wl_surface.attach request in wl_surface versions prior
+        to 5. See wl_surface.attach for details.
+      </description>
+      <arg name="x" type="int" summary="surface-local x coordinate"/>
+      <arg name="y" type="int" summary="surface-local y coordinate"/>
+    </request>
+    <!-- Version 6 additions -->
+    <event name="preferred_buffer_scale" since="6">
+      <description summary="preferred buffer scale for the surface">
+        This event indicates the preferred buffer scale for this surface. It is
+        sent whenever the compositor's preference changes.
+        It is intended that scaling aware clients use this event to scale their
+        content and use wl_surface.set_buffer_scale to indicate the scale they
+        have rendered with. This allows clients to supply a higher detail
+        buffer.
+      </description>
+      <arg name="factor" type="int" summary="preferred scaling factor"/>
+    </event>
+    <event name="preferred_buffer_transform" since="6">
+      <description summary="preferred buffer transform for the surface">
+        This event indicates the preferred buffer transform for this surface.
+        It is sent whenever the compositor's preference changes.
+        It is intended that transform aware clients use this event to apply the
+        transform to their content and use wl_surface.set_buffer_transform to
+        indicate the transform they have rendered with.
+      </description>
+      <arg name="transform" type="uint" enum="wl_output.transform"
+           summary="preferred transform"/>
+    </event>
+   </interface>
+  <interface name="wl_seat" version="9">
+    <description summary="group of input devices">
+      A seat is a group of keyboards, pointer and touch devices. This
+      object is published as a global during start up, or when such a
+      device is hot plugged.  A seat typically has a pointer and
+      maintains a keyboard focus and a pointer focus.
+    </description>
+    <enum name="capability" bitfield="true">
+      <description summary="seat capability bitmask">
+        This is a bitmask of capabilities this seat has; if a member is
+        set, then it is present on the seat.
+      </description>
+      <entry name="pointer" value="1" summary="the seat has pointer devices"/>
+      <entry name="keyboard" value="2" summary="the seat has one or more keyboards"/>
+      <entry name="touch" value="4" summary="the seat has touch devices"/>
+    </enum>
+    <enum name="error">
+      <description summary="wl_seat error values">
+        These errors can be emitted in response to wl_seat requests.
+      </description>
+      <entry name="missing_capability" value="0"
+             summary="get_pointer, get_keyboard or get_touch called on seat without the matching capability"/>
+    </enum>
+    <event name="capabilities">
+      <description summary="seat capabilities changed">
+        This is emitted whenever a seat gains or loses the pointer,
+        keyboard or touch capabilities.  The argument is a capability
+        enum containing the complete set of capabilities this seat has.
+        When the pointer capability is added, a client may create a
+        wl_pointer object using the wl_seat.get_pointer request. This object
+        will receive pointer events until the capability is removed in the
+        future.
+        When the pointer capability is removed, a client should destroy the
+        wl_pointer objects associated with the seat where the capability was
+        removed, using the wl_pointer.release request. No further pointer
+        events will be received on these objects.
+        In some compositors, if a seat regains the pointer capability and a
+        client has a previously obtained wl_pointer object of version 4 or
+        less, that object may start sending pointer events again. This
+        behavior is considered a misinterpretation of the intended behavior
+        and must not be relied upon by the client. wl_pointer objects of
+        version 5 or later must not send events if created before the most
+        recent event notifying the client of an added pointer capability.
+        The above behavior also applies to wl_keyboard and wl_touch with the
+        keyboard and touch capabilities, respectively.
+      </description>
+      <arg name="capabilities" type="uint" enum="capability" summary="capabilities of the seat"/>
+    </event>
+    <request name="get_pointer">
+      <description summary="return pointer object">
+        The ID provided will be initialized to the wl_pointer interface
+        for this seat.
+        This request only takes effect if the seat has the pointer
+        capability, or has had the pointer capability in the past.
+        It is a protocol violation to issue this request on a seat that has
+        never had the pointer capability. The missing_capability error will
+        be sent in this case.
+      </description>
+      <arg name="id" type="new_id" interface="wl_pointer" summary="seat pointer"/>
+    </request>
+    <request name="get_keyboard">
+      <description summary="return keyboard object">
+        The ID provided will be initialized to the wl_keyboard interface
+        for this seat.
+        This request only takes effect if the seat has the keyboard
+        capability, or has had the keyboard capability in the past.
+        It is a protocol violation to issue this request on a seat that has
+        never had the keyboard capability. The missing_capability error will
+        be sent in this case.
+      </description>
+      <arg name="id" type="new_id" interface="wl_keyboard" summary="seat keyboard"/>
+    </request>
+    <request name="get_touch">
+      <description summary="return touch object">
+        The ID provided will be initialized to the wl_touch interface
+        for this seat.
+        This request only takes effect if the seat has the touch
+        capability, or has had the touch capability in the past.
+        It is a protocol violation to issue this request on a seat that has
+        never had the touch capability. The missing_capability error will
+        be sent in this case.
+      </description>
+      <arg name="id" type="new_id" interface="wl_touch" summary="seat touch interface"/>
+    </request>
+    <!-- Version 2 additions -->
+    <event name="name" since="2">
+      <description summary="unique identifier for this seat">
+        In a multi-seat configuration the seat name can be used by clients to
+        help identify which physical devices the seat represents.
+        The seat name is a UTF-8 string with no convention defined for its
+        contents. Each name is unique among all wl_seat globals. The name is
+        only guaranteed to be unique for the current compositor instance.
+        The same seat names are used for all clients. Thus, the name can be
+        shared across processes to refer to a specific wl_seat global.
+        The name event is sent after binding to the seat global. This event is
+        only sent once per seat object, and the name does not change over the
+        lifetime of the wl_seat global.
+        Compositors may re-use the same seat name if the wl_seat global is
+        destroyed and re-created later.
+      </description>
+      <arg name="name" type="string" summary="seat identifier"/>
+    </event>
+    <!-- Version 5 additions -->
+    <request name="release" type="destructor" since="5">
+      <description summary="release the seat object">
+        Using this request a client can tell the server that it is not going to
+        use the seat object anymore.
+      </description>
+    </request>
+  </interface>
+  <interface name="wl_pointer" version="9">
+    <description summary="pointer input device">
+      The wl_pointer interface represents one or more input devices,
+      such as mice, which control the pointer location and pointer_focus
+      of a seat.
+      The wl_pointer interface generates motion, enter and leave
+      events for the surfaces that the pointer is located over,
+      and button and axis events for button presses, button releases
+      and scrolling.
+    </description>
+    <enum name="error">
+      <entry name="role" value="0" summary="given wl_surface has another role"/>
+    </enum>
+    <request name="set_cursor">
+      <description summary="set the pointer surface">
+        Set the pointer surface, i.e., the surface that contains the
+        pointer image (cursor). This request gives the surface the role
+        of a cursor. If the surface already has another role, it raises
+        a protocol error.
+        The cursor actually changes only if the pointer
+        focus for this device is one of the requesting client's surfaces
+        or the surface parameter is the current pointer surface. If
+        there was a previous surface set with this request it is
+        replaced. If surface is NULL, the pointer image is hidden.
+        The parameters hotspot_x and hotspot_y define the position of
+        the pointer surface relative to the pointer location. Its
+        top-left corner is always at (x, y) - (hotspot_x, hotspot_y),
+        where (x, y) are the coordinates of the pointer location, in
+        surface-local coordinates.
+        On surface.attach requests to the pointer surface, hotspot_x
+        and hotspot_y are decremented by the x and y parameters
+        passed to the request. Attach must be confirmed by
+        wl_surface.commit as usual.
+        The hotspot can also be updated by passing the currently set
+        pointer surface to this request with new values for hotspot_x
+        and hotspot_y.
+        The input region is ignored for wl_surfaces with the role of
+        a cursor. When the use as a cursor ends, the wl_surface is
+        unmapped.
+        The serial parameter must match the latest wl_pointer.enter
+        serial number sent to the client. Otherwise the request will be
+        ignored.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the enter event"/>
+      <arg name="surface" type="object" interface="wl_surface" allow-null="true"
+           summary="pointer surface"/>
+      <arg name="hotspot_x" type="int" summary="surface-local x coordinate"/>
+      <arg name="hotspot_y" type="int" summary="surface-local y coordinate"/>
+    </request>
+    <event name="enter">
+      <description summary="enter event">
+        Notification that this seat's pointer is focused on a certain
+        surface.
+        When a seat's focus enters a surface, the pointer image
+        is undefined and a client should respond to this event by setting
+        an appropriate pointer image with the set_cursor request.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the enter event"/>
+      <arg name="surface" type="object" interface="wl_surface" summary="surface entered by the pointer"/>
+      <arg name="surface_x" type="fixed" summary="surface-local x coordinate"/>
+      <arg name="surface_y" type="fixed" summary="surface-local y coordinate"/>
+    </event>
+    <event name="leave">
+      <description summary="leave event">
+        Notification that this seat's pointer is no longer focused on
+        a certain surface.
+        The leave notification is sent before the enter notification
+        for the new focus.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the leave event"/>
+      <arg name="surface" type="object" interface="wl_surface" summary="surface left by the pointer"/>
+    </event>
+    <event name="motion">
+      <description summary="pointer motion event">
+        Notification of pointer location change. The arguments
+        surface_x and surface_y are the location relative to the
+        focused surface.
+      </description>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+      <arg name="surface_x" type="fixed" summary="surface-local x coordinate"/>
+      <arg name="surface_y" type="fixed" summary="surface-local y coordinate"/>
+    </event>
+    <enum name="button_state">
+      <description summary="physical button state">
+        Describes the physical state of a button that produced the button
+        event.
+      </description>
+      <entry name="released" value="0" summary="the button is not pressed"/>
+      <entry name="pressed" value="1" summary="the button is pressed"/>
+    </enum>
+    <event name="button">
+      <description summary="pointer button event">
+        Mouse button click and release notifications.
+        The location of the click is given by the last motion or
+        enter event.
+        The time argument is a timestamp with millisecond
+        granularity, with an undefined base.
+        The button is a button code as defined in the Linux kernel's
+        linux/input-event-codes.h header file, e.g. BTN_LEFT.
+        Any 16-bit button code value is reserved for future additions to the
+        kernel's event code list. All other button codes above 0xFFFF are
+        currently undefined but may be used in future versions of this
+        protocol.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the button event"/>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+      <arg name="button" type="uint" summary="button that produced the event"/>
+      <arg name="state" type="uint" enum="button_state" summary="physical state of the button"/>
+    </event>
+    <enum name="axis">
+      <description summary="axis types">
+        Describes the axis types of scroll events.
+      </description>
+      <entry name="vertical_scroll" value="0" summary="vertical axis"/>
+      <entry name="horizontal_scroll" value="1" summary="horizontal axis"/>
+    </enum>
+    <event name="axis">
+      <description summary="axis event">
+        Scroll and other axis notifications.
+        For scroll events (vertical and horizontal scroll axes), the
+        value parameter is the length of a vector along the specified
+        axis in a coordinate space identical to those of motion events,
+        representing a relative movement along the specified axis.
+        For devices that support movements non-parallel to axes multiple
+        axis events will be emitted.
+        When applicable, for example for touch pads, the server can
+        choose to emit scroll events where the motion vector is
+        equivalent to a motion event vector.
+        When applicable, a client can transform its content relative to the
+        scroll distance.
+      </description>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+      <arg name="axis" type="uint" enum="axis" summary="axis type"/>
+      <arg name="value" type="fixed" summary="length of vector in surface-local coordinate space"/>
+    </event>
+    <!-- Version 3 additions -->
+    <request name="release" type="destructor" since="3">
+      <description summary="release the pointer object">
+        Using this request a client can tell the server that it is not going to
+        use the pointer object anymore.
+        This request destroys the pointer proxy object, so clients must not call
+        wl_pointer_destroy() after using this request.
+      </description>
+    </request>
+    <!-- Version 5 additions -->
+    <event name="frame" since="5">
+      <description summary="end of a pointer event sequence">
+        Indicates the end of a set of events that logically belong together.
+        A client is expected to accumulate the data in all events within the
+        frame before proceeding.
+        All wl_pointer events before a wl_pointer.frame event belong
+        logically together. For example, in a diagonal scroll motion the
+        compositor will send an optional wl_pointer.axis_source event, two
+        wl_pointer.axis events (horizontal and vertical) and finally a
+        wl_pointer.frame event. The client may use this information to
+        calculate a diagonal vector for scrolling.
+        When multiple wl_pointer.axis events occur within the same frame,
+        the motion vector is the combined motion of all events.
+        When a wl_pointer.axis and a wl_pointer.axis_stop event occur within
+        the same frame, this indicates that axis movement in one axis has
+        stopped but continues in the other axis.
+        When multiple wl_pointer.axis_stop events occur within the same
+        frame, this indicates that these axes stopped in the same instance.
+        A wl_pointer.frame event is sent for every logical event group,
+        even if the group only contains a single wl_pointer event.
+        Specifically, a client may get a sequence: motion, frame, button,
+        frame, axis, frame, axis_stop, frame.
+        The wl_pointer.enter and wl_pointer.leave events are logical events
+        generated by the compositor and not the hardware. These events are
+        also grouped by a wl_pointer.frame. When a pointer moves from one
+        surface to another, a compositor should group the
+        wl_pointer.leave event within the same wl_pointer.frame.
+        However, a client must not rely on wl_pointer.leave and
+        wl_pointer.enter being in the same wl_pointer.frame.
+        Compositor-specific policies may require the wl_pointer.leave and
+        wl_pointer.enter event being split across multiple wl_pointer.frame
+        groups.
+      </description>
+    </event>
+    <enum name="axis_source">
+      <description summary="axis source types">
+        Describes the source types for axis events. This indicates to the
+        client how an axis event was physically generated; a client may
+        adjust the user interface accordingly. For example, scroll events
+        from a "finger" source may be in a smooth coordinate space with
+        kinetic scrolling whereas a "wheel" source may be in discrete steps
+        of a number of lines.
+        The "continuous" axis source is a device generating events in a
+        continuous coordinate space, but using something other than a
+        finger. One example for this source is button-based scrolling where
+        the vertical motion of a device is converted to scroll events while
+        a button is held down.
+        The "wheel tilt" axis source indicates that the actual device is a
+        wheel but the scroll event is not caused by a rotation but a
+        (usually sideways) tilt of the wheel.
+      </description>
+      <entry name="wheel" value="0" summary="a physical wheel rotation" />
+      <entry name="finger" value="1" summary="finger on a touch surface" />
+      <entry name="continuous" value="2" summary="continuous coordinate space"/>
+      <entry name="wheel_tilt" value="3" summary="a physical wheel tilt" since="6"/>
+    </enum>
+    <event name="axis_source" since="5">
+      <description summary="axis source event">
+        Source information for scroll and other axes.
+        This event does not occur on its own. It is sent before a
+        wl_pointer.frame event and carries the source information for
+        all events within that frame.
+        The source specifies how this event was generated. If the source is
+        wl_pointer.axis_source.finger, a wl_pointer.axis_stop event will be
+        sent when the user lifts the finger off the device.
+        If the source is wl_pointer.axis_source.wheel,
+        wl_pointer.axis_source.wheel_tilt or
+        wl_pointer.axis_source.continuous, a wl_pointer.axis_stop event may
+        or may not be sent. Whether a compositor sends an axis_stop event
+        for these sources is hardware-specific and implementation-dependent;
+        clients must not rely on receiving an axis_stop event for these
+        scroll sources and should treat scroll sequences from these scroll
+        sources as unterminated by default.
+        This event is optional. If the source is unknown for a particular
+        axis event sequence, no event is sent.
+        Only one wl_pointer.axis_source event is permitted per frame.
+        The order of wl_pointer.axis_discrete and wl_pointer.axis_source is
+        not guaranteed.
+      </description>
+      <arg name="axis_source" type="uint" enum="axis_source" summary="source of the axis event"/>
+    </event>
+    <event name="axis_stop" since="5">
+      <description summary="axis stop event">
+        Stop notification for scroll and other axes.
+        For some wl_pointer.axis_source types, a wl_pointer.axis_stop event
+        is sent to notify a client that the axis sequence has terminated.
+        This enables the client to implement kinetic scrolling.
+        See the wl_pointer.axis_source documentation for information on when
+        this event may be generated.
+        Any wl_pointer.axis events with the same axis_source after this
+        event should be considered as the start of a new axis motion.
+        The timestamp is to be interpreted identical to the timestamp in the
+        wl_pointer.axis event. The timestamp value may be the same as a
+        preceding wl_pointer.axis event.
+      </description>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+      <arg name="axis" type="uint" enum="axis" summary="the axis stopped with this event"/>
+    </event>
+    <event name="axis_discrete" since="5">
+      <description summary="axis click event">
+        Discrete step information for scroll and other axes.
+        This event carries the axis value of the wl_pointer.axis event in
+        discrete steps (e.g. mouse wheel clicks).
+        This event is deprecated with wl_pointer version 8 - this event is not
+        sent to clients supporting version 8 or later.
+        This event does not occur on its own, it is coupled with a
+        wl_pointer.axis event that represents this axis value on a
+        continuous scale. The protocol guarantees that each axis_discrete
+        event is always followed by exactly one axis event with the same
+        axis number within the same wl_pointer.frame. Note that the protocol
+        allows for other events to occur between the axis_discrete and
+        its coupled axis event, including other axis_discrete or axis
+        events. A wl_pointer.frame must not contain more than one axis_discrete
+        event per axis type.
+        This event is optional; continuous scrolling devices
+        like two-finger scrolling on touchpads do not have discrete
+        steps and do not generate this event.
+        The discrete value carries the directional information. e.g. a value
+        of -2 is two steps towards the negative direction of this axis.
+        The axis number is identical to the axis number in the associated
+        axis event.
+        The order of wl_pointer.axis_discrete and wl_pointer.axis_source is
+        not guaranteed.
+      </description>
+      <arg name="axis" type="uint" enum="axis" summary="axis type"/>
+      <arg name="discrete" type="int" summary="number of steps"/>
+    </event>
+    <event name="axis_value120" since="8">
+      <description summary="axis high-resolution scroll event">
+        Discrete high-resolution scroll information.
+        This event carries high-resolution wheel scroll information,
+        with each multiple of 120 representing one logical scroll step
+        (a wheel detent). For example, an axis_value120 of 30 is one quarter of
+        a logical scroll step in the positive direction, a value120 of
+        -240 are two logical scroll steps in the negative direction within the
+        same hardware event.
+        Clients that rely on discrete scrolling should accumulate the
+        value120 to multiples of 120 before processing the event.
+        The value120 must not be zero.
+        This event replaces the wl_pointer.axis_discrete event in clients
+        supporting wl_pointer version 8 or later.
+        Where a wl_pointer.axis_source event occurs in the same
+        wl_pointer.frame, the axis source applies to this event.
+        The order of wl_pointer.axis_value120 and wl_pointer.axis_source is
+        not guaranteed.
+      </description>
+      <arg name="axis" type="uint" enum="axis" summary="axis type"/>
+      <arg name="value120" type="int" summary="scroll distance as fraction of 120"/>
+    </event>
+    <!-- Version 9 additions -->
+    <enum name="axis_relative_direction">
+      <description summary="axis relative direction">
+        This specifies the direction of the physical motion that caused a
+        wl_pointer.axis event, relative to the wl_pointer.axis direction.
+      </description>
+      <entry name="identical" value="0"
+          summary="physical motion matches axis direction"/>
+      <entry name="inverted" value="1"
+          summary="physical motion is the inverse of the axis direction"/>
+    </enum>
+    <event name="axis_relative_direction" since="9">
+      <description summary="axis relative physical direction event">
+        Relative directional information of the entity causing the axis
+        motion.
+        For a wl_pointer.axis event, the wl_pointer.axis_relative_direction
+        event specifies the movement direction of the entity causing the
+        wl_pointer.axis event. For example:
+        - if a user's fingers on a touchpad move down and this
+          causes a wl_pointer.axis vertical_scroll down event, the physical
+          direction is 'identical'
+        - if a user's fingers on a touchpad move down and this causes a
+          wl_pointer.axis vertical_scroll up scroll up event ('natural
+          scrolling'), the physical direction is 'inverted'.
+        A client may use this information to adjust scroll motion of
+        components. Specifically, enabling natural scrolling causes the
+        content to change direction compared to traditional scrolling.
+        Some widgets like volume control sliders should usually match the
+        physical direction regardless of whether natural scrolling is
+        active. This event enables clients to match the scroll direction of
+        a widget to the physical direction.
+        This event does not occur on its own, it is coupled with a
+        wl_pointer.axis event that represents this axis value.
+        The protocol guarantees that each axis_relative_direction event is
+        always followed by exactly one axis event with the same
+        axis number within the same wl_pointer.frame. Note that the protocol
+        allows for other events to occur between the axis_relative_direction
+        and its coupled axis event.
+        The axis number is identical to the axis number in the associated
+        axis event.
+        The order of wl_pointer.axis_relative_direction,
+        wl_pointer.axis_discrete and wl_pointer.axis_source is not
+        guaranteed.
+      </description>
+      <arg name="axis" type="uint" enum="axis" summary="axis type"/>
+      <arg name="direction" type="uint" enum="axis_relative_direction"
+          summary="physical direction relative to axis motion"/>
+    </event>
+  </interface>
+  <interface name="wl_keyboard" version="9">
+    <description summary="keyboard input device">
+      The wl_keyboard interface represents one or more keyboards
+      associated with a seat.
+    </description>
+    <enum name="keymap_format">
+      <description summary="keyboard mapping format">
+        This specifies the format of the keymap provided to the
+        client with the wl_keyboard.keymap event.
+      </description>
+      <entry name="no_keymap" value="0"
+             summary="no keymap; client must understand how to interpret the raw keycode"/>
+      <entry name="xkb_v1" value="1"
+             summary="libxkbcommon compatible, null-terminated string; to determine the xkb keycode, clients must add 8 to the key event keycode"/>
+    </enum>
+    <event name="keymap">
+      <description summary="keyboard mapping">
+        This event provides a file descriptor to the client which can be
+        memory-mapped in read-only mode to provide a keyboard mapping
+        description.
+        From version 7 onwards, the fd must be mapped with MAP_PRIVATE by
+        the recipient, as MAP_SHARED may fail.
+      </description>
+      <arg name="format" type="uint" enum="keymap_format" summary="keymap format"/>
+      <arg name="fd" type="fd" summary="keymap file descriptor"/>
+      <arg name="size" type="uint" summary="keymap size, in bytes"/>
+    </event>
+    <event name="enter">
+      <description summary="enter event">
+        Notification that this seat's keyboard focus is on a certain
+        surface.
+        The compositor must send the wl_keyboard.modifiers event after this
+        event.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the enter event"/>
+      <arg name="surface" type="object" interface="wl_surface" summary="surface gaining keyboard focus"/>
+      <arg name="keys" type="array" summary="the currently pressed keys"/>
+    </event>
+    <event name="leave">
+      <description summary="leave event">
+        Notification that this seat's keyboard focus is no longer on
+        a certain surface.
+        The leave notification is sent before the enter notification
+        for the new focus.
+        After this event client must assume that all keys, including modifiers,
+        are lifted and also it must stop key repeating if there's some going on.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the leave event"/>
+      <arg name="surface" type="object" interface="wl_surface" summary="surface that lost keyboard focus"/>
+    </event>
+    <enum name="key_state">
+      <description summary="physical key state">
+        Describes the physical state of a key that produced the key event.
+      </description>
+      <entry name="released" value="0" summary="key is not pressed"/>
+      <entry name="pressed" value="1" summary="key is pressed"/>
+    </enum>
+    <event name="key">
+      <description summary="key event">
+        A key was pressed or released.
+        The time argument is a timestamp with millisecond
+        granularity, with an undefined base.
+        The key is a platform-specific key code that can be interpreted
+        by feeding it to the keyboard mapping (see the keymap event).
+        If this event produces a change in modifiers, then the resulting
+        wl_keyboard.modifiers event must be sent after this event.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the key event"/>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+      <arg name="key" type="uint" summary="key that produced the event"/>
+      <arg name="state" type="uint" enum="key_state" summary="physical state of the key"/>
+    </event>
+    <event name="modifiers">
+      <description summary="modifier and group state">
+        Notifies clients that the modifier and/or group state has
+        changed, and it should update its local state.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the modifiers event"/>
+      <arg name="mods_depressed" type="uint" summary="depressed modifiers"/>
+      <arg name="mods_latched" type="uint" summary="latched modifiers"/>
+      <arg name="mods_locked" type="uint" summary="locked modifiers"/>
+      <arg name="group" type="uint" summary="keyboard layout"/>
+    </event>
+    <!-- Version 3 additions -->
+    <request name="release" type="destructor" since="3">
+      <description summary="release the keyboard object"/>
+    </request>
+    <!-- Version 4 additions -->
+    <event name="repeat_info" since="4">
+      <description summary="repeat rate and delay">
+        Informs the client about the keyboard's repeat rate and delay.
+        This event is sent as soon as the wl_keyboard object has been created,
+        and is guaranteed to be received by the client before any key press
+        event.
+        Negative values for either rate or delay are illegal. A rate of zero
+        will disable any repeating (regardless of the value of delay).
+        This event can be sent later on as well with a new value if necessary,
+        so clients should continue listening for the event past the creation
+        of wl_keyboard.
+      </description>
+      <arg name="rate" type="int"
+           summary="the rate of repeating keys in characters per second"/>
+      <arg name="delay" type="int"
+           summary="delay in milliseconds since key down until repeating starts"/>
+    </event>
+  </interface>
+  <interface name="wl_touch" version="9">
+    <description summary="touchscreen input device">
+      The wl_touch interface represents a touchscreen
+      associated with a seat.
+      Touch interactions can consist of one or more contacts.
+      For each contact, a series of events is generated, starting
+      with a down event, followed by zero or more motion events,
+      and ending with an up event. Events relating to the same
+      contact point can be identified by the ID of the sequence.
+    </description>
+    <event name="down">
+      <description summary="touch down event and beginning of a touch sequence">
+        A new touch point has appeared on the surface. This touch point is
+        assigned a unique ID. Future events from this touch point reference
+        this ID. The ID ceases to be valid after a touch up event and may be
+        reused in the future.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the touch down event"/>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+      <arg name="surface" type="object" interface="wl_surface" summary="surface touched"/>
+      <arg name="id" type="int" summary="the unique ID of this touch point"/>
+      <arg name="x" type="fixed" summary="surface-local x coordinate"/>
+      <arg name="y" type="fixed" summary="surface-local y coordinate"/>
+    </event>
+    <event name="up">
+      <description summary="end of a touch event sequence">
+        The touch point has disappeared. No further events will be sent for
+        this touch point and the touch point's ID is released and may be
+        reused in a future touch down event.
+      </description>
+      <arg name="serial" type="uint" summary="serial number of the touch up event"/>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+      <arg name="id" type="int" summary="the unique ID of this touch point"/>
+    </event>
+    <event name="motion">
+      <description summary="update of touch point coordinates">
+        A touch point has changed coordinates.
+      </description>
+      <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+      <arg name="id" type="int" summary="the unique ID of this touch point"/>
+      <arg name="x" type="fixed" summary="surface-local x coordinate"/>
+      <arg name="y" type="fixed" summary="surface-local y coordinate"/>
+    </event>
+    <event name="frame">
+      <description summary="end of touch frame event">
+        Indicates the end of a set of events that logically belong together.
+        A client is expected to accumulate the data in all events within the
+        frame before proceeding.
+        A wl_touch.frame terminates at least one event but otherwise no
+        guarantee is provided about the set of events within a frame. A client
+        must assume that any state not updated in a frame is unchanged from the
+        previously known state.
+      </description>
+    </event>
+    <event name="cancel">
+      <description summary="touch session cancelled">
+        Sent if the compositor decides the touch stream is a global
+        gesture. No further events are sent to the clients from that
+        particular gesture. Touch cancellation applies to all touch points
+        currently active on this client's surface. The client is
+        responsible for finalizing the touch points, future touch points on
+        this surface may reuse the touch point ID.
+      </description>
+    </event>
+    <!-- Version 3 additions -->
+    <request name="release" type="destructor" since="3">
+      <description summary="release the touch object"/>
+    </request>
+    <!-- Version 6 additions -->
+    <event name="shape" since="6">
+      <description summary="update shape of touch point">
+        Sent when a touchpoint has changed its shape.
+        This event does not occur on its own. It is sent before a
+        wl_touch.frame event and carries the new shape information for
+        any previously reported, or new touch points of that frame.
+        Other events describing the touch point such as wl_touch.down,
+        wl_touch.motion or wl_touch.orientation may be sent within the
+        same wl_touch.frame. A client should treat these events as a single
+        logical touch point update. The order of wl_touch.shape,
+        wl_touch.orientation and wl_touch.motion is not guaranteed.
+        A wl_touch.down event is guaranteed to occur before the first
+        wl_touch.shape event for this touch ID but both events may occur within
+        the same wl_touch.frame.
+        A touchpoint shape is approximated by an ellipse through the major and
+        minor axis length. The major axis length describes the longer diameter
+        of the ellipse, while the minor axis length describes the shorter
+        diameter. Major and minor are orthogonal and both are specified in
+        surface-local coordinates. The center of the ellipse is always at the
+        touchpoint location as reported by wl_touch.down or wl_touch.move.
+        This event is only sent by the compositor if the touch device supports
+        shape reports. The client has to make reasonable assumptions about the
+        shape if it did not receive this event.
+      </description>
+      <arg name="id" type="int" summary="the unique ID of this touch point"/>
+      <arg name="major" type="fixed" summary="length of the major axis in surface-local coordinates"/>
+      <arg name="minor" type="fixed" summary="length of the minor axis in surface-local coordinates"/>
+    </event>
+    <event name="orientation" since="6">
+      <description summary="update orientation of touch point">
+        Sent when a touchpoint has changed its orientation.
+        This event does not occur on its own. It is sent before a
+        wl_touch.frame event and carries the new shape information for
+        any previously reported, or new touch points of that frame.
+        Other events describing the touch point such as wl_touch.down,
+        wl_touch.motion or wl_touch.shape may be sent within the
+        same wl_touch.frame. A client should treat these events as a single
+        logical touch point update. The order of wl_touch.shape,
+        wl_touch.orientation and wl_touch.motion is not guaranteed.
+        A wl_touch.down event is guaranteed to occur before the first
+        wl_touch.orientation event for this touch ID but both events may occur
+        within the same wl_touch.frame.
+        The orientation describes the clockwise angle of a touchpoint's major
+        axis to the positive surface y-axis and is normalized to the -180 to
+        +180 degree range. The granularity of orientation depends on the touch
+        device, some devices only support binary rotation values between 0 and
+        90 degrees.
+        This event is only sent by the compositor if the touch device supports
+        orientation reports.
+      </description>
+      <arg name="id" type="int" summary="the unique ID of this touch point"/>
+      <arg name="orientation" type="fixed" summary="angle between major axis and positive surface y-axis in degrees"/>
+    </event>
+  </interface>
+  <interface name="wl_output" version="4">
+    <description summary="compositor output region">
+      An output describes part of the compositor geometry.  The
+      compositor works in the 'compositor coordinate system' and an
+      output corresponds to a rectangular area in that space that is
+      actually visible.  This typically corresponds to a monitor that
+      displays part of the compositor space.  This object is published
+      as global during start up, or when a monitor is hotplugged.
+    </description>
+    <enum name="subpixel">
+      <description summary="subpixel geometry information">
+        This enumeration describes how the physical
+        pixels on an output are laid out.
+      </description>
+      <entry name="unknown" value="0" summary="unknown geometry"/>
+      <entry name="none" value="1" summary="no geometry"/>
+      <entry name="horizontal_rgb" value="2" summary="horizontal RGB"/>
+      <entry name="horizontal_bgr" value="3" summary="horizontal BGR"/>
+      <entry name="vertical_rgb" value="4" summary="vertical RGB"/>
+      <entry name="vertical_bgr" value="5" summary="vertical BGR"/>
+    </enum>
+    <enum name="transform">
+      <description summary="transform from framebuffer to output">
+        This describes the transform that a compositor will apply to a
+        surface to compensate for the rotation or mirroring of an
+        output device.
+        The flipped values correspond to an initial flip around a
+        vertical axis followed by rotation.
+        The purpose is mainly to allow clients to render accordingly and
+        tell the compositor, so that for fullscreen surfaces, the
+        compositor will still be able to scan out directly from client
+        surfaces.
+      </description>
+      <entry name="normal" value="0" summary="no transform"/>
+      <entry name="90" value="1" summary="90 degrees counter-clockwise"/>
+      <entry name="180" value="2" summary="180 degrees counter-clockwise"/>
+      <entry name="270" value="3" summary="270 degrees counter-clockwise"/>
+      <entry name="flipped" value="4" summary="180 degree flip around a vertical axis"/>
+      <entry name="flipped_90" value="5" summary="flip and rotate 90 degrees counter-clockwise"/>
+      <entry name="flipped_180" value="6" summary="flip and rotate 180 degrees counter-clockwise"/>
+      <entry name="flipped_270" value="7" summary="flip and rotate 270 degrees counter-clockwise"/>
+    </enum>
+    <event name="geometry">
+      <description summary="properties of the output">
+        The geometry event describes geometric properties of the output.
+        The event is sent when binding to the output object and whenever
+        any of the properties change.
+        The physical size can be set to zero if it doesn't make sense for this
+        output (e.g. for projectors or virtual outputs).
+        The geometry event will be followed by a done event (starting from
+        version 2).
+        Note: wl_output only advertises partial information about the output
+        position and identification. Some compositors, for instance those not
+        implementing a desktop-style output layout or those exposing virtual
+        outputs, might fake this information. Instead of using x and y, clients
+        should use xdg_output.logical_position. Instead of using make and model,
+        clients should use name and description.
+      </description>
+      <arg name="x" type="int"
+           summary="x position within the global compositor space"/>
+      <arg name="y" type="int"
+           summary="y position within the global compositor space"/>
+      <arg name="physical_width" type="int"
+           summary="width in millimeters of the output"/>
+      <arg name="physical_height" type="int"
+           summary="height in millimeters of the output"/>
+      <arg name="subpixel" type="int" enum="subpixel"
+           summary="subpixel orientation of the output"/>
+      <arg name="make" type="string"
+           summary="textual description of the manufacturer"/>
+      <arg name="model" type="string"
+           summary="textual description of the model"/>
+      <arg name="transform" type="int" enum="transform"
+           summary="transform that maps framebuffer to output"/>
+    </event>
+    <enum name="mode" bitfield="true">
+      <description summary="mode information">
+        These flags describe properties of an output mode.
+        They are used in the flags bitfield of the mode event.
+      </description>
+      <entry name="current" value="0x1"
+             summary="indicates this is the current mode"/>
+      <entry name="preferred" value="0x2"
+             summary="indicates this is the preferred mode"/>
+    </enum>
+    <event name="mode">
+      <description summary="advertise available modes for the output">
+        The mode event describes an available mode for the output.
+        The event is sent when binding to the output object and there
+        will always be one mode, the current mode.  The event is sent
+        again if an output changes mode, for the mode that is now
+        current.  In other words, the current mode is always the last
+        mode that was received with the current flag set.
+        Non-current modes are deprecated. A compositor can decide to only
+        advertise the current mode and never send other modes. Clients
+        should not rely on non-current modes.
+        The size of a mode is given in physical hardware units of
+        the output device. This is not necessarily the same as
+        the output size in the global compositor space. For instance,
+        the output may be scaled, as described in wl_output.scale,
+        or transformed, as described in wl_output.transform. Clients
+        willing to retrieve the output size in the global compositor
+        space should use xdg_output.logical_size instead.
+        The vertical refresh rate can be set to zero if it doesn't make
+        sense for this output (e.g. for virtual outputs).
+        The mode event will be followed by a done event (starting from
+        version 2).
+        Clients should not use the refresh rate to schedule frames. Instead,
+        they should use the wl_surface.frame event or the presentation-time
+        protocol.
+        Note: this information is not always meaningful for all outputs. Some
+        compositors, such as those exposing virtual outputs, might fake the
+        refresh rate or the size.
+      </description>
+      <arg name="flags" type="uint" enum="mode" summary="bitfield of mode flags"/>
+      <arg name="width" type="int" summary="width of the mode in hardware units"/>
+      <arg name="height" type="int" summary="height of the mode in hardware units"/>
+      <arg name="refresh" type="int" summary="vertical refresh rate in mHz"/>
+    </event>
+    <!-- Version 2 additions -->
+    <event name="done" since="2">
+      <description summary="sent all information about output">
+        This event is sent after all other properties have been
+        sent after binding to the output object and after any
+        other property changes done after that. This allows
+        changes to the output properties to be seen as
+        atomic, even if they happen via multiple events.
+      </description>
+    </event>
+    <event name="scale" since="2">
+      <description summary="output scaling properties">
+        This event contains scaling geometry information
+        that is not in the geometry event. It may be sent after
+        binding the output object or if the output scale changes
+        later. If it is not sent, the client should assume a
+        scale of 1.
+        A scale larger than 1 means that the compositor will
+        automatically scale surface buffers by this amount
+        when rendering. This is used for very high resolution
+        displays where applications rendering at the native
+        resolution would be too small to be legible.
+        It is intended that scaling aware clients track the
+        current output of a surface, and if it is on a scaled
+        output it should use wl_surface.set_buffer_scale with
+        the scale of the output. That way the compositor can
+        avoid scaling the surface, and the client can supply
+        a higher detail image.
+        The scale event will be followed by a done event.
+      </description>
+      <arg name="factor" type="int" summary="scaling factor of output"/>
+    </event>
+    <!-- Version 3 additions -->
+    <request name="release" type="destructor" since="3">
+      <description summary="release the output object">
+        Using this request a client can tell the server that it is not going to
+        use the output object anymore.
+      </description>
+    </request>
+    <!-- Version 4 additions -->
+    <event name="name" since="4">
+      <description summary="name of this output">
+        Many compositors will assign user-friendly names to their outputs, show
+        them to the user, allow the user to refer to an output, etc. The client
+        may wish to know this name as well to offer the user similar behaviors.
+        The name is a UTF-8 string with no convention defined for its contents.
+        Each name is unique among all wl_output globals. The name is only
+        guaranteed to be unique for the compositor instance.
+        The same output name is used for all clients for a given wl_output
+        global. Thus, the name can be shared across processes to refer to a
+        specific wl_output global.
+        The name is not guaranteed to be persistent across sessions, thus cannot
+        be used to reliably identify an output in e.g. configuration files.
+        Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do
+        not assume that the name is a reflection of an underlying DRM connector,
+        X11 connection, etc.
+        The name event is sent after binding the output object. This event is
+        only sent once per output object, and the name does not change over the
+        lifetime of the wl_output global.
+        Compositors may re-use the same output name if the wl_output global is
+        destroyed and re-created later. Compositors should avoid re-using the
+        same name if possible.
+        The name event will be followed by a done event.
+      </description>
+      <arg name="name" type="string" summary="output name"/>
+    </event>
+    <event name="description" since="4">
+      <description summary="human-readable description of this output">
+        Many compositors can produce human-readable descriptions of their
+        outputs. The client may wish to know this description as well, e.g. for
+        output selection purposes.
+        The description is a UTF-8 string with no convention defined for its
+        contents. The description is not guaranteed to be unique among all
+        wl_output globals. Examples might include 'Foocorp 11" Display' or
+        'Virtual X11 output via :1'.
+        The description event is sent after binding the output object and
+        whenever the description changes. The description is optional, and may
+        not be sent at all.
+        The description event will be followed by a done event.
+      </description>
+      <arg name="description" type="string" summary="output description"/>
+    </event>
+  </interface>
+  <interface name="wl_region" version="1">
+    <description summary="region interface">
+      A region object describes an area.
+      Region objects are used to describe the opaque and input
+      regions of a surface.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy region">
+        Destroy the region.  This will invalidate the object ID.
+      </description>
+    </request>
+    <request name="add">
+      <description summary="add rectangle to region">
+        Add the specified rectangle to the region.
+      </description>
+      <arg name="x" type="int" summary="region-local x coordinate"/>
+      <arg name="y" type="int" summary="region-local y coordinate"/>
+      <arg name="width" type="int" summary="rectangle width"/>
+      <arg name="height" type="int" summary="rectangle height"/>
+    </request>
+    <request name="subtract">
+      <description summary="subtract rectangle from region">
+        Subtract the specified rectangle from the region.
+      </description>
+      <arg name="x" type="int" summary="region-local x coordinate"/>
+      <arg name="y" type="int" summary="region-local y coordinate"/>
+      <arg name="width" type="int" summary="rectangle width"/>
+      <arg name="height" type="int" summary="rectangle height"/>
+    </request>
+  </interface>
+  <interface name="wl_subcompositor" version="1">
+    <description summary="sub-surface compositing">
+      The global interface exposing sub-surface compositing capabilities.
+      A wl_surface, that has sub-surfaces associated, is called the
+      parent surface. Sub-surfaces can be arbitrarily nested and create
+      a tree of sub-surfaces.
+      The root surface in a tree of sub-surfaces is the main
+      surface. The main surface cannot be a sub-surface, because
+      sub-surfaces must always have a parent.
+      A main surface with its sub-surfaces forms a (compound) window.
+      For window management purposes, this set of wl_surface objects is
+      to be considered as a single window, and it should also behave as
+      such.
+      The aim of sub-surfaces is to offload some of the compositing work
+      within a window from clients to the compositor. A prime example is
+      a video player with decorations and video in separate wl_surface
+      objects. This should allow the compositor to pass YUV video buffer
+      processing to dedicated overlay hardware when possible.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="unbind from the subcompositor interface">
+        Informs the server that the client will not be using this
+        protocol object anymore. This does not affect any other
+        objects, wl_subsurface objects included.
+      </description>
+    </request>
+    <enum name="error">
+      <entry name="bad_surface" value="0"
+             summary="the to-be sub-surface is invalid"/>
+      <entry name="bad_parent" value="1"
+             summary="the to-be sub-surface parent is invalid"/>
+    </enum>
+    <request name="get_subsurface">
+      <description summary="give a surface the role sub-surface">
+        Create a sub-surface interface for the given surface, and
+        associate it with the given parent surface. This turns a
+        plain wl_surface into a sub-surface.
+        The to-be sub-surface must not already have another role, and it
+        must not have an existing wl_subsurface object. Otherwise the
+        bad_surface protocol error is raised.
+        Adding sub-surfaces to a parent is a double-buffered operation on the
+        parent (see wl_surface.commit). The effect of adding a sub-surface
+        becomes visible on the next time the state of the parent surface is
+        applied.
+        The parent surface must not be one of the child surface's descendants,
+        and the parent must be different from the child surface, otherwise the
+        bad_parent protocol error is raised.
+        This request modifies the behaviour of wl_surface.commit request on
+        the sub-surface, see the documentation on wl_subsurface interface.
+      </description>
+      <arg name="id" type="new_id" interface="wl_subsurface"
+           summary="the new sub-surface object ID"/>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="the surface to be turned into a sub-surface"/>
+      <arg name="parent" type="object" interface="wl_surface"
+           summary="the parent surface"/>
+    </request>
+  </interface>
+  <interface name="wl_subsurface" version="1">
+    <description summary="sub-surface interface to a wl_surface">
+      An additional interface to a wl_surface object, which has been
+      made a sub-surface. A sub-surface has one parent surface. A
+      sub-surface's size and position are not limited to that of the parent.
+      Particularly, a sub-surface is not automatically clipped to its
+      parent's area.
+      A sub-surface becomes mapped, when a non-NULL wl_buffer is applied
+      and the parent surface is mapped. The order of which one happens
+      first is irrelevant. A sub-surface is hidden if the parent becomes
+      hidden, or if a NULL wl_buffer is applied. These rules apply
+      recursively through the tree of surfaces.
+      The behaviour of a wl_surface.commit request on a sub-surface
+      depends on the sub-surface's mode. The possible modes are
+      synchronized and desynchronized, see methods
+      wl_subsurface.set_sync and wl_subsurface.set_desync. Synchronized
+      mode caches the wl_surface state to be applied when the parent's
+      state gets applied, and desynchronized mode applies the pending
+      wl_surface state directly. A sub-surface is initially in the
+      synchronized mode.
+      Sub-surfaces also have another kind of state, which is managed by
+      wl_subsurface requests, as opposed to wl_surface requests. This
+      state includes the sub-surface position relative to the parent
+      surface (wl_subsurface.set_position), and the stacking order of
+      the parent and its sub-surfaces (wl_subsurface.place_above and
+      .place_below). This state is applied when the parent surface's
+      wl_surface state is applied, regardless of the sub-surface's mode.
+      As the exception, set_sync and set_desync are effective immediately.
+      The main surface can be thought to be always in desynchronized mode,
+      since it does not have a parent in the sub-surfaces sense.
+      Even if a sub-surface is in desynchronized mode, it will behave as
+      in synchronized mode, if its parent surface behaves as in
+      synchronized mode. This rule is applied recursively throughout the
+      tree of surfaces. This means, that one can set a sub-surface into
+      synchronized mode, and then assume that all its child and grand-child
+      sub-surfaces are synchronized, too, without explicitly setting them.
+      Destroying a sub-surface takes effect immediately. If you need to
+      synchronize the removal of a sub-surface to the parent surface update,
+      unmap the sub-surface first by attaching a NULL wl_buffer, update parent,
+      and then destroy the sub-surface.
+      If the parent wl_surface object is destroyed, the sub-surface is
+      unmapped.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="remove sub-surface interface">
+        The sub-surface interface is removed from the wl_surface object
+        that was turned into a sub-surface with a
+        wl_subcompositor.get_subsurface request. The wl_surface's association
+        to the parent is deleted. The wl_surface is unmapped immediately.
+      </description>
+    </request>
+    <enum name="error">
+      <entry name="bad_surface" value="0"
+             summary="wl_surface is not a sibling or the parent"/>
+    </enum>
+    <request name="set_position">
+      <description summary="reposition the sub-surface">
+        This schedules a sub-surface position change.
+        The sub-surface will be moved so that its origin (top left
+        corner pixel) will be at the location x, y of the parent surface
+        coordinate system. The coordinates are not restricted to the parent
+        surface area. Negative values are allowed.
+        The scheduled coordinates will take effect whenever the state of the
+        parent surface is applied. When this happens depends on whether the
+        parent surface is in synchronized mode or not. See
+        wl_subsurface.set_sync and wl_subsurface.set_desync for details.
+        If more than one set_position request is invoked by the client before
+        the commit of the parent surface, the position of a new request always
+        replaces the scheduled position from any previous request.
+        The initial position is 0, 0.
+      </description>
+      <arg name="x" type="int" summary="x coordinate in the parent surface"/>
+      <arg name="y" type="int" summary="y coordinate in the parent surface"/>
+    </request>
+    <request name="place_above">
+      <description summary="restack the sub-surface">
+        This sub-surface is taken from the stack, and put back just
+        above the reference surface, changing the z-order of the sub-surfaces.
+        The reference surface must be one of the sibling surfaces, or the
+        parent surface. Using any other surface, including this sub-surface,
+        will cause a protocol error.
+        The z-order is double-buffered. Requests are handled in order and
+        applied immediately to a pending state. The final pending state is
+        copied to the active state the next time the state of the parent
+        surface is applied. When this happens depends on whether the parent
+        surface is in synchronized mode or not. See wl_subsurface.set_sync and
+        wl_subsurface.set_desync for details.
+        A new sub-surface is initially added as the top-most in the stack
+        of its siblings and parent.
+      </description>
+      <arg name="sibling" type="object" interface="wl_surface"
+           summary="the reference surface"/>
+    </request>
+    <request name="place_below">
+      <description summary="restack the sub-surface">
+        The sub-surface is placed just below the reference surface.
+        See wl_subsurface.place_above.
+      </description>
+      <arg name="sibling" type="object" interface="wl_surface"
+           summary="the reference surface"/>
+    </request>
+    <request name="set_sync">
+      <description summary="set sub-surface to synchronized mode">
+        Change the commit behaviour of the sub-surface to synchronized
+        mode, also described as the parent dependent mode.
+        In synchronized mode, wl_surface.commit on a sub-surface will
+        accumulate the committed state in a cache, but the state will
+        not be applied and hence will not change the compositor output.
+        The cached state is applied to the sub-surface immediately after
+        the parent surface's state is applied. This ensures atomic
+        updates of the parent and all its synchronized sub-surfaces.
+        Applying the cached state will invalidate the cache, so further
+        parent surface commits do not (re-)apply old state.
+        See wl_subsurface for the recursive effect of this mode.
+      </description>
+    </request>
+    <request name="set_desync">
+      <description summary="set sub-surface to desynchronized mode">
+        Change the commit behaviour of the sub-surface to desynchronized
+        mode, also described as independent or freely running mode.
+        In desynchronized mode, wl_surface.commit on a sub-surface will
+        apply the pending state directly, without caching, as happens
+        normally with a wl_surface. Calling wl_surface.commit on the
+        parent surface has no effect on the sub-surface's wl_surface
+        state. This mode allows a sub-surface to be updated on its own.
+        If cached state exists when wl_surface.commit is called in
+        desynchronized mode, the pending state is added to the cached
+        state, and applied as a whole. This invalidates the cache.
+        Note: even if a sub-surface is set to desynchronized, a parent
+        sub-surface may override it to behave as synchronized. For details,
+        see wl_subsurface.
+        If a surface's parent surface behaves as desynchronized, then
+        the cached state is applied on set_desync.
+      </description>
+    </request>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/xdg-activation-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-activation-v1.xml
new file mode 100644
index 0000000..d87e633
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-activation-v1.xml
@@ -0,0 +1,186 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_activation_v1">
+  <copyright>
+    Copyright © 2020 Aleix Pol Gonzalez &lt;aleixpol@kde.org&gt;
+    Copyright © 2020 Carlos Garnacho &lt;carlosg@gnome.org&gt;
+    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 requesting activation of surfaces">
+    The way for a client to pass focus to another toplevel is as follows.
+    The client that intends to activate another toplevel uses the
+    xdg_activation_v1.get_activation_token request to get an activation token.
+    This token is then passed to the client to be activated through a separate
+    band of communication. The client to be activated will then pass the token
+    it received to the xdg_activation_v1.activate request. The compositor can
+    then use this token to decide how to react to the activation request.
+    The token the activating client gets may be ineffective either already at
+    the time it receives it, for example if it was not focused, for focus
+    stealing prevention. The activating client will have no way to discover
+    the validity of the token, and may still forward it to the to be activated
+    client.
+    The created activation token may optionally get information attached to it
+    that can be used by the compositor to identify the application that we
+    intend to activate. This can for example be used to display a visual hint
+    about what application is being started.
+    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_activation_v1" version="1">
+    <description summary="interface for activating surfaces">
+      A global interface used for informing the compositor about applications
+      being activated or started, or for applications to request to be
+      activated.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the xdg_activation object">
+        Notify the compositor that the xdg_activation object will no longer be
+        used.
+        The child objects created via this interface are unaffected and should
+        be destroyed separately.
+      </description>
+    </request>
+    <request name="get_activation_token">
+      <description summary="requests a token">
+        Creates an xdg_activation_token_v1 object that will provide
+        the initiating client with a unique token for this activation. This
+        token should be offered to the clients to be activated.
+      </description>
+      <arg name="id" type="new_id" interface="xdg_activation_token_v1"/>
+    </request>
+    <request name="activate">
+      <description summary="notify new interaction being available">
+        Requests surface activation. It's up to the compositor to display
+        this information as desired, for example by placing the surface above
+        the rest.
+        The compositor may know who requested this by checking the activation
+        token and might decide not to follow through with the activation if it's
+        considered unwanted.
+        Compositors can ignore unknown presentation tokens when an invalid
+        token is passed.
+      </description>
+      <arg name="token" type="string" summary="the activation token of the initiating client"/>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="the wl_surface to activate"/>
+    </request>
+  </interface>
+  <interface name="xdg_activation_token_v1" version="1">
+    <description summary="an exported activation handle">
+      An object for setting up a token and receiving a token handle that can
+      be passed as an activation token to another client.
+      The object is created using the xdg_activation_v1.get_activation_token
+      request. This object should then be populated with the app_id, surface
+      and serial information and committed. The compositor shall then issue a
+      done event with the token. In case the request's parameters are invalid,
+      the compositor will provide an invalid token.
+    </description>
+    <enum name="error">
+      <entry name="already_used" value="0"
+             summary="The token has already been used previously"/>
+    </enum>
+    <request name="set_serial">
+      <description summary="specifies the seat and serial of the activating event">
+        Provides information about the seat and serial event that requested the
+        token.
+        Must be sent before commit. This information is optional.
+      </description>
+      <arg name="serial" type="uint"
+           summary="the serial of the event that triggered the activation"/>
+      <arg name="seat" type="object" interface="wl_seat"
+           summary="the wl_seat of the event"/>
+    </request>
+    <request name="set_app_id">
+      <description summary="specifies the application being activated">
+        The requesting client can specify an app_id to associate the token
+        being created with it.
+        Must be sent before commit. This information is optional.
+      </description>
+      <arg name="app_id" type="string"
+           summary="the application id of the client being activated."/>
+    </request>
+    <request name="set_surface">
+      <description summary="specifies the application being activated">
+        The requesting client can specify a surface to associate the token
+        being created with it.
+        Must be triggered before commit. This information is optional.
+      </description>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="the requesting surface"/>
+    </request>
+    <request name="commit">
+      <description summary="issues the token request">
+        Requests an activation token based on the different parameters that
+        have been offered through set_serial, set_surface and set_app_id.
+      </description>
+    </request>
+    <event name="done">
+      <description summary="the exported activation token">
+        The 'done' event contains the unique token of this activation request
+        and notifies that the provider is done.
+        Applications will typically receive the token through the
+        XDG_ACTIVATION_TOKEN environment variable as set by its launcher, and
+        should unset the environment variable right after this request, in
+        order to avoid propagating it to child processes.
+        Applications implementing the D-Bus interface org.freedesktop.Application
+        should get their token under XDG_ACTIVATION_TOKEN on their platform_data.
+        Presentation tokens may be transferred across clients through means not
+        described in this protocol.
+      </description>
+      <arg name="token" type="string" summary="the exported activation token"/>
+    </event>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the xdg_activation_token_v1 object">
+        Notify the compositor that the xdg_activation_token_v1 object will no
+        longer be used.
+      </description>
+    </request>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/xdg-decoration-unstable-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-decoration-unstable-v1.xml
new file mode 100644
index 0000000..378e8ff
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-decoration-unstable-v1.xml
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_decoration_unstable_v1">
+  <copyright>
+    Copyright © 2018 Simon Ser
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+  <interface name="zxdg_decoration_manager_v1" version="1">
+    <description summary="window decoration manager">
+      This interface allows a compositor to announce support for server-side
+      decorations.
+      A window decoration is a set of window controls as deemed appropriate by
+      the party managing them, such as user interface components used to move,
+      resize and change a window's state.
+      A client can use this protocol to request being decorated by a supporting
+      compositor.
+      If compositor and client do not negotiate the use of a server-side
+      decoration using this protocol, clients continue to self-decorate as they
+      see fit.
+      Warning! The protocol described in this file is experimental and
+      backward incompatible changes may be made. Backward compatible changes
+      may be added together with the corresponding interface version bump.
+      Backward incompatible changes are done by bumping the version number in
+      the protocol and interface names and resetting the interface version.
+      Once the protocol is to be declared stable, the 'z' prefix and the
+      version number in the protocol and interface names are removed and the
+      interface version number is reset.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the decoration manager object">
+        Destroy the decoration manager. This doesn't destroy objects created
+        with the manager.
+      </description>
+    </request>
+    <request name="get_toplevel_decoration">
+      <description summary="create a new toplevel decoration object">
+        Create a new decoration object associated with the given toplevel.
+        Creating an xdg_toplevel_decoration from an xdg_toplevel which has a
+        buffer attached or committed is a client error, and any attempts by a
+        client to attach or manipulate a buffer prior to the first
+        xdg_toplevel_decoration.configure event must also be treated as
+        errors.
+      </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="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
+      another mode.
+      The xdg_toplevel_decoration object must be destroyed before its
+      xdg_toplevel.
+    </description>
+    <enum name="error">
+      <entry name="unconfigured_buffer" value="0"
+        summary="xdg_toplevel has a buffer attached before configure"/>
+      <entry name="already_constructed" value="1"
+        summary="xdg_toplevel already has a decoration object"/>
+      <entry name="orphaned" value="2"
+        summary="xdg_toplevel destroyed before the decoration object"/>
+    </enum>
+    <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.
+      </description>
+    </request>
+    <enum name="mode">
+      <description summary="window decoration modes">
+        These values describe window decoration modes.
+      </description>
+      <entry name="client_side" value="1"
+        summary="no server-side window decoration"/>
+      <entry name="server_side" value="2"
+        summary="server-side window decoration"/>
+    </enum>
+    <request name="set_mode">
+      <description summary="set the decoration mode">
+        Set the toplevel surface decoration mode. This informs the compositor
+        that the client prefers the provided decoration mode.
+        After requesting a decoration mode, the compositor will respond by
+        emitting a xdg_surface.configure event. The client should then update
+        its content, drawing it without decorations if the received mode is
+        server-side decorations. The client must also acknowledge the configure
+        when committing the new content (see xdg_surface.ack_configure).
+        The compositor can decide not to use the client's mode and enforce a
+        different mode instead.
+        Clients whose decoration mode depend on the xdg_toplevel state may send
+        a set_mode request in response to a xdg_surface.configure event and wait
+        for the next xdg_surface.configure event to prevent unwanted state.
+        Such clients are responsible for preventing configure loops and must
+        make sure not to send multiple successive set_mode requests with the
+        same decoration mode.
+      </description>
+      <arg name="mode" type="uint" enum="mode" summary="the decoration mode"/>
+    </request>
+    <request name="unset_mode">
+      <description summary="unset the decoration mode">
+        Unset the toplevel surface decoration mode. This informs the compositor
+        that the client doesn't prefer a particular decoration mode.
+        This request has the same semantics as set_mode.
+      </description>
+    </request>
+    <event name="configure">
+      <description summary="suggest a surface change">
+        The configure event asks the client to change its decoration mode. The
+        configured state should not be applied immediately. Clients must send an
+        ack_configure in response to this event. See xdg_surface.configure and
+        xdg_surface.ack_configure for details.
+        A configure event can be sent at any time. The specified mode must be
+        obeyed by the client.
+      </description>
+      <arg name="mode" type="uint" enum="mode" summary="the decoration mode"/>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/xdg-dialog-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-dialog-v1.xml
new file mode 100644
index 0000000..fb3fc14
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-dialog-v1.xml
@@ -0,0 +1,110 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_dialog_v1">
+  <copyright>
+    Copyright © 2023 Carlos Garnacho
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+  <interface name="xdg_wm_dialog_v1" version="1">
+    <description summary="create dialogs related to other toplevels">
+      The xdg_wm_dialog_v1 interface is exposed as a global object allowing
+      to register surfaces with a xdg_toplevel role as "dialogs" relative to
+      another toplevel.
+      The compositor may let this relation influence how the surface is
+      placed, displayed or interacted with.
+      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>
+    <enum name="error">
+      <entry name="already_used" value="0"
+             summary="the xdg_toplevel object has already been used to create a xdg_dialog_v1"/>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the dialog manager object">
+        Destroys the xdg_wm_dialog_v1 object. This does not affect
+        the xdg_dialog_v1 objects generated through it.
+      </description>
+    </request>
+    <request name="get_xdg_dialog">
+      <description summary="create a dialog object">
+        Creates a xdg_dialog_v1 object for the given toplevel. See the interface
+        description for more details.
+        Compositors must raise an already_used error if clients attempt to
+        create multiple xdg_dialog_v1 objects for the same xdg_toplevel.
+      </description>
+      <arg name="id" type="new_id" interface="xdg_dialog_v1"/>
+      <arg name="toplevel" type="object" interface="xdg_toplevel"/>
+    </request>
+  </interface>
+  <interface name="xdg_dialog_v1" version="1">
+    <description summary="dialog object">
+      A xdg_dialog_v1 object is an ancillary object tied to a xdg_toplevel. Its
+      purpose is hinting the compositor that the toplevel is a "dialog" (e.g. a
+      temporary window) relative to another toplevel (see
+      xdg_toplevel.set_parent). If the xdg_toplevel is destroyed, the xdg_dialog_v1
+      becomes inert.
+      Through this object, the client may provide additional hints about
+      the purpose of the secondary toplevel. This interface has no effect
+      on toplevels that are not attached to a parent toplevel.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the dialog object">
+        Destroys the xdg_dialog_v1 object. If this object is destroyed
+        before the related xdg_toplevel, the compositor should unapply its
+        effects.
+      </description>
+    </request>
+    <request name="set_modal">
+      <description summary="mark dialog as modal">
+        Hints that the dialog has "modal" behavior. Modal dialogs typically
+        require to be fully addressed by the user (i.e. closed) before resuming
+        interaction with the parent toplevel, and may require a distinct
+        presentation.
+        Clients must implement the logic to filter events in the parent
+        toplevel on their own.
+        Compositors may choose any policy in event delivery to the parent
+        toplevel, from delivering all events unfiltered to using them for
+        internal consumption.
+      </description>
+    </request>
+    <request name="unset_modal">
+      <description summary="mark dialog as not modal">
+        Drops the hint that this dialog has "modal" behavior. See
+        xdg_dialog_v1.set_modal for more details.
+      </description>
+    </request>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/xdg-foreign-unstable-v2.xml b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-foreign-unstable-v2.xml
new file mode 100644
index 0000000..cc3271d
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-foreign-unstable-v2.xml
@@ -0,0 +1,200 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_foreign_unstable_v2">
+  <copyright>
+    Copyright © 2015-2016 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 exporting xdg surface handles">
+    This protocol specifies a way for making it possible to reference a surface
+    of a different client. With such a reference, a client can, by using the
+    interfaces provided by this protocol, manipulate the relationship between
+    its own surfaces and the surface of some other client. For example, stack
+    some of its own surface above the other clients surface.
+    In order for a client A to get a reference of a surface of client B, client
+    B must first export its surface using xdg_exporter.export_toplevel. Upon
+    doing this, client B will receive a handle (a unique string) that it may
+    share with client A in some way (for example D-Bus). After client A has
+    received the handle from client B, it may use xdg_importer.import_toplevel
+    to create a reference to the surface client B just exported. See the
+    corresponding requests for details.
+    A possible use case for this is out-of-process dialogs. For example when a
+    sandboxed client without file system access needs the user to select a file
+    on the file system, given sandbox environment support, it can export its
+    surface, passing the exported surface handle to an unsandboxed process that
+    can show a file browser dialog and stack it above the sandboxed client's
+    surface.
+    Warning! The protocol described in this file is experimental and backward
+    incompatible changes may be made. Backward compatible changes may be added
+    together with the corresponding interface version bump. Backward
+    incompatible changes are done by bumping the version number in the protocol
+    and interface names and resetting the interface version. Once the protocol
+    is to be declared stable, the 'z' prefix and the version number in the
+    protocol and interface names are removed and the interface version number is
+    reset.
+  </description>
+  <interface name="zxdg_exporter_v2" version="1">
+    <description summary="interface for exporting surfaces">
+      A global interface used for exporting surfaces that can later be imported
+      using xdg_importer.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the xdg_exporter object">
+        Notify the compositor that the xdg_exporter object will no longer be
+        used.
+      </description>
+    </request>
+    <enum name="error">
+      <description summary="error values">
+        These errors can be emitted in response to invalid xdg_exporter
+        requests.
+      </description>
+      <entry name="invalid_surface" value="0" summary="surface is not an xdg_toplevel"/>
+    </enum>
+    <request name="export_toplevel">
+      <description summary="export a toplevel surface">
+        The export_toplevel request exports the passed surface so that it can later be
+        imported via xdg_importer. When called, a new xdg_exported object will
+        be created and xdg_exported.handle will be sent immediately. See the
+        corresponding interface and event for details.
+        A surface may be exported multiple times, and each exported handle may
+        be used to create an xdg_imported multiple times. Only xdg_toplevel
+        equivalent surfaces may be exported, otherwise an invalid_surface
+        protocol error is sent.
+      </description>
+      <arg name="id" type="new_id" interface="zxdg_exported_v2"
+           summary="the new xdg_exported object"/>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="the surface to export"/>
+    </request>
+  </interface>
+  <interface name="zxdg_importer_v2" version="1">
+    <description summary="interface for importing surfaces">
+      A global interface used for importing surfaces exported by xdg_exporter.
+      With this interface, a client can create a reference to a surface of
+      another client.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the xdg_importer object">
+        Notify the compositor that the xdg_importer object will no longer be
+        used.
+      </description>
+    </request>
+    <request name="import_toplevel">
+      <description summary="import a toplevel surface">
+        The import_toplevel request imports a surface from any client given a handle
+        retrieved by exporting said surface using xdg_exporter.export_toplevel.
+        When called, a new xdg_imported object will be created. This new object
+        represents the imported surface, and the importing client can
+        manipulate its relationship using it. See xdg_imported for details.
+      </description>
+      <arg name="id" type="new_id" interface="zxdg_imported_v2"
+           summary="the new xdg_imported object"/>
+      <arg name="handle" type="string"
+           summary="the exported surface handle"/>
+    </request>
+  </interface>
+  <interface name="zxdg_exported_v2" version="1">
+    <description summary="an exported surface handle">
+      An xdg_exported object represents an exported reference to a surface. The
+      exported surface may be referenced as long as the xdg_exported object not
+      destroyed. Destroying the xdg_exported invalidates any relationship the
+      importer may have established using xdg_imported.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="unexport the exported surface">
+        Revoke the previously exported surface. This invalidates any
+        relationship the importer may have set up using the xdg_imported created
+        given the handle sent via xdg_exported.handle.
+      </description>
+    </request>
+    <event name="handle">
+      <description summary="the exported surface handle">
+        The handle event contains the unique handle of this exported surface
+        reference. It may be shared with any client, which then can use it to
+        import the surface by calling xdg_importer.import_toplevel. A handle
+        may be used to import the surface multiple times.
+      </description>
+      <arg name="handle" type="string" summary="the exported surface handle"/>
+    </event>
+  </interface>
+  <interface name="zxdg_imported_v2" version="1">
+    <description summary="an imported surface handle">
+      An xdg_imported object represents an imported reference to surface exported
+      by some client. A client can use this interface to manipulate
+      relationships between its own surfaces and the imported surface.
+    </description>
+    <enum name="error">
+      <description summary="error values">
+        These errors can be emitted in response to invalid xdg_imported
+        requests.
+      </description>
+      <entry name="invalid_surface" value="0" summary="surface is not an xdg_toplevel"/>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the xdg_imported object">
+        Notify the compositor that it will no longer use the xdg_imported
+        object. Any relationship that may have been set up will at this point
+        be invalidated.
+      </description>
+    </request>
+    <request name="set_parent_of">
+      <description summary="set as the parent of some surface">
+        Set the imported surface as the parent of some surface of the client.
+        The passed surface must be an xdg_toplevel equivalent, otherwise an
+        invalid_surface protocol error is sent. Calling this function sets up
+        a surface to surface relation with the same stacking and positioning
+        semantics as xdg_toplevel.set_parent.
+      </description>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="the child surface"/>
+    </request>
+    <event name="destroyed">
+      <description summary="the imported surface handle has been destroyed">
+        The imported surface handle has been destroyed and any relationship set
+        up has been invalidated. This may happen for various reasons, for
+        example if the exported surface or the exported surface handle has been
+        destroyed, if the handle used for importing was invalid.
+      </description>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/xdg-output-unstable-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-output-unstable-v1.xml
new file mode 100644
index 0000000..9a5b790
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-output-unstable-v1.xml
@@ -0,0 +1,220 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_output_unstable_v1">
+  <copyright>
+    Copyright © 2017 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 to describe output regions">
+    This protocol aims at describing outputs in a way which is more in line
+    with the concept of an output on desktop oriented systems.
+    Some information are more specific to the concept of an output for
+    a desktop oriented system and may not make sense in other applications,
+    such as IVI systems for example.
+    Typically, the global compositor space on a desktop system is made of
+    a contiguous or overlapping set of rectangular regions.
+    Some of the information provided in this protocol might be identical
+    to their counterparts already available from wl_output, in which case
+    the information provided by this protocol should be preferred to their
+    equivalent in wl_output. The goal is to move the desktop specific
+    concepts (such as output location within the global compositor space,
+    the connector name and types, etc.) out of the core wl_output protocol.
+    Warning! The protocol described in this file is experimental and
+    backward incompatible changes may be made. Backward compatible
+    changes may be added together with the corresponding interface
+    version bump.
+    Backward incompatible changes are done by bumping the version
+    number in the protocol and interface names and resetting the
+    interface version. Once the protocol is to be declared stable,
+    the 'z' prefix and the version number in the protocol and
+    interface names are removed and the interface version number is
+    reset.
+  </description>
+  <interface name="zxdg_output_manager_v1" version="3">
+    <description summary="manage xdg_output objects">
+      A global factory interface for xdg_output objects.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the xdg_output_manager object">
+        Using this request a client can tell the server that it is not
+        going to use the xdg_output_manager object anymore.
+        Any objects already created through this instance are not affected.
+      </description>
+    </request>
+    <request name="get_xdg_output">
+      <description summary="create an xdg output from a wl_output">
+        This creates a new xdg_output object for the given wl_output.
+      </description>
+      <arg name="id" type="new_id" interface="zxdg_output_v1"/>
+      <arg name="output" type="object" interface="wl_output"/>
+    </request>
+  </interface>
+  <interface name="zxdg_output_v1" version="3">
+    <description summary="compositor logical output region">
+      An xdg_output describes part of the compositor geometry.
+      This typically corresponds to a monitor that displays part of the
+      compositor space.
+      For objects version 3 onwards, after all xdg_output properties have been
+      sent (when the object is created and when properties are updated), a
+      wl_output.done event is sent. This allows changes to the output
+      properties to be seen as atomic, even if they happen via multiple events.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the xdg_output object">
+        Using this request a client can tell the server that it is not
+        going to use the xdg_output object anymore.
+      </description>
+    </request>
+    <event name="logical_position">
+      <description summary="position of the output within the global compositor space">
+        The position event describes the location of the wl_output within
+        the global compositor space.
+        The logical_position event is sent after creating an xdg_output
+        (see xdg_output_manager.get_xdg_output) and whenever the location
+        of the output changes within the global compositor space.
+      </description>
+      <arg name="x" type="int"
+           summary="x position within the global compositor space"/>
+      <arg name="y" type="int"
+           summary="y position within the global compositor space"/>
+    </event>
+    <event name="logical_size">
+      <description summary="size of the output in the global compositor space">
+        The logical_size event describes the size of the output in the
+        global compositor space.
+        For example, a surface without any buffer scale, transformation
+        nor rotation set, with the size matching the logical_size will
+        have the same size as the corresponding output when displayed.
+        Most regular Wayland clients should not pay attention to the
+        logical size and would rather rely on xdg_shell interfaces.
+        Some clients such as Xwayland, however, need this to configure
+        their surfaces in the global compositor space as the compositor
+        may apply a different scale from what is advertised by the output
+        scaling property (to achieve fractional scaling, for example).
+        For example, for a wl_output mode 3840×2160 and a scale factor 2:
+        - A compositor not scaling the surface buffers will advertise a
+          logical size of 3840×2160,
+        - A compositor automatically scaling the surface buffers will
+          advertise a logical size of 1920×1080,
+        - A compositor using a fractional scale of 1.5 will advertise a
+          logical size of 2560×1440.
+        For example, for a wl_output mode 1920×1080 and a 90 degree rotation,
+        the compositor will advertise a logical size of 1080x1920.
+        The logical_size event is sent after creating an xdg_output
+        (see xdg_output_manager.get_xdg_output) and whenever the logical
+        size of the output changes, either as a result of a change in the
+        applied scale or because of a change in the corresponding output
+        mode(see wl_output.mode) or transform (see wl_output.transform).
+      </description>
+      <arg name="width" type="int"
+           summary="width in global compositor space"/>
+      <arg name="height" type="int"
+           summary="height in global compositor space"/>
+    </event>
+    <event name="done">
+      <description summary="all information about the output have been sent">
+        This event is sent after all other properties of an xdg_output
+        have been sent.
+        This allows changes to the xdg_output properties to be seen as
+        atomic, even if they happen via multiple events.
+        For objects version 3 onwards, this event is deprecated. Compositors
+        are not required to send it anymore and must send wl_output.done
+        instead.
+      </description>
+    </event>
+    <!-- Version 2 additions -->
+    <event name="name" since="2">
+      <description summary="name of this output">
+        Many compositors will assign names to their outputs, show them to the
+        user, allow them to be configured by name, etc. The client may wish to
+        know this name as well to offer the user similar behaviors.
+        The naming convention is compositor defined, but limited to
+        alphanumeric characters and dashes (-). Each name is unique among all
+        wl_output globals, but if a wl_output global is destroyed the same name
+        may be reused later. The names will also remain consistent across
+        sessions with the same hardware and software configuration.
+        Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do
+        not assume that the name is a reflection of an underlying DRM
+        connector, X11 connection, etc.
+        The name event is sent after creating an xdg_output (see
+        xdg_output_manager.get_xdg_output). This event is only sent once per
+        xdg_output, and the name does not change over the lifetime of the
+        wl_output global.
+      </description>
+      <arg name="name" type="string" summary="output name"/>
+    </event>
+    <event name="description" since="2">
+      <description summary="human-readable description of this output">
+        Many compositors can produce human-readable descriptions of their
+        outputs.  The client may wish to know this description as well, to
+        communicate the user for various purposes.
+        The description is a UTF-8 string with no convention defined for its
+        contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11
+        output via :1'.
+        The description event is sent after creating an xdg_output (see
+        xdg_output_manager.get_xdg_output) and whenever the description
+        changes. The description is optional, and may not be sent at all.
+        For objects of version 2 and lower, this event is only sent once per
+        xdg_output, and the description does not change over the lifetime of
+        the wl_output global.
+      </description>
+      <arg name="description" type="string" summary="output description"/>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/xdg-shell.xml b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-shell.xml
new file mode 100644
index 0000000..777eaa7
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-shell.xml
@@ -0,0 +1,1370 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_shell">
+  <copyright>
+    Copyright © 2008-2013 Kristian Høgsberg
+    Copyright © 2013      Rafael Antognolli
+    Copyright © 2013      Jasper St. Pierre
+    Copyright © 2010-2013 Intel Corporation
+    Copyright © 2015-2017 Samsung Electronics Co., Ltd
+    Copyright © 2015-2017 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>
+  <interface name="xdg_wm_base" version="6">
+    <description summary="create desktop-style surfaces">
+      The xdg_wm_base interface is exposed as a global object enabling clients
+      to turn their wl_surfaces into windows in a desktop environment. It
+      defines the basic functionality needed for clients and the compositor to
+      create windows that can be dragged, resized, maximized, etc, as well as
+      creating transient windows such as popup menus.
+    </description>
+    <enum name="error">
+      <entry name="role" value="0" summary="given wl_surface has another role"/>
+      <entry name="defunct_surfaces" value="1"
+             summary="xdg_wm_base was destroyed before children"/>
+      <entry name="not_the_topmost_popup" value="2"
+             summary="the client tried to map or destroy a non-topmost popup"/>
+      <entry name="invalid_popup_parent" value="3"
+             summary="the client specified an invalid popup parent surface"/>
+      <entry name="invalid_surface_state" value="4"
+             summary="the client provided an invalid surface state"/>
+      <entry name="invalid_positioner" value="5"
+             summary="the client provided an invalid positioner"/>
+      <entry name="unresponsive" value="6"
+             summary="the client didn’t respond to a ping event in time"/>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="destroy xdg_wm_base">
+        Destroy this xdg_wm_base object.
+        Destroying a bound xdg_wm_base object while there are surfaces
+        still alive created by this xdg_wm_base object instance is illegal
+        and will result in a defunct_surfaces error.
+      </description>
+    </request>
+    <request name="create_positioner">
+      <description summary="create a positioner object">
+        Create a positioner object. A positioner object is used to position
+        surfaces relative to some parent surface. See the interface description
+        and xdg_surface.get_popup for details.
+      </description>
+      <arg name="id" type="new_id" interface="xdg_positioner"/>
+    </request>
+    <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.
+        See the documentation of xdg_surface for more details about what an
+        xdg_surface is and how it is used.
+      </description>
+      <arg name="id" type="new_id" interface="xdg_surface"/>
+      <arg name="surface" type="object" interface="wl_surface"/>
+    </request>
+    <request name="pong">
+      <description summary="respond to a ping event">
+        A client must respond to a ping event with a pong request or
+        the client may be deemed unresponsive. See xdg_wm_base.ping
+        and xdg_wm_base.error.unresponsive.
+      </description>
+      <arg name="serial" type="uint" summary="serial of the ping event"/>
+    </request>
+    <event name="ping">
+      <description summary="check if the client is alive">
+        The ping event asks the client if it's still alive. Pass the
+        serial specified in the event back to the compositor by sending
+        a "pong" request back with the specified serial. See xdg_wm_base.pong.
+        Compositors can use this to determine if the client is still
+        alive. It's unspecified what will happen if the client doesn't
+        respond to the ping request, or in what timeframe. Clients should
+        try to respond in a reasonable amount of time. The “unresponsive”
+        error is provided for compositors that wish to disconnect unresponsive
+        clients.
+        A compositor is free to ping in any way it wants, but a client must
+        always respond to any xdg_wm_base object it created.
+      </description>
+      <arg name="serial" type="uint" summary="pass this to the pong request"/>
+    </event>
+  </interface>
+  <interface name="xdg_positioner" version="6">
+    <description summary="child surface positioner">
+      The xdg_positioner provides a collection of rules for the placement of a
+      child surface relative to a parent surface. Rules can be defined to ensure
+      the child surface remains within the visible area's borders, and to
+      specify how the child surface changes its position, such as sliding along
+      an axis, or flipping around a rectangle. These positioner-created rules are
+      constrained by the requirement that a child surface must intersect with or
+      be at least partially adjacent to its parent surface.
+      See the various requests for details about possible rules.
+      At the time of the request, the compositor makes a copy of the rules
+      specified by the xdg_positioner. Thus, after the request is complete the
+      xdg_positioner object can be destroyed or reused; further changes to the
+      object will have no effect on previous usages.
+      For an xdg_positioner object to be considered complete, it must have a
+      non-zero size set by set_size, and a non-zero anchor rectangle set by
+      set_anchor_rect. Passing an incomplete xdg_positioner object when
+      positioning a surface raises an invalid_positioner error.
+    </description>
+    <enum name="error">
+      <entry name="invalid_input" value="0" summary="invalid input provided"/>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the xdg_positioner object">
+        Notify the compositor that the xdg_positioner will no longer be used.
+      </description>
+    </request>
+    <request name="set_size">
+      <description summary="set the size of the to-be positioned rectangle">
+        Set the size of the surface that is to be positioned with the positioner
+        object. The size is in surface-local coordinates and corresponds to the
+        window geometry. See xdg_surface.set_window_geometry.
+        If a zero or negative size is set the invalid_input error is raised.
+      </description>
+      <arg name="width" type="int" summary="width of positioned rectangle"/>
+      <arg name="height" type="int" summary="height of positioned rectangle"/>
+    </request>
+    <request name="set_anchor_rect">
+      <description summary="set the anchor rectangle within the parent surface">
+        Specify the anchor rectangle within the parent surface that the child
+        surface will be placed relative to. The rectangle is relative to the
+        window geometry as defined by xdg_surface.set_window_geometry of the
+        parent surface.
+        When the xdg_positioner object is used to position a child surface, the
+        anchor rectangle may not extend outside the window geometry of the
+        positioned child's parent surface.
+        If a negative size is set the invalid_input error is raised.
+      </description>
+      <arg name="x" type="int" summary="x position of anchor rectangle"/>
+      <arg name="y" type="int" summary="y position of anchor rectangle"/>
+      <arg name="width" type="int" summary="width of anchor rectangle"/>
+      <arg name="height" type="int" summary="height of anchor rectangle"/>
+    </request>
+    <enum name="anchor">
+      <entry name="none" value="0"/>
+      <entry name="top" value="1"/>
+      <entry name="bottom" value="2"/>
+      <entry name="left" value="3"/>
+      <entry name="right" value="4"/>
+      <entry name="top_left" value="5"/>
+      <entry name="bottom_left" value="6"/>
+      <entry name="top_right" value="7"/>
+      <entry name="bottom_right" value="8"/>
+    </enum>
+    <request name="set_anchor">
+      <description summary="set anchor rectangle anchor">
+        Defines the anchor point for the anchor rectangle. The specified anchor
+        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"/>
+    </request>
+    <enum name="gravity">
+      <entry name="none" value="0"/>
+      <entry name="top" value="1"/>
+      <entry name="bottom" value="2"/>
+      <entry name="left" value="3"/>
+      <entry name="right" value="4"/>
+      <entry name="top_left" value="5"/>
+      <entry name="bottom_left" value="6"/>
+      <entry name="top_right" value="7"/>
+      <entry name="bottom_right" value="8"/>
+    </enum>
+    <request name="set_gravity">
+      <description summary="set child surface gravity">
+        Defines in what direction a surface should be positioned, relative to
+        the anchor point of the parent surface. If a corner gravity is
+        specified (e.g. 'bottom_right' or 'top_left'), then the child surface
+        will be placed towards the specified gravity; otherwise, the child
+        surface will be centered over the anchor point on any axis that had no
+        gravity specified. If the gravity is not in the ‘gravity’ enum, an
+        invalid_input error is raised.
+      </description>
+      <arg name="gravity" type="uint" enum="gravity"
+           summary="gravity direction"/>
+    </request>
+    <enum name="constraint_adjustment" bitfield="true">
+      <description summary="constraint adjustments">
+        The constraint adjustment value define ways the compositor will adjust
+        the position of the surface, if the unadjusted position would result
+        in the surface being partly constrained.
+        Whether a surface is considered 'constrained' is left to the compositor
+        to determine. For example, the surface may be partly outside the
+        compositor's defined 'work area', thus necessitating the child surface's
+        position be adjusted until it is entirely inside the work area.
+        The adjustments can be combined, according to a defined precedence: 1)
+        Flip, 2) Slide, 3) Resize.
+      </description>
+      <entry name="none" value="0">
+        <description summary="don't move the child surface when constrained">
+          Don't alter the surface position even if it is constrained on some
+          axis, for example partially outside the edge of an output.
+        </description>
+      </entry>
+      <entry name="slide_x" value="1">
+        <description summary="move along the x axis until unconstrained">
+          Slide the surface along the x axis until it is no longer constrained.
+          First try to slide towards the direction of the gravity on the x axis
+          until either the edge in the opposite direction of the gravity is
+          unconstrained or the edge in the direction of the gravity is
+          constrained.
+          Then try to slide towards the opposite direction of the gravity on the
+          x axis until either the edge in the direction of the gravity is
+          unconstrained or the edge in the opposite direction of the gravity is
+          constrained.
+        </description>
+      </entry>
+      <entry name="slide_y" value="2">
+        <description summary="move along the y axis until unconstrained">
+          Slide the surface along the y axis until it is no longer constrained.
+          First try to slide towards the direction of the gravity on the y axis
+          until either the edge in the opposite direction of the gravity is
+          unconstrained or the edge in the direction of the gravity is
+          constrained.
+          Then try to slide towards the opposite direction of the gravity on the
+          y axis until either the edge in the direction of the gravity is
+          unconstrained or the edge in the opposite direction of the gravity is
+          constrained.
+        </description>
+      </entry>
+      <entry name="flip_x" value="4">
+        <description summary="invert the anchor and gravity on the x axis">
+          Invert the anchor and gravity on the x axis if the surface is
+          constrained on the x axis. For example, if the left edge of the
+          surface is constrained, the gravity is 'left' and the anchor is
+          'left', change the gravity to 'right' and the anchor to 'right'.
+          If the adjusted position also ends up being constrained, the resulting
+          position of the flip_x adjustment will be the one before the
+          adjustment.
+        </description>
+      </entry>
+      <entry name="flip_y" value="8">
+        <description summary="invert the anchor and gravity on the y axis">
+          Invert the anchor and gravity on the y axis if the surface is
+          constrained on the y axis. For example, if the bottom edge of the
+          surface is constrained, the gravity is 'bottom' and the anchor is
+          'bottom', change the gravity to 'top' and the anchor to 'top'.
+          The adjusted position is calculated given the original anchor
+          rectangle and offset, but with the new flipped anchor and gravity
+          values.
+          If the adjusted position also ends up being constrained, the resulting
+          position of the flip_y adjustment will be the one before the
+          adjustment.
+        </description>
+      </entry>
+      <entry name="resize_x" value="16">
+        <description summary="horizontally resize the surface">
+          Resize the surface horizontally so that it is completely
+          unconstrained.
+        </description>
+      </entry>
+      <entry name="resize_y" value="32">
+        <description summary="vertically resize the surface">
+          Resize the surface vertically so that it is completely unconstrained.
+        </description>
+      </entry>
+    </enum>
+    <request name="set_constraint_adjustment">
+      <description summary="set the adjustment to be done when constrained">
+        Specify how the window should be positioned if the originally intended
+        position caused the surface to be constrained, meaning at least
+        partially outside positioning boundaries set by the compositor. The
+        adjustment is set by constructing a bitmask describing the adjustment to
+        be made when the surface is constrained on that axis.
+        If no bit for one axis is set, the compositor will assume that the child
+        surface should not change its position on that axis when constrained.
+        If more than one bit for one axis is set, the order of how adjustments
+        are applied is specified in the corresponding adjustment descriptions.
+        The default adjustment is none.
+      </description>
+      <arg name="constraint_adjustment" type="uint"
+           summary="bit mask of constraint adjustments"/>
+    </request>
+    <request name="set_offset">
+      <description summary="set surface position offset">
+        Specify the surface position offset relative to the position of the
+        anchor on the anchor rectangle and the anchor on the surface. For
+        example if the anchor of the anchor rectangle is at (x, y), the surface
+        has the gravity bottom|right, and the offset is (ox, oy), the calculated
+        surface position will be (x + ox, y + oy). The offset position of the
+        surface is the one used for constraint testing. See
+        set_constraint_adjustment.
+        An example use case is placing a popup menu on top of a user interface
+        element, while aligning the user interface element of the parent surface
+        with some user interface element placed somewhere in the popup surface.
+      </description>
+      <arg name="x" type="int" summary="surface position x offset"/>
+      <arg name="y" type="int" summary="surface position y offset"/>
+    </request>
+    <!-- Version 3 additions -->
+    <request name="set_reactive" since="3">
+      <description summary="continuously reconstrain the surface">
+        When set reactive, the surface is reconstrained if the conditions used
+        for constraining changed, e.g. the parent window moved.
+        If the conditions changed and the popup was reconstrained, an
+        xdg_popup.configure event is sent with updated geometry, followed by an
+        xdg_surface.configure event.
+      </description>
+    </request>
+    <request name="set_parent_size" since="3">
+      <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
+        this doesn't match the dimension of the parent the popup is eventually
+        positioned against, the behavior is undefined.
+        The arguments are given in the surface-local coordinate space.
+      </description>
+      <arg name="parent_width" type="int"
+           summary="future window geometry width of parent"/>
+      <arg name="parent_height" type="int"
+           summary="future window geometry height of parent"/>
+    </request>
+    <request name="set_parent_configure" since="3">
+      <description summary="set parent configure this is a response to">
+        Set the serial of an xdg_surface.configure event this positioner will be
+        used in response to. The compositor may use this information together
+        with set_parent_size to determine what future state the popup should be
+        constrained using.
+      </description>
+      <arg name="serial" type="uint"
+           summary="serial of parent configure event"/>
+    </request>
+  </interface>
+  <interface name="xdg_surface" version="6">
+    <description summary="desktop user interface surface base interface">
+      An interface that may be implemented by a wl_surface, for
+      implementations that provide a desktop-style user interface.
+      It provides a base set of functionality required to construct user
+      interface elements requiring management by the compositor, such as
+      toplevel windows, menus, etc. The types of functionality are split into
+      xdg_surface roles.
+      Creating an xdg_surface does not set the role for a wl_surface. In order
+      to map an xdg_surface, the client must create a role-specific object
+      using, e.g., get_toplevel, get_popup. The wl_surface for any given
+      xdg_surface can have at most one role, and may not be assigned any role
+      not based on xdg_surface.
+      A role must be assigned before any other requests are made to the
+      xdg_surface object.
+      The client must call wl_surface.commit on the corresponding wl_surface
+      for the xdg_surface state to take effect.
+      Creating an xdg_surface from a wl_surface which has a buffer attached or
+      committed is a client error, and any attempts by a client to attach or
+      manipulate a buffer prior to the first xdg_surface.configure call must
+      also be treated as errors.
+      After creating a role-specific object and setting it up, the client must
+      perform an initial commit without any buffer attached. The compositor
+      will reply with initial wl_surface state such as
+      wl_surface.preferred_buffer_scale followed by an xdg_surface.configure
+      event. The client must acknowledge it and is then allowed to attach a
+      buffer to map the surface.
+      Mapping an xdg_surface-based role surface is defined as making it
+      possible for the surface to be shown by the compositor. Note that
+      a mapped surface is not guaranteed to be visible once it is mapped.
+      For an xdg_surface to be mapped by the compositor, the following
+      conditions must be met:
+      (1) the client has assigned an xdg_surface-based role to the surface
+      (2) the client has set and committed the xdg_surface state and the
+          role-dependent state to the surface
+      (3) the client has committed a buffer to the surface
+      A newly-unmapped surface is considered to have met condition (1) out
+      of the 3 required conditions for mapping a surface if its role surface
+      has not been destroyed, i.e. the client must perform the initial commit
+      again before attaching a buffer.
+    </description>
+    <enum name="error">
+      <entry name="not_constructed" value="1"
+             summary="Surface was not fully constructed"/>
+      <entry name="already_constructed" value="2"
+             summary="Surface was already constructed"/>
+      <entry name="unconfigured_buffer" value="3"
+             summary="Attaching a buffer to an unconfigured surface"/>
+      <entry name="invalid_serial" value="4"
+             summary="Invalid serial number when acking a configure event"/>
+      <entry name="invalid_size" value="5"
+             summary="Width or height was zero or negative"/>
+      <entry name="defunct_role_object" value="6"
+             summary="Surface was destroyed before its role object"/>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the xdg_surface">
+        Destroy the xdg_surface object. An xdg_surface must only be destroyed
+        after its role object has been destroyed, otherwise
+        a defunct_role_object error is raised.
+      </description>
+    </request>
+    <request name="get_toplevel">
+      <description summary="assign the xdg_toplevel surface role">
+        This creates an xdg_toplevel object for the given xdg_surface and gives
+        the associated wl_surface the xdg_toplevel role.
+        See the documentation of xdg_toplevel for more details about what an
+        xdg_toplevel is and how it is used.
+      </description>
+      <arg name="id" type="new_id" interface="xdg_toplevel"/>
+    </request>
+    <request name="get_popup">
+      <description summary="assign the xdg_popup surface role">
+        This creates an xdg_popup object for the given xdg_surface and gives
+        the associated wl_surface the xdg_popup role.
+        If null is passed as a parent, a parent surface must be specified using
+        some other protocol, before committing the initial state.
+        See the documentation of xdg_popup for more details about what an
+        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"/>
+      <arg name="positioner" type="object" interface="xdg_positioner"/>
+    </request>
+    <request name="set_window_geometry">
+      <description summary="set the new window geometry">
+        The window geometry of a surface is its "visible bounds" from the
+        user's perspective. Client-side decorations often have invisible
+        portions like drop-shadows which should be ignored for the
+        purposes of aligning, placing and constraining windows.
+        The window geometry is double buffered, and will be applied at the
+        time wl_surface.commit of the corresponding wl_surface is called.
+        When maintaining a position, the compositor should treat the (x, y)
+        coordinate of the window geometry as the top left corner of the window.
+        A client changing the (x, y) window geometry coordinate should in
+        general not alter the position of the window.
+        Once the window geometry of the surface is set, it is not possible to
+        unset it, and it will remain the same until set_window_geometry is
+        called again, even if a new subsurface or buffer is attached.
+        If never set, the value is the full bounds of the surface,
+        including any subsurfaces. This updates dynamically on every
+        commit. This unset is meant for extremely simple clients.
+        The arguments are given in the surface-local coordinate space of
+        the wl_surface associated with this xdg_surface, and may extend outside
+        of the wl_surface itself to mark parts of the subsurface tree as part of
+        the window geometry.
+        When applied, the effective window geometry will be the set window
+        geometry clamped to the bounding rectangle of the combined
+        geometry of the surface of the xdg_surface and the associated
+        subsurfaces.
+        The effective geometry will not be recalculated unless a new call to
+        set_window_geometry is done and the new pending surface state is
+        subsequently applied.
+        The width and height of the effective window geometry must be
+        greater than zero. Setting an invalid size will raise an
+        invalid_size error.
+      </description>
+      <arg name="x" type="int"/>
+      <arg name="y" type="int"/>
+      <arg name="width" type="int"/>
+      <arg name="height" type="int"/>
+    </request>
+    <request name="ack_configure">
+      <description summary="ack a configure event">
+        When a configure event is received, if a client commits the
+        surface in response to the configure event, then the client
+        must make an ack_configure request sometime before the commit
+        request, passing along the serial of the configure event.
+        For instance, for toplevel surfaces the compositor might use this
+        information to move a surface to the top left only when the client has
+        drawn itself for the maximized or fullscreen state.
+        If the client receives multiple configure events before it
+        can respond to one, it only has to ack the last configure event.
+        Acking a configure event that was never sent raises an invalid_serial
+        error.
+        A client is not required to commit immediately after sending
+        an ack_configure request - it may even ack_configure several times
+        before its next surface commit.
+        A client may send multiple ack_configure requests before committing, but
+        only the last request sent before a commit indicates which configure
+        event the client really is responding to.
+        Sending an ack_configure request consumes the serial number sent with
+        the request, as well as serial numbers sent by all configure events
+        sent on this xdg_surface prior to the configure event referenced by
+        the committed serial.
+        It is an error to issue multiple ack_configure requests referencing a
+        serial from the same configure event, or to issue an ack_configure
+        request referencing a serial from a configure event issued before the
+        event identified by the last ack_configure request for the same
+        xdg_surface. Doing so will raise an invalid_serial error.
+      </description>
+      <arg name="serial" type="uint" summary="the serial from the configure event"/>
+    </request>
+    <event name="configure">
+      <description summary="suggest a surface change">
+        The configure event marks the end of a configure sequence. A configure
+        sequence is a set of one or more events configuring the state of the
+        xdg_surface, including the final xdg_surface.configure event.
+        Where applicable, xdg_surface surface roles will during a configure
+        sequence extend this event as a latched state sent as events before the
+        xdg_surface.configure event. Such events should be considered to make up
+        a set of atomically applied configuration states, where the
+        xdg_surface.configure commits the accumulated state.
+        Clients should arrange their surface for the new states, and then send
+        an ack_configure request with the serial sent in this configure event at
+        some point before committing the new surface.
+        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>
+      <arg name="serial" type="uint" summary="serial of the configure event"/>
+    </event>
+  </interface>
+  <interface name="xdg_toplevel" version="6">
+    <description summary="toplevel surface">
+      This interface defines an xdg_surface role which allows a surface to,
+      among other things, set window-like properties such as maximize,
+      fullscreen, and minimize, set application-specific metadata like title and
+      id, and well as trigger user interactive operations such as interactive
+      resize and move.
+      Unmapping an xdg_toplevel means that the surface cannot be shown
+      by the compositor until it is explicitly mapped again.
+      All active operations (e.g., move, resize) are canceled and all
+      attributes (e.g. title, state, stacking, ...) are discarded for
+      an xdg_toplevel surface when it is unmapped. The xdg_toplevel returns to
+      the state it had right after xdg_surface.get_toplevel. The client
+      can re-map the toplevel by perfoming a commit without any buffer
+      attached, waiting for a configure event and handling it as usual (see
+      xdg_surface description).
+      Attaching a null buffer to a toplevel unmaps the surface.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the xdg_toplevel">
+        This request destroys the role surface and unmaps the surface;
+        see "Unmapping" behavior in interface section for details.
+      </description>
+    </request>
+    <enum name="error">
+      <entry name="invalid_resize_edge" value="0" summary="provided value is
+        not a valid variant of the resize_edge enum"/>
+      <entry name="invalid_parent" value="1"
+        summary="invalid parent toplevel"/>
+      <entry name="invalid_size" value="2"
+        summary="client provided an invalid min or max size"/>
+    </enum>
+    <request name="set_parent">
+      <description summary="set the parent of this surface">
+        Set the "parent" of this surface. This surface should be stacked
+        above the parent surface and all other ancestor surfaces.
+        Parent surfaces should be set on dialogs, toolboxes, or other
+        "auxiliary" surfaces, so that the parent is raised when the dialog
+        is raised.
+        Setting a null parent for a child surface unsets its parent. Setting
+        a null parent for a surface which currently has no parent is a no-op.
+        Only mapped surfaces can have child surfaces. Setting a parent which
+        is not mapped is equivalent to setting a null parent. If a surface
+        becomes unmapped, its children's parent is set to the parent of
+        the now-unmapped surface. If the now-unmapped surface has no parent,
+        its children's parent is unset. If the now-unmapped surface becomes
+        mapped again, its parent-child relationship is not restored.
+        The parent toplevel must not be one of the child toplevel's
+        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"/>
+    </request>
+    <request name="set_title">
+      <description summary="set surface title">
+        Set a short title for the surface.
+        This string may be used to identify the surface in a task bar,
+        window list, or other user interface elements provided by the
+        compositor.
+        The string must be encoded in UTF-8.
+      </description>
+      <arg name="title" type="string"/>
+    </request>
+    <request name="set_app_id">
+      <description summary="set application ID">
+        Set an application identifier for the surface.
+        The app ID identifies the general class of applications to which
+        the surface belongs. The compositor can use this to group multiple
+        surfaces together, or to determine how to launch a new application.
+        For D-Bus activatable applications, the app ID is used as the D-Bus
+        service name.
+        The compositor shell will try to group application surfaces together
+        by their app ID. As a best practice, it is suggested to select app
+        ID's that match the basename of the application's .desktop file.
+        For example, "org.freedesktop.FooViewer" where the .desktop file is
+        "org.freedesktop.FooViewer.desktop".
+        Like other properties, a set_app_id request can be sent after the
+        xdg_toplevel has been mapped to update the property.
+        See the desktop-entry specification [0] for more details on
+        application identifiers and how they relate to well-known D-Bus
+        names and .desktop files.
+        [0] https://standards.freedesktop.org/desktop-entry-spec/
+      </description>
+      <arg name="app_id" type="string"/>
+    </request>
+    <request name="show_window_menu">
+      <description summary="show the window menu">
+        Clients implementing client-side decorations might want to show
+        a context menu when right-clicking on the decorations, giving the
+        user a menu that they can use to maximize or minimize the window.
+        This request asks the compositor to pop up such a window menu at
+        the given position, relative to the local surface coordinates of
+        the parent surface. There are no guarantees as to what menu items
+        the window menu contains, or even if a window menu will be drawn
+        at all.
+        This request must be used in response to some sort of user action
+        like a button press, key press, or touch down event.
+      </description>
+      <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
+      <arg name="serial" type="uint" summary="the serial of the user event"/>
+      <arg name="x" type="int" summary="the x position to pop up the window menu at"/>
+      <arg name="y" type="int" summary="the y position to pop up the window menu at"/>
+    </request>
+    <request name="move">
+      <description summary="start an interactive move">
+        Start an interactive, user-driven move of the surface.
+        This request must be used in response to some sort of user action
+        like a button press, key press, or touch down event. The passed
+        serial is used to determine the type of interactive move (touch,
+        pointer, etc).
+        The server may ignore move requests depending on the state of
+        the surface (e.g. fullscreen or maximized), or if the passed serial
+        is no longer valid.
+        If triggered, the surface will lose the focus of the device
+        (wl_pointer, wl_touch, etc) used for the move. It is up to the
+        compositor to visually indicate that the move is taking place, such as
+        updating a pointer cursor, during the move. There is no guarantee
+        that the device focus will return when the move is completed.
+      </description>
+      <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
+      <arg name="serial" type="uint" summary="the serial of the user event"/>
+    </request>
+    <enum name="resize_edge">
+      <description summary="edge values for resizing">
+        These values are used to indicate which edge of a surface
+        is being dragged in a resize operation.
+      </description>
+      <entry name="none" value="0"/>
+      <entry name="top" value="1"/>
+      <entry name="bottom" value="2"/>
+      <entry name="left" value="4"/>
+      <entry name="top_left" value="5"/>
+      <entry name="bottom_left" value="6"/>
+      <entry name="right" value="8"/>
+      <entry name="top_right" value="9"/>
+      <entry name="bottom_right" value="10"/>
+    </enum>
+    <request name="resize">
+      <description summary="start an interactive resize">
+        Start a user-driven, interactive resize of the surface.
+        This request must be used in response to some sort of user action
+        like a button press, key press, or touch down event. The passed
+        serial is used to determine the type of interactive resize (touch,
+        pointer, etc).
+        The server may ignore resize requests depending on the state of
+        the surface (e.g. fullscreen or maximized).
+        If triggered, the client will receive configure events with the
+        "resize" state enum value and the expected sizes. See the "resize"
+        enum value for more details about what is required. The client
+        must also acknowledge configure events using "ack_configure". After
+        the resize is completed, the client will receive another "configure"
+        event without the resize state.
+        If triggered, the surface also will lose the focus of the device
+        (wl_pointer, wl_touch, etc) used for the resize. It is up to the
+        compositor to visually indicate that the resize is taking place,
+        such as updating a pointer cursor, during the resize. There is no
+        guarantee that the device focus will return when the resize is
+        completed.
+        The edges parameter specifies how the surface should be resized, and
+        is one of the values of the resize_edge enum. Values not matching
+        a variant of the enum will cause the invalid_resize_edge protocol error.
+        The compositor may use this information to update the surface position
+        for example when dragging the top left corner. The compositor may also
+        use this information to adapt its behavior, e.g. choose an appropriate
+        cursor image.
+      </description>
+      <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
+      <arg name="serial" type="uint" summary="the serial of the user event"/>
+      <arg name="edges" type="uint" enum="resize_edge" summary="which edge or corner is being dragged"/>
+    </request>
+    <enum name="state">
+      <description summary="types of state on the surface">
+        The different state values used on the surface. This is designed for
+        state values like maximized, fullscreen. It is paired with the
+        configure event to ensure that both the client and the compositor
+        setting the state can be synchronized.
+        States set in this way are double-buffered. They will get applied on
+        the next commit.
+      </description>
+      <entry name="maximized" value="1" summary="the surface is maximized">
+        <description summary="the surface is maximized">
+          The surface is maximized. The window geometry specified in the configure
+          event must be obeyed by the client, or the xdg_wm_base.invalid_surface_state
+          error is raised.
+          The client should draw without shadow or other
+          decoration outside of the window geometry.
+        </description>
+      </entry>
+      <entry name="fullscreen" value="2" summary="the surface is fullscreen">
+        <description summary="the surface is fullscreen">
+          The surface is fullscreen. The window geometry specified in the
+          configure event is a maximum; the client cannot resize beyond it. For
+          a surface to cover the whole fullscreened area, the geometry
+          dimensions must be obeyed by the client. For more details, see
+          xdg_toplevel.set_fullscreen.
+        </description>
+      </entry>
+      <entry name="resizing" value="3" summary="the surface is being resized">
+        <description summary="the surface is being resized">
+          The surface is being resized. The window geometry specified in the
+          configure event is a maximum; the client cannot resize beyond it.
+          Clients that have aspect ratio or cell sizing configuration can use
+          a smaller size, however.
+        </description>
+      </entry>
+      <entry name="activated" value="4" summary="the surface is now activated">
+        <description summary="the surface is now activated">
+          Client window decorations should be painted as if the window is
+          active. Do not assume this means that the window actually has
+          keyboard or pointer focus.
+        </description>
+      </entry>
+      <entry name="tiled_left" value="5" since="2">
+        <description summary="the surface’s left edge is tiled">
+          The window is currently in a tiled layout and the left edge is
+          considered to be adjacent to another part of the tiling grid.
+        </description>
+      </entry>
+      <entry name="tiled_right" value="6" since="2">
+        <description summary="the surface’s right edge is tiled">
+          The window is currently in a tiled layout and the right edge is
+          considered to be adjacent to another part of the tiling grid.
+        </description>
+      </entry>
+      <entry name="tiled_top" value="7" since="2">
+        <description summary="the surface’s top edge is tiled">
+          The window is currently in a tiled layout and the top edge is
+          considered to be adjacent to another part of the tiling grid.
+        </description>
+      </entry>
+      <entry name="tiled_bottom" value="8" since="2">
+        <description summary="the surface’s bottom edge is tiled">
+          The window is currently in a tiled layout and the bottom edge is
+          considered to be adjacent to another part of the tiling grid.
+        </description>
+      </entry>
+      <entry name="suspended" value="9" since="6">
+        <description summary="surface repaint is suspended">
+          The surface is currently not ordinarily being repainted; for
+          example because its content is occluded by another window, or its
+          outputs are switched off due to screen locking.
+        </description>
+      </entry>
+    </enum>
+    <request name="set_max_size">
+      <description summary="set the maximum size">
+        Set a maximum size for the window.
+        The client can specify a maximum size so that the compositor does
+        not try to configure the window beyond this size.
+        The width and height arguments are in window geometry coordinates.
+        See xdg_surface.set_window_geometry.
+        Values set in this way are double-buffered. They will get applied
+        on the next commit.
+        The compositor can use this information to allow or disallow
+        different states like maximize or fullscreen and draw accurate
+        animations.
+        Similarly, a tiling window manager may use this information to
+        place and resize client windows in a more effective way.
+        The client should not rely on the compositor to obey the maximum
+        size. The compositor may decide to ignore the values set by the
+        client and request a larger size.
+        If never set, or a value of zero in the request, means that the
+        client has no expected maximum size in the given dimension.
+        As a result, a client wishing to reset the maximum size
+        to an unspecified state can use zero for width and height in the
+        request.
+        Requesting a maximum size to be smaller than the minimum size of
+        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 a
+        invalid_size error.
+      </description>
+      <arg name="width" type="int"/>
+      <arg name="height" type="int"/>
+    </request>
+    <request name="set_min_size">
+      <description summary="set the minimum size">
+        Set a minimum size for the window.
+        The client can specify a minimum size so that the compositor does
+        not try to configure the window below this size.
+        The width and height arguments are in window geometry coordinates.
+        See xdg_surface.set_window_geometry.
+        Values set in this way are double-buffered. They will get applied
+        on the next commit.
+        The compositor can use this information to allow or disallow
+        different states like maximize or fullscreen and draw accurate
+        animations.
+        Similarly, a tiling window manager may use this information to
+        place and resize client windows in a more effective way.
+        The client should not rely on the compositor to obey the minimum
+        size. The compositor may decide to ignore the values set by the
+        client and request a smaller size.
+        If never set, or a value of zero in the request, means that the
+        client has no expected minimum size in the given dimension.
+        As a result, a client wishing to reset the minimum size
+        to an unspecified state can use zero for width and height in the
+        request.
+        Requesting a minimum size to be larger than the maximum size of
+        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 a
+        invalid_size error.
+      </description>
+      <arg name="width" type="int"/>
+      <arg name="height" type="int"/>
+    </request>
+    <request name="set_maximized">
+      <description summary="maximize the window">
+        Maximize the surface.
+        After requesting that the surface should be maximized, the compositor
+        will respond by emitting a configure event. Whether this configure
+        actually sets the window maximized is subject to compositor policies.
+        The client must then update its content, drawing in the configured
+        state. The client must also acknowledge the configure when committing
+        the new content (see ack_configure).
+        It is up to the compositor to decide how and where to maximize the
+        surface, for example which output and what region of the screen should
+        be used.
+        If the surface was already maximized, the compositor will still emit
+        a configure event with the "maximized" state.
+        If the surface is in a fullscreen state, this request has no direct
+        effect. It may alter the state the surface is returned to when
+        unmaximized unless overridden by the compositor.
+      </description>
+    </request>
+    <request name="unset_maximized">
+      <description summary="unmaximize the window">
+        Unmaximize the surface.
+        After requesting that the surface should be unmaximized, the compositor
+        will respond by emitting a configure event. Whether this actually
+        un-maximizes the window is subject to compositor policies.
+        If available and applicable, the compositor will include the window
+        geometry dimensions the window had prior to being maximized in the
+        configure event. The client must then update its content, drawing it in
+        the configured state. The client must also acknowledge the configure
+        when committing the new content (see ack_configure).
+        It is up to the compositor to position the surface after it was
+        unmaximized; usually the position the surface had before maximizing, if
+        applicable.
+        If the surface was already not maximized, the compositor will still
+        emit a configure event without the "maximized" state.
+        If the surface is in a fullscreen state, this request has no direct
+        effect. It may alter the state the surface is returned to when
+        unmaximized unless overridden by the compositor.
+      </description>
+    </request>
+    <request name="set_fullscreen">
+      <description summary="set the window as fullscreen on an output">
+        Make the surface fullscreen.
+        After requesting that the surface should be fullscreened, the
+        compositor will respond by emitting a configure event. Whether the
+        client is actually put into a fullscreen state is subject to compositor
+        policies. The client must also acknowledge the configure when
+        committing the new content (see ack_configure).
+        The output passed by the request indicates the client's preference as
+        to which display it should be set fullscreen on. If this value is NULL,
+        it's up to the compositor to choose which display will be used to map
+        this surface.
+        If the surface doesn't cover the whole output, the compositor will
+        position the surface in the center of the output and compensate with
+        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).
+        If the fullscreened surface is not opaque, the compositor must make
+        sure that other screen content not part of the same surface tree (made
+        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"/>
+    </request>
+    <request name="unset_fullscreen">
+      <description summary="unset the window as fullscreen">
+        Make the surface no longer fullscreen.
+        After requesting that the surface should be unfullscreened, the
+        compositor will respond by emitting a configure event.
+        Whether this actually removes the fullscreen state of the client is
+        subject to compositor policies.
+        Making a surface unfullscreen sets states for the surface based on the following:
+        * the state(s) it may have had before becoming fullscreen
+        * any state(s) decided by the compositor
+        * any state(s) requested by the client while the surface was fullscreen
+        The compositor may include the previous window geometry dimensions in
+        the configure event, if applicable.
+        The client must also acknowledge the configure when committing the new
+        content (see ack_configure).
+      </description>
+    </request>
+    <request name="set_minimized">
+      <description summary="set the window as minimized">
+        Request that the compositor minimize your surface. There is no
+        way to know if the surface is currently minimized, nor is there
+        any way to unset minimization on this surface.
+        If you are looking to throttle redrawing when minimized, please
+        instead use the wl_surface.frame event for this, as this will
+        also work with live previews on windows in Alt-Tab, Expose or
+        similar compositor features.
+      </description>
+    </request>
+    <event name="configure">
+      <description summary="suggest a surface change">
+        This configure event asks the client to resize its toplevel surface or
+        to change its state. The configured state should not be applied
+        immediately. See xdg_surface.configure for details.
+        The width and height arguments specify a hint to the window
+        about how its surface should be resized in window geometry
+        coordinates. See set_window_geometry.
+        If the width or height arguments are zero, it means the client
+        should decide its own window dimension. This may happen when the
+        compositor needs to configure the state of the surface but doesn't
+        have any information about any previous or expected dimension.
+        The states listed in the event specify how the width/height
+        arguments should be interpreted, and possibly how it should be
+        drawn.
+        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"/>
+      <arg name="height" type="int"/>
+      <arg name="states" type="array"/>
+    </event>
+    <event name="close">
+      <description summary="surface wants to be closed">
+        The close event is sent by the compositor when the user
+        wants the surface to be closed. This should be equivalent to
+        the user clicking the close button in client-side decorations,
+        if your application has any.
+        This is only a request that the user intends to close the
+        window. The client may choose to ignore this request, or show
+        a dialog to ask the user to save their data, etc.
+      </description>
+    </event>
+    <!-- Version 4 additions -->
+    <event name="configure_bounds" since="4">
+      <description summary="recommended window geometry bounds">
+        The configure_bounds event may be sent prior to a xdg_toplevel.configure
+        event to communicate the bounds a window geometry size is recommended
+        to constrain to.
+        The passed width and height are in surface coordinate space. If width
+        and height are 0, it means bounds is unknown and equivalent to as if no
+        configure_bounds event was ever sent for this surface.
+        The bounds can for example correspond to the size of a monitor excluding
+        any panels or other shell components, so that a surface isn't created in
+        a way that it cannot fit.
+        The bounds may change at any point, and in such a case, a new
+        xdg_toplevel.configure_bounds will be sent, followed by
+        xdg_toplevel.configure and xdg_surface.configure.
+      </description>
+      <arg name="width" type="int"/>
+      <arg name="height" type="int"/>
+    </event>
+    <!-- Version 5 additions -->
+    <enum name="wm_capabilities" since="5">
+      <entry name="window_menu" value="1" summary="show_window_menu is available"/>
+      <entry name="maximize" value="2" summary="set_maximized and unset_maximized are available"/>
+      <entry name="fullscreen" value="3" summary="set_fullscreen and unset_fullscreen are available"/>
+      <entry name="minimize" value="4" summary="set_minimized is available"/>
+    </enum>
+    <event name="wm_capabilities" since="5">
+      <description summary="compositor capabilities">
+        This event advertises the capabilities supported by the compositor. If
+        a capability isn't supported, clients should hide or disable the UI
+        elements that expose this functionality. For instance, if the
+        compositor doesn't advertise support for minimized toplevels, a button
+        triggering the set_minimized request should not be displayed.
+        The compositor will ignore requests it doesn't support. For instance,
+        a compositor which doesn't advertise support for minimized will ignore
+        set_minimized requests.
+        Compositors must send this event once before the first
+        xdg_surface.configure event. When the capabilities change, compositors
+        must send this event again and then send an xdg_surface.configure
+        event.
+        The configured state should not be applied immediately. See
+        xdg_surface.configure for details.
+        The capabilities are sent as an array of 32-bit unsigned integers in
+        native endianness.
+      </description>
+      <arg name="capabilities" type="array" summary="array of 32-bit capabilities"/>
+    </event>
+  </interface>
+  <interface name="xdg_popup" version="6">
+    <description summary="short-lived, popup surfaces for menus">
+      A popup surface is a short-lived, temporary surface. It can be used to
+      implement for example menus, popovers, tooltips and other similar user
+      interface concepts.
+      A popup can be made to take an explicit grab. See xdg_popup.grab for
+      details.
+      When the popup is dismissed, a popup_done event will be sent out, and at
+      the same time the surface will be unmapped. See the xdg_popup.popup_done
+      event for details.
+      Explicitly destroying the xdg_popup object will also dismiss the popup and
+      unmap the surface. Clients that want to dismiss the popup when another
+      surface of their own is clicked should dismiss the popup using the destroy
+      request.
+      A newly created xdg_popup will be stacked on top of all previously created
+      xdg_popup surfaces associated with the same xdg_toplevel.
+      The parent of an xdg_popup must be mapped (see the xdg_surface
+      description) before the xdg_popup itself.
+      The client must call wl_surface.commit on the corresponding wl_surface
+      for the xdg_popup state to take effect.
+    </description>
+    <enum name="error">
+      <entry name="invalid_grab" value="0"
+             summary="tried to grab after being mapped"/>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="remove xdg_popup interface">
+        This destroys the popup. Explicitly destroying the xdg_popup
+        object will also dismiss the popup, and unmap the surface.
+        If this xdg_popup is not the "topmost" popup, the
+        xdg_wm_base.not_the_topmost_popup protocol error will be sent.
+      </description>
+    </request>
+    <request name="grab">
+      <description summary="make the popup take an explicit grab">
+        This request makes the created popup take an explicit grab. An explicit
+        grab will be dismissed when the user dismisses the popup, or when the
+        client destroys the xdg_popup. This can be done by the user clicking
+        outside the surface, using the keyboard, or even locking the screen
+        through closing the lid or a timeout.
+        If the compositor denies the grab, the popup will be immediately
+        dismissed.
+        This request must be used in response to some sort of user action like a
+        button press, key press, or touch down event. The serial number of the
+        event should be passed as 'serial'.
+        The parent of a grabbing popup must either be an xdg_toplevel surface or
+        another xdg_popup with an explicit grab. If the parent is another
+        xdg_popup it means that the popups are nested, with this popup now being
+        the topmost popup.
+        Nested popups must be destroyed in the reverse order they were created
+        in, e.g. the only popup you are allowed to destroy at all times is the
+        topmost one.
+        When compositors choose to dismiss a popup, they may dismiss every
+        nested grabbing popup as well. When a compositor dismisses popups, it
+        will follow the same dismissing order as required from the client.
+        If the topmost grabbing popup is destroyed, the grab will be returned to
+        the parent of the popup, if that parent previously had an explicit grab.
+        If the parent is a grabbing popup which has already been dismissed, this
+        popup will be immediately dismissed. If the parent is a popup that did
+        not take an explicit grab, an error will be raised.
+        During a popup grab, the client owning the grab will receive pointer
+        and touch events for all their surfaces as normal (similar to an
+        "owner-events" grab in X11 parlance), while the top most grabbing popup
+        will always have keyboard focus.
+      </description>
+      <arg name="seat" type="object" interface="wl_seat"
+           summary="the wl_seat of the user event"/>
+      <arg name="serial" type="uint" summary="the serial of the user event"/>
+    </request>
+    <event name="configure">
+      <description summary="configure the popup surface">
+        This event asks the popup surface to configure itself given the
+        configuration. The configured state should not be applied immediately.
+        See xdg_surface.configure for details.
+        The x and y arguments represent the position the popup was placed at
+        given the xdg_positioner rule, relative to the upper left corner of the
+        window geometry of the parent surface.
+        For version 2 or older, the configure event for an xdg_popup is only
+        ever sent once for the initial configuration. Starting with version 3,
+        it may be sent again if the popup is setup with an xdg_positioner with
+        set_reactive requested, or in response to xdg_popup.reposition requests.
+      </description>
+      <arg name="x" type="int"
+           summary="x position relative to parent surface window geometry"/>
+      <arg name="y" type="int"
+           summary="y position relative to parent surface window geometry"/>
+      <arg name="width" type="int" summary="window geometry width"/>
+      <arg name="height" type="int" summary="window geometry height"/>
+    </event>
+    <event name="popup_done">
+      <description summary="popup interaction is done">
+        The popup_done event is sent out when a popup is dismissed by the
+        compositor. The client should destroy the xdg_popup object at this
+        point.
+      </description>
+    </event>
+    <!-- Version 3 additions -->
+    <request name="reposition" since="3">
+      <description summary="recalculate the popup's location">
+        Reposition an already-mapped popup. The popup will be placed given the
+        details in the passed xdg_positioner object, and a
+        xdg_popup.repositioned followed by xdg_popup.configure and
+        xdg_surface.configure will be emitted in response. Any parameters set
+        by the previous positioner will be discarded.
+        The passed token will be sent in the corresponding
+        xdg_popup.repositioned event. The new popup position will not take
+        effect until the corresponding configure event is acknowledged by the
+        client. See xdg_popup.repositioned for details. The token itself is
+        opaque, and has no other special meaning.
+        If multiple reposition requests are sent, the compositor may skip all
+        but the last one.
+        If the popup is repositioned in response to a configure event for its
+        parent, the client should send an xdg_positioner.set_parent_configure
+        and possibly an xdg_positioner.set_parent_size request to allow the
+        compositor to properly constrain the popup.
+        If the popup is repositioned together with a parent that is being
+        resized, but not in response to a configure event, the client should
+        send an xdg_positioner.set_parent_size request.
+      </description>
+      <arg name="positioner" type="object" interface="xdg_positioner"/>
+      <arg name="token" type="uint" summary="reposition request token"/>
+    </request>
+    <event name="repositioned" since="3">
+      <description summary="signal the completion of a repositioned request">
+        The repositioned event is sent as part of a popup configuration
+        sequence, together with xdg_popup.configure and lastly
+        xdg_surface.configure to notify the completion of a reposition request.
+        The repositioned event is to notify about the completion of a
+        xdg_popup.reposition request. The token argument is the token passed
+        in the xdg_popup.reposition request.
+        Immediately after this event is emitted, xdg_popup.configure and
+        xdg_surface.configure will be sent with the updated size and position,
+        as well as a new configure serial.
+        The client should optionally update the content of the popup, but must
+        acknowledge the new popup configuration for the new position to take
+        effect. See xdg_surface.ack_configure for details.
+      </description>
+      <arg name="token" type="uint" summary="reposition request token"/>
+    </event>
+  </interface>
+</protocol>
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/xdg-toplevel-icon-v1.xml b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-toplevel-icon-v1.xml
new file mode 100644
index 0000000..4270d69
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-toplevel-icon-v1.xml
@@ -0,0 +1,203 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_toplevel_icon_v1">
+  <copyright>
+    Copyright © 2023-2024 Matthias Klumpp
+    Copyright ©      2024 David Edmundson
+    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 assign icons to toplevels">
+    This protocol allows clients to set icons for their toplevel surfaces
+    either via the XDG icon stock (using an icon name), or from pixel data.
+    A toplevel icon represents the individual toplevel (unlike the application
+    or launcher icon, which represents the application as a whole), and may be
+    shown in window switchers, window overviews and taskbars that list
+    individual windows.
+    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="xdg_toplevel_icon_manager_v1" version="1">
+    <description summary="interface to manage toplevel icons">
+      This interface allows clients to create toplevel window icons and set
+      them on toplevel windows to be displayed to the user.
+    </description>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the toplevel icon manager">
+        Destroy the toplevel icon manager.
+        This does not destroy objects created with the manager.
+      </description>
+    </request>
+    <request name="create_icon">
+      <description summary="create a new icon instance">
+        Creates a new icon object. This icon can then be attached to a
+        xdg_toplevel via the 'set_icon' request.
+      </description>
+      <arg name="id" type="new_id" interface="xdg_toplevel_icon_v1"/>
+    </request>
+    <request name="set_icon">
+      <description summary="set an icon on a toplevel window">
+        This request assigns the icon 'icon' to 'toplevel', or clears the
+        toplevel icon if 'icon' was null.
+        This state is double-buffered and is applied on the next
+        wl_surface.commit of the toplevel.
+        After making this call, the xdg_toplevel_icon_v1 provided as 'icon'
+        can be destroyed by the client without 'toplevel' losing its icon.
+        The xdg_toplevel_icon_v1 is immutable from this point, and any
+        future attempts to change it must raise the
+        'xdg_toplevel_icon_v1.immutable' protocol error.
+        The compositor must set the toplevel icon from either the pixel data
+        the icon provides, or by loading a stock icon using the icon name.
+        See the description of 'xdg_toplevel_icon_v1' for details.
+        If 'icon' is set to null, the icon of the respective toplevel is reset
+        to its default icon (usually the icon of the application, derived from
+        its desktop-entry file, or a placeholder icon).
+        If this request is passed an icon with no pixel buffers or icon name
+        assigned, the icon must be reset just like if 'icon' was null.
+      </description>
+      <arg name="toplevel" type="object" interface="xdg_toplevel" summary="the toplevel to act on"/>
+      <arg name="icon" type="object" interface="xdg_toplevel_icon_v1" allow-null="true"/>
+    </request>
+    <event name="icon_size">
+      <description summary="describes a supported &amp; preferred icon size">
+        This event indicates an icon size the compositor prefers to be
+        available if the client has scalable icons and can render to any size.
+        When the 'xdg_toplevel_icon_manager_v1' object is created, the
+        compositor may send one or more 'icon_size' events to describe the list
+        of preferred icon sizes. If the compositor has no size preference, it
+        may not send any 'icon_size' event, and it is up to the client to
+        decide a suitable icon size.
+        A sequence of 'icon_size' events must be finished with a 'done' event.
+        If the compositor has no size preferences, it must still send the
+        'done' event, without any preceding 'icon_size' events.
+      </description>
+      <arg name="size" type="int"
+           summary="the edge size of the square icon in surface-local coordinates, e.g. 64"/>
+    </event>
+    <event name="done">
+      <description summary="all information has been sent">
+        This event is sent after all 'icon_size' events have been sent.
+      </description>
+    </event>
+  </interface>
+  <interface name="xdg_toplevel_icon_v1" version="1">
+    <description summary="a toplevel window icon">
+      This interface defines a toplevel icon.
+      An icon can have a name, and multiple buffers.
+      In order to be applied, the icon must have either a name, or at least
+      one buffer assigned. Applying an empty icon (with no buffer or name) to
+      a toplevel should reset its icon to the default icon.
+      It is up to compositor policy whether to prefer using a buffer or loading
+      an icon via its name. See 'set_name' and 'add_buffer' for details.
+    </description>
+    <enum name="error">
+      <entry name="invalid_buffer"
+             summary="the provided buffer does not satisfy requirements"
+             value="1"/>
+      <entry name="immutable"
+             summary="the icon has already been assigned to a toplevel and must not be changed"
+             value="2"/>
+      <entry name="no_buffer"
+             summary="the provided buffer has been destroyed before the toplevel icon"
+             value="3"/>
+    </enum>
+    <request name="destroy" type="destructor">
+      <description summary="destroy the icon object">
+        Destroys the 'xdg_toplevel_icon_v1' object.
+        The icon must still remain set on every toplevel it was assigned to,
+        until the toplevel icon is reset explicitly.
+      </description>
+    </request>
+    <request name="set_name">
+      <description summary="set an icon name">
+        This request assigns an icon name to this icon.
+        Any previously set name is overridden.
+        The compositor must resolve 'icon_name' according to the lookup rules
+        described in the XDG icon theme specification[1] using the
+        environment's current icon theme.
+        If the compositor does not support icon names or cannot resolve
+        'icon_name' according to the XDG icon theme specification it must
+        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', a 'immutable' error must be raised.
+        [1]: https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
+      </description>
+      <arg name="icon_name" type="string"/>
+    </request>
+    <request name="add_buffer">
+      <description summary="add icon data from a pixel buffer">
+        This request adds pixel data supplied as wl_buffer to the icon.
+        The client should add pixel data for all icon sizes and scales that
+        it can provide, or which are explicitly requested by the compositor
+        via 'icon_size' events on xdg_toplevel_icon_manager_v1.
+        The wl_buffer supplying pixel data as 'buffer' must be backed by wl_shm
+        and must be a square (width and height being equal).
+        If any of these buffer requirements are not fulfilled, a 'invalid_buffer'
+        error must be raised.
+        If this icon instance already has a buffer of the same size and scale
+        from a previous 'add_buffer' request, data from the last request
+        overrides the preexisting pixel data.
+        The wl_buffer must be kept alive for as long as the xdg_toplevel_icon
+        it is associated with is not destroyed, otherwise a 'no_buffer' error
+        is raised. The buffer contents must not be modified after it was
+        assigned to the icon.
+        If this request is made after the icon has been assigned to a toplevel
+        via 'set_icon', a 'immutable' error must be raised.
+      </description>
+      <arg name="buffer" type="object" interface="wl_buffer"/>
+      <arg name="scale" type="int"
+           summary="the scaling factor of the icon, e.g. 1"/>
+    </request>
+  </interface>
+</protocol>