Ammerhai/Mikemon
2
0
Fork 0
Code Issues 8 Pull Requests Packages Projects 2 Releases 1 Wiki Activity

update SDL3 from 3.2.20 to 3.4.2

Browse Source
This commit is contained in:
Sven Balzer
2026-04-01 18:25:03 +02:00
parent 1daf4d79f1
commit 05b19704f8
1626 changed files with 124218 additions and 191491 deletions
Download Patch File Download Diff File Expand all files Collapse all files
libs/SDL3/wayland-protocols/color-management-v1.xml
+221 -128
View File
@@ -31,9 +31,14 @@
<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.
properties of their content on surfaces. All surface contents must be
readily intended for some display, but not necessarily for the display at
hand. Doing this enables a compositor to perform automatic color management
of content for different outputs according to how content is intended to
look like.
For an introduction, see the section "Color management" in the Wayland
documentation at https://wayland.freedesktop.org/docs/html/ .
The color properties are represented as an image description object which
is immutable after it has been created. A wl_output always has an
@@ -43,16 +48,17 @@
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.
An image description essentially defines a display and (indirectly) its
viewing environment. An image description includes SDR and HDR colorimetry
and encoding, HDR metadata, and some parameters related to the viewing
environment. 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 normative appendix for this protocol is in the appendix.md file beside
this XML file.
The color-and-hdr repository
(https://gitlab.freedesktop.org/pq/color-and-hdr) contains
@@ -71,7 +77,7 @@
only be done by creating a new major version of the extension.
</description>
<interface name="wp_color_manager_v1" version="1">
<interface name="wp_color_manager_v1" version="2">
<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
@@ -118,6 +124,14 @@
summary="ICC-absolute colorimetric"/>
<entry name="relative_bpc" value="4"
summary="media-relative colorimetric + black point compensation"/>
<entry name="absolute_no_adaptation" value="5" since="2">
<description summary="ICC-absolute colorimetric without adaptation">
This rendering intent is a modified absolute rendering intent that
assumes the viewer is not adapted to the display white point, so no
chromatic adaptation between surface and display is done.
This can be useful for color proofing applications.
</description>
</entry>
</enum>
<enum name="feature">
@@ -149,18 +163,14 @@
</description>
</entry>
<entry name="windows_scrgb" value="7"
summary="get_windows_scrgb request"/>
summary="create_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.
Named color primaries used to encode well-known sets of primaries.
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">
@@ -173,7 +183,6 @@
- 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">
@@ -184,7 +193,6 @@
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">
@@ -194,7 +202,6 @@
- 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">
@@ -205,13 +212,13 @@
- 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.
Color primaries as defined by Recommendation ITU-T H.273
"Coding-independent code points for video signal type identification"
for "generic film".
</description>
</entry>
<entry name="bt2020" value="6">
@@ -219,7 +226,6 @@
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">
@@ -228,21 +234,18 @@
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.
SMPTE RP 431-2 (2011).
</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">
@@ -256,13 +259,11 @@
<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.
characteristics of displays.
A value of 0 is invalid and will never be present in the list of enums.
Descriptions do list the specifications for convenience.
See appendix.md for the formulae.
</description>
<entry name="bt1886" value="1">
@@ -271,8 +272,6 @@
- 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²
@@ -289,65 +288,57 @@
- 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.
- IEC 61966-2-1 (reference display)
</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">
<entry name="srgb" value="9" deprecated-since="2">
<description summary="Deprecated (ambiguous sRGB 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.
As a rule of thumb, use gamma22 for video, motion picture and
computer graphics, or compound_power_2_4 for ICC calibrated print
workflows.
</description>
</entry>
<entry name="ext_srgb" value="10">
<description summary="Extended sRGB piece-wise transfer function">
<entry name="ext_srgb" value="10" deprecated-since="2">
<description summary="Deprecated (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">
@@ -355,7 +346,6 @@
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²
@@ -373,7 +363,6 @@
<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">
@@ -381,7 +370,6 @@
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²
@@ -398,6 +386,12 @@
ARIB STD-B67 or BT.2100.
</description>
</entry>
<entry name="compound_power_2_4" value="14" since="2">
<description summary="IEC 61966-2-1 encoding function">
Encoding characteristics as defined by IEC 61966-2-1, for displays
that invert the encoding function.
</description>
</entry>
</enum>
<request name="get_output">
@@ -531,6 +525,9 @@
<description summary="supported rendering intent">
When this object is created, it shall immediately send this event once
for each rendering intent the compositor supports.
A compositor must not advertise intents that are deprecated in the
bound version of the interface.
</description>
<arg name="render_intent" type="uint" enum="render_intent"
@@ -541,6 +538,9 @@
<description summary="supported features">
When this object is created, it shall immediately send this event once
for each compositor supported feature listed in the enumeration.
A compositor must not advertise features that are deprecated in the
bound version of the interface.
</description>
<arg name="feature" type="uint" enum="feature"
@@ -552,6 +552,9 @@
When this object is created, it shall immediately send this event once
for each named transfer function the compositor supports with the
parametric image description creator.
A compositor must not advertise transfer functions that are deprecated
in the bound version of the interface.
</description>
<arg name="tf" type="uint" enum="transfer_function"
@@ -563,6 +566,9 @@
When this object is created, it shall immediately send this event once
for each named set of primaries the compositor supports with the
parametric image description creator.
A compositor must not advertise names that are deprecated in the
bound version of the interface.
</description>
<arg name="primaries" type="uint" enum="primaries"
@@ -575,9 +581,23 @@
transfer functions and named primaries have been sent.
</description>
</event>
<request name="get_image_description" since="2">
<description summary="create an image description from a reference">
This request retrieves the image description backing a reference.
The get_information request can be used if and only if the request that
creates the reference allows it.
</description>
<arg name="image_description"
type="new_id" interface="wp_image_description_v1"/>
<arg name="reference"
type="object" interface="wp_image_description_reference_v1"/>
</request>
</interface>
<interface name="wp_color_management_output_v1" version="1">
<interface name="wp_color_management_output_v1" version="2">
<description summary="output color properties">
A wp_color_management_output_v1 describes the color properties of an
output.
@@ -647,7 +667,7 @@
</request>
</interface>
<interface name="wp_color_management_surface_v1" version="1">
<interface name="wp_color_management_surface_v1" version="2">
<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.
@@ -693,18 +713,18 @@
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
When an image description is set on a surface, it establishes an
explicit link between surface pixel values and surface colorimetry.
This link may be undefined for some pixel values, see the image
description creator interfaces for the conditions. Non-finite
floating-point values (NaN, Inf) always have an undefined colorimetry.
A rendering intent provides the client's preference on how surface
colorimetry 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
@@ -735,7 +755,7 @@
</request>
</interface>
<interface name="wp_color_management_surface_feedback_v1" version="1">
<interface name="wp_color_management_surface_feedback_v1" version="2">
<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.
@@ -758,27 +778,14 @@
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
<event name="preferred_changed" deprecated-since="2">
<description summary="the preferred image description changed (32-bit)">
Starting from interface version 2, 'preferred_changed2' is sent instead
of this event. See the 'preferred_changed2' event for the definition.
</description>
<arg name="identity" type="uint" summary="image description id number"/>
<arg name="identity" type="uint"
summary="the 32-bit image description id number"/>
</event>
<request name="get_preferred">
@@ -835,9 +842,38 @@
<arg name="image_description"
type="new_id" interface="wp_image_description_v1"/>
</request>
<!-- Version 2 additions -->
<event name="preferred_changed2" since="2">
<description summary="the preferred image description changed">
The preferred image description is the one which likely has the most
performance and/or quality benefits for the compositor if used by the
client for its wl_surface contents. This event is sent whenever the
compositor changes the wl_surface's preferred image description.
This event sends the identity of the new preferred state as the argument,
so clients who are aware of the image description already can reuse it.
Otherwise, if the client client wants to know what the preferred image
description is, it shall use the get_preferred request.
The preferred image description is not automatically used for anything.
It is only a hint, and clients may set any valid image description with
set_image_description, but there might be performance and color accuracy
improvements by providing the wl_surface contents in the preferred
image description. Therefore clients that can, should render according
to the preferred image description
</description>
<arg name="identity_hi" type="uint"
summary="high 32 bits of the 64-bit image description id number"/>
<arg name="identity_lo" type="uint"
summary="low 32 bits of the 64-bit image description id number"/>
</event>
</interface>
<interface name="wp_image_description_creator_icc_v1" version="1">
<interface name="wp_image_description_creator_icc_v1" version="2">
<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
@@ -853,6 +889,10 @@
Once all properties have been set, the create request must be used to
create the image description object, destroying the creator in the
process.
The link between a pixel value (a device value in ICC) and its respective
colorimetry is defined by the details of the particular ICC profile.
Those details also determine when colorimetry becomes undefined.
</description>
<enum name="error">
@@ -949,7 +989,7 @@
</request>
</interface>
<interface name="wp_image_description_creator_params_v1" version="1">
<interface name="wp_image_description_creator_params_v1" version="2">
<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
@@ -978,6 +1018,20 @@
Once all properties have been set, the create request must be used to
create the image description object, destroying the creator in the
process.
A viewer, who is viewing the display defined by the resulting image
description (the viewing environment included), is assumed to be fully
adapted to the primary color volume's white point.
Any of the following conditions will cause the colorimetry of a pixel
to become undefined:
- Values outside of the defined range of the transfer characteristic.
- Tristimulus that exceeds the target color volume.
- If extended_target_volume is not supported: tristimulus that exceeds
the primary color volume.
The closest correspondence to an image description created through this
interface is the Display class of profiles in ICC.
</description>
<enum name="error">
@@ -1006,14 +1060,16 @@
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 both max_cll and max_fall are set, max_fall must be less or equal
to max_cll otherwise the invalid_luminance protocol error is raised.
In version 1, these following conditions also result in the
invalid_luminance protocol error. Version 2 and later do not have this
requirement.
- When max_cll is set, it must be greater than min L and less or equal
to max L of the mastering luminance range.
- When max_fall is set, it must be greater than min L and less or equal
to max L of the mastering luminance range.
- When both max_cll and max_fall are set, max_fall must be less or equal
to max_cll.
If the particular combination of the parameter set is not supported
by the compositor, the resulting image description object shall
@@ -1039,7 +1095,7 @@
functions.
When the resulting image description is attached to an image, the
content should be encoded and decoded according to the industry standard
content should be decoded according to the industry standard
practices for the transfer characteristic.
Only names advertised with wp_color_manager_v1 event supported_tf_named
@@ -1061,9 +1117,6 @@
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.
@@ -1129,8 +1182,8 @@
<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
luminance level. These values include the minimum display emission, but
not external flare. The minimum display emission is assumed to have
the chromaticity of the primary color volume white point.
The default luminances from
@@ -1310,13 +1363,15 @@
</request>
</interface>
<interface name="wp_image_description_v1" version="1">
<interface name="wp_image_description_v1" version="2">
<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
An image description carries information about the pixel color encoding
and its intended display and viewing environment. The image description is
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.
quantities, which allows the compositor to transform the surface contents
to become suitable for various displays and viewing environments.
Note, that the wp_image_description_v1 object is not ready to be used
immediately after creation. The object eventually delivers either the
@@ -1385,38 +1440,22 @@
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.
<event name="ready" deprecated-since="2">
<description summary="the object is ready to be used (32-bit)">
Starting from interface version 2, the 'ready2' event is sent instead
of this event.
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.
For the definition of this event, see the 'ready2' event. The
difference to this event is as follows.
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"/>
<arg name="identity" type="uint"
summary="the 32-bit image description id number"/>
</event>
<request name="get_information">
@@ -1433,9 +1472,45 @@
<arg name="information"
type="new_id" interface="wp_image_description_info_v1"/>
</request>
<!-- Version 2 additions -->
<event name="ready2" since="2">
<description summary="the object is ready to be used">
Once this event has been sent, the wp_image_description_v1 object is
deemed "ready". Ready objects can be used to send requests and can be
used through other interfaces.
Every ready wp_image_description_v1 protocol object refers to an
underlying image description record in the compositor. Multiple protocol
objects may end up referring to the same record. Clients may identify
these "copies" by comparing their id numbers: if the numbers from two
protocol objects are identical, the protocol objects refer to the same
image description record. Two different image description records
cannot have the same id number simultaneously. The id number does not
change during the lifetime of the image description record.
Image description id number is not a protocol object id. Zero is
reserved as an invalid id number. It shall not be possible for a client
to refer to an image description by its id number in protocol. The id
numbers might not be portable between Wayland connections. A compositor
shall not send an invalid id number.
Compositors must not recycle image description id numbers.
This identity allows clients to de-duplicate image description records
and avoid get_information request if they already have the image
description information.
</description>
<arg name="identity_hi" type="uint"
summary="high 32 bits of the 64-bit image description id number"/>
<arg name="identity_lo" type="uint"
summary="low 32 bits of the 64-bit image description id number"/>
</event>
</interface>
<interface name="wp_image_description_info_v1" version="1">
<interface name="wp_image_description_info_v1" version="2">
<description summary="Colorimetric image description information">
Sends all matching events describing an image description object exactly
once and finally sends the 'done' event.
@@ -1628,4 +1703,22 @@
summary="Maximum frame-average light level (cd/m²)"/>
</event>
</interface>
<interface name="wp_image_description_reference_v1" version="1">
<description summary="Reference to an image description">
This object is a reference to an image description. This interface is
frozen at version 1 to allow other protocols to create
wp_image_description_v1 objects.
The wp_color_manager_v1.get_image_description request can be used to
retrieve the underlying image description.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the reference">
Destroy this object. This has no effect on the referenced image
description.
</description>
</request>
</interface>
</protocol>
libs/SDL3/wayland-protocols/pointer-gestures-unstable-v1.xml
+253
View File
@@ -0,0 +1,253 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="pointer_gestures_unstable_v1">
<interface name="zwp_pointer_gestures_v1" version="3">
<description summary="touchpad gestures">
A global interface to provide semantic touchpad gestures for a given
pointer.
Three gestures are currently supported: swipe, pinch, and hold.
Pinch and swipe gestures follow a three-stage cycle: begin, update,
end, hold gestures follow a two-stage cycle: begin and end. All
gestures are identified by a unique id.
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="get_swipe_gesture">
<description summary="get swipe gesture">
Create a swipe gesture object. See the
wl_pointer_gesture_swipe interface for details.
</description>
<arg name="id" type="new_id" interface="zwp_pointer_gesture_swipe_v1"/>
<arg name="pointer" type="object" interface="wl_pointer"/>
</request>
<request name="get_pinch_gesture">
<description summary="get pinch gesture">
Create a pinch gesture object. See the
wl_pointer_gesture_pinch interface for details.
</description>
<arg name="id" type="new_id" interface="zwp_pointer_gesture_pinch_v1"/>
<arg name="pointer" type="object" interface="wl_pointer"/>
</request>
<!-- Version 2 additions -->
<request name="release" type="destructor" since="2">
<description summary="destroy the pointer gesture object">
Destroy the pointer gesture object. Swipe, pinch and hold objects
created via this gesture object remain valid.
</description>
</request>
<!-- Version 3 additions -->
<request name="get_hold_gesture" since="3">
<description summary="get hold gesture">
Create a hold gesture object. See the
wl_pointer_gesture_hold interface for details.
</description>
<arg name="id" type="new_id" interface="zwp_pointer_gesture_hold_v1"/>
<arg name="pointer" type="object" interface="wl_pointer"/>
</request>
</interface>
<interface name="zwp_pointer_gesture_swipe_v1" version="2">
<description summary="a swipe gesture object">
A swipe gesture object notifies a client about a multi-finger swipe
gesture detected on an indirect input device such as a touchpad.
The gesture is usually initiated by multiple fingers moving in the
same direction but once initiated the direction may change.
The precise conditions of when such a gesture is detected are
implementation-dependent.
A gesture consists of three stages: begin, update (optional) and end.
There cannot be multiple simultaneous hold, pinch or swipe gestures on a
same pointer/seat, how compositors prevent these situations is
implementation-dependent.
A gesture may be cancelled by the compositor or the hardware.
Clients should not consider performing permanent or irreversible
actions until the end of a gesture has been received.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the pointer swipe gesture object"/>
</request>
<event name="begin">
<description summary="multi-finger swipe begin">
This event is sent when a multi-finger swipe gesture is detected
on the device.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="fingers" type="uint" summary="number of fingers"/>
</event>
<event name="update">
<description summary="multi-finger swipe motion">
This event is sent when a multi-finger swipe gesture changes the
position of the logical center.
The dx and dy coordinates are relative coordinates of the logical
center of the gesture compared to the previous event.
</description>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="dx" type="fixed" summary="delta x coordinate in surface coordinate space"/>
<arg name="dy" type="fixed" summary="delta y coordinate in surface coordinate space"/>
</event>
<event name="end">
<description summary="multi-finger swipe end">
This event is sent when a multi-finger swipe gesture ceases to
be valid. This may happen when one or more fingers are lifted or
the gesture is cancelled.
When a gesture is cancelled, the client should undo state changes
caused by this gesture. What causes a gesture to be cancelled is
implementation-dependent.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="cancelled" type="int" summary="1 if the gesture was cancelled, 0 otherwise"/>
</event>
</interface>
<interface name="zwp_pointer_gesture_pinch_v1" version="2">
<description summary="a pinch gesture object">
A pinch gesture object notifies a client about a multi-finger pinch
gesture detected on an indirect input device such as a touchpad.
The gesture is usually initiated by multiple fingers moving towards
each other or away from each other, or by two or more fingers rotating
around a logical center of gravity. The precise conditions of when
such a gesture is detected are implementation-dependent.
A gesture consists of three stages: begin, update (optional) and end.
There cannot be multiple simultaneous hold, pinch or swipe gestures on a
same pointer/seat, how compositors prevent these situations is
implementation-dependent.
A gesture may be cancelled by the compositor or the hardware.
Clients should not consider performing permanent or irreversible
actions until the end of a gesture has been received.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the pinch gesture object"/>
</request>
<event name="begin">
<description summary="multi-finger pinch begin">
This event is sent when a multi-finger pinch gesture is detected
on the device.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="fingers" type="uint" summary="number of fingers"/>
</event>
<event name="update">
<description summary="multi-finger pinch motion">
This event is sent when a multi-finger pinch gesture changes the
position of the logical center, the rotation or the relative scale.
The dx and dy coordinates are relative coordinates in the
surface coordinate space of the logical center of the gesture.
The scale factor is an absolute scale compared to the
pointer_gesture_pinch.begin event, e.g. a scale of 2 means the fingers
are now twice as far apart as on pointer_gesture_pinch.begin.
The rotation is the relative angle in degrees clockwise compared to the previous
pointer_gesture_pinch.begin or pointer_gesture_pinch.update event.
</description>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="dx" type="fixed" summary="delta x coordinate in surface coordinate space"/>
<arg name="dy" type="fixed" summary="delta y coordinate in surface coordinate space"/>
<arg name="scale" type="fixed" summary="scale relative to the initial finger position"/>
<arg name="rotation" type="fixed" summary="angle in degrees cw relative to the previous event"/>
</event>
<event name="end">
<description summary="multi-finger pinch end">
This event is sent when a multi-finger pinch gesture ceases to
be valid. This may happen when one or more fingers are lifted or
the gesture is cancelled.
When a gesture is cancelled, the client should undo state changes
caused by this gesture. What causes a gesture to be cancelled is
implementation-dependent.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="cancelled" type="int" summary="1 if the gesture was cancelled, 0 otherwise"/>
</event>
</interface>
<interface name="zwp_pointer_gesture_hold_v1" version="3">
<description summary="a hold gesture object">
A hold gesture object notifies a client about a single- or
multi-finger hold gesture detected on an indirect input device such as
a touchpad. The gesture is usually initiated by one or more fingers
being held down without significant movement. The precise conditions
of when such a gesture is detected are implementation-dependent.
In particular, this gesture may be used to cancel kinetic scrolling.
A hold gesture consists of two stages: begin and end. Unlike pinch and
swipe there is no update stage.
There cannot be multiple simultaneous hold, pinch or swipe gestures on a
same pointer/seat, how compositors prevent these situations is
implementation-dependent.
A gesture may be cancelled by the compositor or the hardware.
Clients should not consider performing permanent or irreversible
actions until the end of a gesture has been received.
</description>
<request name="destroy" type="destructor" since="3">
<description summary="destroy the hold gesture object"/>
</request>
<event name="begin" since="3">
<description summary="multi-finger hold begin">
This event is sent when a hold gesture is detected on the device.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="fingers" type="uint" summary="number of fingers"/>
</event>
<event name="end" since="3">
<description summary="multi-finger hold end">
This event is sent when a hold gesture ceases to
be valid. This may happen when the holding fingers are lifted or
the gesture is cancelled, for example if the fingers move past an
implementation-defined threshold, the finger count changes or the hold
gesture changes into a different type of gesture.
When a gesture is cancelled, the client may need to undo state changes
caused by this gesture. What causes a gesture to be cancelled is
implementation-dependent.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="cancelled" type="int" summary="1 if the gesture was cancelled, 0 otherwise"/>
</event>
</interface>
</protocol>
libs/SDL3/wayland-protocols/pointer-warp-v1.xml
+72
View File
@@ -0,0 +1,72 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="pointer_warp_v1">
<copyright>
Copyright © 2024 Neal Gompa
Copyright © 2024 Xaver Hugl
Copyright © 2024 Matthias Klumpp
Copyright © 2024 Vlad Zahorodnii
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_pointer_warp_v1" version="1">
<description summary="reposition the pointer to a location on a surface">
This global interface allows applications to request the pointer to be
moved to a position relative to a wl_surface.
Note that if the desired behavior is to constrain the pointer to an area
or lock it to a position, this protocol does not provide a reliable way
to do that. The pointer constraint and pointer lock protocols should be
used for those use cases instead.
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 warp manager">
Destroy the pointer warp manager.
</description>
</request>
<request name="warp_pointer">
<description summary="reposition the pointer">
Request the compositor to move the pointer to a surface-local position.
Whether or not the compositor honors the request is implementation defined,
but it should
- honor it if the surface has pointer focus, including
when it has an implicit pointer grab
- reject it if the enter serial is incorrect
- reject it if the requested position is outside of the surface
Note that the enter serial is valid for any surface of the client,
and does not have to be from the surface the pointer is warped to.
</description>
<arg name="surface" type="object" interface="wl_surface"
summary="surface to position the pointer on"/>
<arg name="pointer" type="object" interface="wl_pointer"
summary="the pointer that should be repositioned"/>
<arg name="x" type="fixed"/>
<arg name="y" type="fixed"/>
<arg name="serial" type="uint" summary="serial number of the enter event"/>
</request>
</interface>
</protocol>
libs/SDL3/wayland-protocols/wayland.xml
+220 -72
View File
@@ -46,7 +46,7 @@
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.
The callback_data passed in the callback is undefined and should be ignored.
</description>
<arg name="callback" type="new_id" interface="wl_callback"
summary="callback object for the sync request"/>
@@ -212,7 +212,7 @@
</request>
</interface>
<interface name="wl_shm_pool" version="1">
<interface name="wl_shm_pool" version="2">
<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
@@ -262,17 +262,17 @@
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.
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">
<interface name="wl_shm" version="2">
<description summary="shared memory support">
A singleton global object that provides support for shared
memory.
@@ -419,6 +419,21 @@
<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"/>
<entry name="c1" value="0x20203143" summary="[7:0] C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight pixels/byte"/>
<entry name="c2" value="0x20203243" summary="[7:0] C0:C1:C2:C3 2:2:2:2 four pixels/byte"/>
<entry name="c4" value="0x20203443" summary="[7:0] C0:C1 4:4 two pixels/byte"/>
<entry name="d1" value="0x20203144" summary="[7:0] D0:D1:D2:D3:D4:D5:D6:D7 1:1:1:1:1:1:1:1 eight pixels/byte"/>
<entry name="d2" value="0x20203244" summary="[7:0] D0:D1:D2:D3 2:2:2:2 four pixels/byte"/>
<entry name="d4" value="0x20203444" summary="[7:0] D0:D1 4:4 two pixels/byte"/>
<entry name="d8" value="0x20203844" summary="[7:0] D"/>
<entry name="r1" value="0x20203152" summary="[7:0] R0:R1:R2:R3:R4:R5:R6:R7 1:1:1:1:1:1:1:1 eight pixels/byte"/>
<entry name="r2" value="0x20203252" summary="[7:0] R0:R1:R2:R3 2:2:2:2 four pixels/byte"/>
<entry name="r4" value="0x20203452" summary="[7:0] R0:R1 4:4 two pixels/byte"/>
<entry name="r10" value="0x20303152" summary="[15:0] x:R 6:10 little endian"/>
<entry name="r12" value="0x20323152" summary="[15:0] x:R 4:12 little endian"/>
<entry name="avuy8888" value="0x59555641" summary="[31:0] A:Cr:Cb:Y 8:8:8:8 little endian"/>
<entry name="xvuy8888" value="0x59555658" summary="[31:0] X:Cr:Cb:Y 8:8:8:8 little endian"/>
<entry name="p030" value="0x30333050" summary="2x2 subsampled Cr:Cb plane 10 bits per channel packed"/>
</enum>
<request name="create_pool">
@@ -442,6 +457,17 @@
</description>
<arg name="format" type="uint" enum="format" summary="buffer pixel format"/>
</event>
<!-- Version 2 additions -->
<request name="release" type="destructor" since="2">
<description summary="release the shm object">
Using this request a client can tell the server that it is not going to
use the shm object anymore.
Objects created via this interface remain unaffected.
</description>
</request>
</interface>
<interface name="wl_buffer" version="1">
@@ -453,9 +479,11 @@
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.
Color channels are assumed to be electrical rather than optical (in other
words, encoded with a transfer function) unless otherwise specified. If
the buffer uses a format that has an alpha channel, the alpha channel is
assumed to be premultiplied into the electrical color channel values
(after transfer function encoding) unless otherwise specified.
Note, because wl_buffer objects are created from multiple independent
factory interfaces, the wl_buffer interface is frozen at version 1.
@@ -473,8 +501,10 @@
<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.
For more information on when release events may or may not be sent,
and what consequences it has, please see the description of
wl_surface.attach.
If a client receives a release event before the frame callback
requested in the same wl_surface.commit that attaches this
@@ -847,6 +877,7 @@
<enum name="error">
<entry name="role" value="0" summary="given wl_surface has another role"/>
<entry name="used_source" value="1" summary="source has already been used"/>
</enum>
<request name="start_drag">
@@ -868,7 +899,7 @@
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
hotspot, but subsequent wl_surface.offset requests 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,
@@ -876,6 +907,10 @@
The input region is ignored for wl_surfaces with the role of a
drag-and-drop icon.
The given source may not be used in any further set_selection or
start_drag requests. Attempting to reuse a previously-used source
may send a used_source error.
</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"/>
@@ -889,6 +924,10 @@
to the data from the source on behalf of the client.
To unset the selection, set the source to NULL.
The given source may not be used in any further set_selection or
start_drag requests. Attempting to reuse a previously-used source
may send a used_source error.
</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"/>
@@ -1411,7 +1450,7 @@
<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"/>
summary="surface was destroyed before its role object"/>
</enum>
<request name="destroy" type="destructor">
@@ -1440,9 +1479,9 @@
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.
'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.
@@ -1467,7 +1506,8 @@
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.
from the same backing storage or use a protocol extension providing
per-commit release notifications.
Destroying the wl_buffer after wl_buffer.release does not change
the surface contents. Destroying the wl_buffer before wl_buffer.release
@@ -1479,6 +1519,13 @@
If wl_surface.attach is sent with a NULL wl_buffer, the
following wl_surface.commit will remove the surface content.
If a pending wl_buffer has been destroyed, the result is not specified.
Many compositors are known to remove the surface content on the following
wl_surface.commit, but this behaviour is not universal. Clients seeking to
maximise compatibility should not destroy pending buffers and should
ensure that they explicitly remove content from surfaces, even after
destroying buffers.
</description>
<arg name="buffer" type="object" interface="wl_buffer" allow-null="true"
summary="buffer of surface contents"/>
@@ -1618,16 +1665,18 @@
<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.
as opposed to the active state in use by the compositor.
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.
A commit request atomically creates a content update from the pending
state, even if the pending state has not been touched. The content
update is placed in a queue until it becomes active. After commit, the
new pending state is as documented for each related request.
When the content update is applied, the wl_buffer is applied before all
other state. This means that all coordinates in double-buffered state
are relative to the newly attached wl_buffers, except for
wl_surface.attach itself. If there is no newly attached wl_buffer, the
coordinates are relative to the previous content update.
All requests that need a commit to become effective are documented
to affect double-buffered state.
@@ -1666,10 +1715,12 @@
<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.
This request sets the transformation that the client has already applied
to the content of the buffer. The accepted values for the transform
parameter are the values for wl_output.transform.
The compositor applies the inverse of this transformation whenever it
uses the buffer contents.
Buffer transform is double-buffered state, see wl_surface.commit.
@@ -1725,11 +1776,11 @@
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
If scale is not greater than 0 the invalid_scale protocol error is
raised.
</description>
<arg name="scale" type="int"
summary="positive scale for interpreting buffer contents"/>
summary="scale for interpreting buffer contents"/>
</request>
<!-- Version 4 additions -->
@@ -1784,6 +1835,9 @@
x and y, combined with the new surface size define in which
directions the surface's size changes.
The exact semantics of wl_surface.offset are role-specific. Refer to
the documentation of specific roles for more information.
Surface location offset is double-buffered state, see
wl_surface.commit.
@@ -1802,10 +1856,15 @@
This event indicates the preferred buffer scale for this surface. It is
sent whenever the compositor's preference changes.
Before receiving this event the preferred buffer scale for this surface
is 1.
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.
The compositor shall emit a scale value greater than 0.
</description>
<arg name="factor" type="int" summary="preferred scaling factor"/>
</event>
@@ -1815,16 +1874,19 @@
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.
Before receiving this event the preferred buffer transform for this
surface is normal.
Applying this transformation to the surface buffer contents and using
wl_surface.set_buffer_transform might allow the compositor to use the
surface buffer more efficiently.
</description>
<arg name="transform" type="uint" enum="wl_output.transform"
summary="preferred transform"/>
</event>
</interface>
<interface name="wl_seat" version="9">
<interface name="wl_seat" version="10">
<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
@@ -1852,9 +1914,10 @@
<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.
This is sent on binding to the seat global or 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
@@ -1936,9 +1999,9 @@
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.
The name event is sent after binding to the seat global, and should be sent
before announcing capabilities. This event 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.
@@ -1957,7 +2020,7 @@
</interface>
<interface name="wl_pointer" version="9">
<interface name="wl_pointer" version="10">
<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
@@ -1992,9 +2055,9 @@
where (x, y) are the coordinates of the pointer location, in
surface-local coordinates.
On surface.attach requests to the pointer surface, hotspot_x
On wl_surface.offset 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
passed to the request. The offset must be applied by
wl_surface.commit as usual.
The hotspot can also be updated by passing the currently set
@@ -2248,7 +2311,7 @@
<arg name="axis" type="uint" enum="axis" summary="the axis stopped with this event"/>
</event>
<event name="axis_discrete" since="5">
<event name="axis_discrete" since="5" deprecated-since="8">
<description summary="axis click event">
Discrete step information for scroll and other axes.
@@ -2370,10 +2433,20 @@
</event>
</interface>
<interface name="wl_keyboard" version="9">
<interface name="wl_keyboard" version="10">
<description summary="keyboard input device">
The wl_keyboard interface represents one or more keyboards
associated with a seat.
Each wl_keyboard has the following logical state:
- an active surface (possibly null),
- the keys currently logically down,
- the active modifiers,
- the active group.
By default, the active surface is null, the keys currently logically down
are empty, the active modifiers and the active group are 0.
</description>
<enum name="keymap_format">
@@ -2408,10 +2481,18 @@
The compositor must send the wl_keyboard.modifiers event after this
event.
In the wl_keyboard logical state, this event sets the active surface to
the surface argument and the keys currently logically down to the keys
in the keys argument. The compositor must not send this event if the
wl_keyboard already had an active surface immediately before this event.
Clients should not use the list of pressed keys to emulate key-press
events. The order of keys in the list is unspecified.
</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"/>
<arg name="keys" type="array" summary="the keys currently logically down"/>
</event>
<event name="leave">
@@ -2422,8 +2503,10 @@
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.
In the wl_keyboard logical state, this event resets all values to their
defaults. The compositor must not send this event if the active surface
of the wl_keyboard was not equal to the surface argument immediately
before this event.
</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"/>
@@ -2432,9 +2515,18 @@
<enum name="key_state">
<description summary="physical key state">
Describes the physical state of a key that produced the key event.
Since version 10, the key can be in a "repeated" pseudo-state which
means the same as "pressed", but is used to signal repetition in the
key event.
The key may only enter the repeated state after entering the pressed
state and before entering the released state. This event may be
generated multiple times while the key is down.
</description>
<entry name="released" value="0" summary="key is not pressed"/>
<entry name="pressed" value="1" summary="key is pressed"/>
<entry name="repeated" value="2" summary="key was repeated" since="10"/>
</enum>
<event name="key">
@@ -2448,6 +2540,20 @@
If this event produces a change in modifiers, then the resulting
wl_keyboard.modifiers event must be sent after this event.
In the wl_keyboard logical state, this event adds the key to the keys
currently logically down (if the state argument is pressed) or removes
the key from the keys currently logically down (if the state argument is
released). The compositor must not send this event if the wl_keyboard
did not have an active surface immediately before this event. The
compositor must not send this event if state is pressed (resp. released)
and the key was already logically down (resp. was not logically down)
immediately before this event.
Since version 10, compositors may send key events with the "repeated"
key state when a wl_keyboard.repeat_info event with a rate argument of
0 has been received. This allows the compositor to take over the
responsibility of key repetition.
</description>
<arg name="serial" type="uint" summary="serial number of the key event"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
@@ -2459,6 +2565,17 @@
<description summary="modifier and group state">
Notifies clients that the modifier and/or group state has
changed, and it should update its local state.
The compositor may send this event without a surface of the client
having keyboard focus, for example to tie modifier information to
pointer focus instead. If a modifier event with pressed modifiers is sent
without a prior enter event, the client can assume the modifier state is
valid until it receives the next wl_keyboard.modifiers event. In order to
reset the modifier state again, the compositor can send a
wl_keyboard.modifiers event with no pressed modifiers.
In the wl_keyboard logical state, this event updates the modifiers and
group.
</description>
<arg name="serial" type="uint" summary="serial number of the modifiers event"/>
<arg name="mods_depressed" type="uint" summary="depressed modifiers"/>
@@ -2497,7 +2614,7 @@
</event>
</interface>
<interface name="wl_touch" version="9">
<interface name="wl_touch" version="10">
<description summary="touchscreen input device">
The wl_touch interface represents a touchscreen
associated with a seat.
@@ -2566,6 +2683,8 @@
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.
No frame event is required after the cancel event.
</description>
</event>
@@ -2665,10 +2784,9 @@
</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.
<description summary="transformation applied to buffer contents">
This describes transformations that clients and compositors apply to
buffer contents.
The flipped values correspond to an initial flip around a
vertical axis followed by rotation.
@@ -2700,6 +2818,10 @@
The geometry event will be followed by a done event (starting from
version 2).
Clients should use wl_surface.preferred_buffer_transform instead of the
transform advertised by this event to find the preferred buffer
transform to use for a surface.
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
@@ -2722,7 +2844,7 @@
<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"/>
summary="additional transformation applied to buffer contents during presentation"/>
</event>
<enum name="mode" bitfield="true">
@@ -2795,8 +2917,9 @@
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.
later. The compositor will emit a non-zero, positive
value for scale. 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
@@ -2804,12 +2927,9 @@
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.
Clients should use wl_surface.preferred_buffer_scale
instead of this event to find the preferred buffer
scale to use for a surface.
The scale event will be followed by a done event.
</description>
@@ -3035,6 +3155,11 @@
If the parent wl_surface object is destroyed, the sub-surface is
unmapped.
A sub-surface never has the keyboard focus of any seat.
The wl_surface.offset request is ignored: clients must use set_position
instead to move the sub-surface.
</description>
<request name="destroy" type="destructor">
@@ -3060,9 +3185,7 @@
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.
parent surface is applied.
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
@@ -3085,9 +3208,7 @@
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.
surface is applied.
A new sub-surface is initially added as the top-most in the stack
of its siblings and parent.
@@ -3148,4 +3269,31 @@
</request>
</interface>
<interface name="wl_fixes" version="1">
<description summary="wayland protocol fixes">
This global fixes problems with other core-protocol interfaces that
cannot be fixed in these interfaces themselves.
</description>
<request name="destroy" type="destructor">
<description summary="destroys this object"/>
</request>
<request name="destroy_registry">
<description summary="destroy a wl_registry">
This request destroys a wl_registry object.
The client should no longer use the wl_registry after making this
request.
The compositor will emit a wl_display.delete_id event with the object ID
of the registry and will no longer emit any events on the registry. The
client should re-use the object ID once it receives the
wl_display.delete_id event.
</description>
<arg name="registry" type="object" interface="wl_registry"
summary="the registry to destroy"/>
</request>
</interface>
</protocol>
libs/SDL3/wayland-protocols/xdg-shell.xml
+61 -16
View File
@@ -29,7 +29,7 @@
DEALINGS IN THE SOFTWARE.
</copyright>
<interface name="xdg_wm_base" version="6">
<interface name="xdg_wm_base" version="7">
<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
@@ -122,7 +122,7 @@
</event>
</interface>
<interface name="xdg_positioner" version="6">
<interface name="xdg_positioner" version="7">
<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
@@ -344,7 +344,7 @@
The default adjustment is none.
</description>
<arg name="constraint_adjustment" type="uint"
<arg name="constraint_adjustment" type="uint" enum="constraint_adjustment"
summary="bit mask of constraint adjustments"/>
</request>
@@ -407,7 +407,7 @@
</request>
</interface>
<interface name="xdg_surface" version="6">
<interface name="xdg_surface" version="7">
<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.
@@ -434,7 +434,8 @@
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
After creating a role-specific object and setting it up (e.g. by sending
the title, app ID, size constraints, parent, etc), 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
@@ -515,8 +516,7 @@
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.
The window geometry is double-buffered state, see wl_surface.commit.
When maintaining a position, the compositor should treat the (x, y)
coordinate of the window geometry as the top left corner of the window.
@@ -617,7 +617,7 @@
</interface>
<interface name="xdg_toplevel" version="6">
<interface name="xdg_toplevel" version="7">
<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,
@@ -625,13 +625,17 @@
id, and well as trigger user interactive operations such as interactive
resize and move.
A xdg_toplevel by default is responsible for providing the full intended
visual representation of the toplevel, which depending on the window
state, may mean things like a title bar, window controls and drop shadow.
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
can re-map the toplevel by performing a commit without any buffer
attached, waiting for a configure event and handling it as usual (see
xdg_surface description).
@@ -828,8 +832,7 @@
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.
States set in this way are double-buffered, see wl_surface.commit.
</description>
<entry name="maximized" value="1" summary="the surface is maximized">
<description summary="the surface is maximized">
@@ -869,24 +872,36 @@
<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.
The client should draw without shadow or other decoration outside of
the window geometry on the left edge.
</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.
The client should draw without shadow or other decoration outside of
the window geometry on the right edge.
</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.
The client should draw without shadow or other decoration outside of
the window geometry on the top edge.
</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.
The client should draw without shadow or other decoration outside of
the window geometry on the bottom edge.
</description>
</entry>
<entry name="suspended" value="9" since="6">
@@ -896,6 +911,38 @@
outputs are switched off due to screen locking.
</description>
</entry>
<entry name="constrained_left" value="10" since="7">
<description summary="the surface’s left edge is constrained">
The left edge of the window is currently constrained, meaning it
shouldn't attempt to resize from that edge. It can for example mean
it's tiled next to a monitor edge on the constrained side of the
window.
</description>
</entry>
<entry name="constrained_right" value="11" since="7">
<description summary="the surface’s right edge is constrained">
The right edge of the window is currently constrained, meaning it
shouldn't attempt to resize from that edge. It can for example mean
it's tiled next to a monitor edge on the constrained side of the
window.
</description>
</entry>
<entry name="constrained_top" value="12" since="7">
<description summary="the surface’s top edge is constrained">
The top edge of the window is currently constrained, meaning it
shouldn't attempt to resize from that edge. It can for example mean
it's tiled next to a monitor edge on the constrained side of the
window.
</description>
</entry>
<entry name="constrained_bottom" value="13" since="7">
<description summary="the surface’s bottom edge is tiled">
The bottom edge of the window is currently constrained, meaning it
shouldn't attempt to resize from that edge. It can for example mean
it's tiled next to a monitor edge on the constrained side of the
window.
</description>
</entry>
</enum>
<request name="set_max_size">
@@ -908,8 +955,7 @@
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.
Values set in this way are double-buffered, see wl_surface.commit.
The compositor can use this information to allow or disallow
different states like maximize or fullscreen and draw accurate
@@ -949,8 +995,7 @@
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.
Values set in this way are double-buffered, see wl_surface.commit.
The compositor can use this information to allow or disallow
different states like maximize or fullscreen and draw accurate
@@ -1194,7 +1239,7 @@
</event>
</interface>
<interface name="xdg_popup" version="6">
<interface name="xdg_popup" version="7">
<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