diff options
Diffstat (limited to 'src/3rdparty/protocol')
18 files changed, 4372 insertions, 826 deletions
diff --git a/src/3rdparty/protocol/cursor-shape-v1.xml b/src/3rdparty/protocol/cursor-shape-v1.xml new file mode 100644 index 000000000..b6fbe08b7 --- /dev/null +++ b/src/3rdparty/protocol/cursor-shape-v1.xml @@ -0,0 +1,146 @@ +<?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 allows clients to set cursor images by name instead of + creating and attaching buffers. + + 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/3rdparty/protocol/fractional-scale-v1.xml b/src/3rdparty/protocol/fractional-scale-v1.xml new file mode 100644 index 000000000..350bfc01e --- /dev/null +++ b/src/3rdparty/protocol/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/3rdparty/protocol/linux-dmabuf-unstable-v1.xml b/src/3rdparty/protocol/linux-dmabuf-unstable-v1.xml index 154afe23e..b43e81ca0 100644 --- a/src/3rdparty/protocol/linux-dmabuf-unstable-v1.xml +++ b/src/3rdparty/protocol/linux-dmabuf-unstable-v1.xml @@ -28,6 +28,7 @@ <description summary="factory for creating dmabuf-based wl_buffers"> Following the interfaces from: https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt + https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt and the Linux DRM sub-system's AddFb2 ioctl. This interface offers ways to create generic dmabuf-based @@ -129,8 +130,16 @@ binds to this interface. A roundtrip after binding guarantees that the client has received all supported format-modifier pairs. + For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi == + 0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event. + It indicates that the server can support the format with an implicit + modifier. When a plane has DRM_FORMAT_MOD_INVALID as its modifier, it + is as if no explicit modifier is specified. The effective modifier + will be derived from the dmabuf. + For the definition of the format and modifier codes, see the - zwp_linux_buffer_params_v1::create request. + zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add + requests. </description> <arg name="format" type="uint" summary="DRM_FORMAT code"/> <arg name="modifier_hi" type="uint" @@ -197,6 +206,11 @@ compression, etc. driver-specific modifications to the base format defined by the DRM fourcc code. + Warning: It should be an error if the format/modifier pair was not + advertised with the modifier event. This is not enforced yet because + some implementations always accept DRM_FORMAT_MOD_INVALID. Also + version 2 of this protocol does not have the modifier event. + This request raises the PLANE_IDX error if plane_idx is too large. The error PLANE_SET is raised if attempting to set a plane that was already set. diff --git a/src/3rdparty/protocol/pointer-gestures-unstable-v1.xml b/src/3rdparty/protocol/pointer-gestures-unstable-v1.xml new file mode 100644 index 000000000..59502ac11 --- /dev/null +++ b/src/3rdparty/protocol/pointer-gestures-unstable-v1.xml @@ -0,0 +1,186 @@ +<?xml version="1.0" encoding="UTF-8"?> +<protocol name="pointer_gestures_unstable_v1"> + + <interface name="zwp_pointer_gestures_v1" version="2"> + <description summary="touchpad gestures"> + A global interface to provide semantic touchpad gestures for a given + pointer. + + Two gestures are currently supported: swipe and zoom/rotate. + All gestures follow a three-stage cycle: begin, update, end and + 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 and pinch objects created via this + gesture object remain valid. + </description> + </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 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 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> + +</protocol> diff --git a/src/3rdparty/protocol/presentation-time.xml b/src/3rdparty/protocol/presentation-time.xml new file mode 100644 index 000000000..d1731f036 --- /dev/null +++ b/src/3rdparty/protocol/presentation-time.xml @@ -0,0 +1,266 @@ +<?xml version="1.0" encoding="UTF-8"?> +<protocol name="presentation_time"> +<!-- wrap:70 --> + + <copyright> + Copyright © 2013-2014 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_presentation" version="1"> + <description summary="timed presentation related wl_surface requests"> + +<!-- Introduction --> + + The main feature of this interface is accurate presentation + timing feedback to ensure smooth video playback while maintaining + audio/video synchronization. Some features use the concept of a + presentation clock, which is defined in the + presentation.clock_id event. + + A content update for a wl_surface is submitted by a + wl_surface.commit request. Request 'feedback' associates with + the wl_surface.commit and provides feedback on the content + update, particularly the final realized presentation time. + +<!-- Completing presentation --> + + When the final realized presentation time is available, e.g. + after a framebuffer flip completes, the requested + presentation_feedback.presented events are sent. The final + presentation time can differ from the compositor's predicted + display update time and the update's target time, especially + when the compositor misses its target vertical blanking period. + </description> + + <enum name="error"> + <description summary="fatal presentation errors"> + These fatal protocol errors may be emitted in response to + illegal presentation requests. + </description> + <entry name="invalid_timestamp" value="0" + summary="invalid value in tv_nsec"/> + <entry name="invalid_flag" value="1" + summary="invalid flag"/> + </enum> + + <request name="destroy" type="destructor"> + <description summary="unbind from the presentation interface"> + 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="feedback"> + <description summary="request presentation feedback information"> + Request presentation feedback for the current content submission + on the given surface. This creates a new presentation_feedback + object, which will deliver the feedback information once. If + multiple presentation_feedback objects are created for the same + submission, they will all deliver the same information. + + For details on what information is returned, see the + presentation_feedback interface. + </description> + <arg name="surface" type="object" interface="wl_surface" + summary="target surface"/> + <arg name="callback" type="new_id" interface="wp_presentation_feedback" + summary="new feedback object"/> + </request> + + <event name="clock_id"> + <description summary="clock ID for timestamps"> + This event tells the client in which clock domain the + compositor interprets the timestamps used by the presentation + extension. This clock is called the presentation clock. + + The compositor sends this event when the client binds to the + presentation interface. The presentation clock does not change + during the lifetime of the client connection. + + The clock identifier is platform dependent. On Linux/glibc, + the identifier value is one of the clockid_t values accepted + by clock_gettime(). clock_gettime() is defined by + POSIX.1-2001. + + Timestamps in this clock domain are 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]. + + Note that clock_id applies only to the presentation clock, + and implies nothing about e.g. the timestamps used in the + Wayland core protocol input events. + + Compositors should prefer a clock which does not jump and is + not slewed e.g. by NTP. The absolute value of the clock is + irrelevant. Precision of one millisecond or better is + recommended. Clients must be able to query the current clock + value directly, not by asking the compositor. + </description> + <arg name="clk_id" type="uint" summary="platform clock identifier"/> + </event> + + </interface> + + <interface name="wp_presentation_feedback" version="1"> + <description summary="presentation time feedback event"> + A presentation_feedback object returns an indication that a + wl_surface content update has become visible to the user. + One object corresponds to one content update submission + (wl_surface.commit). There are two possible outcomes: the + content update is presented to the user, and a presentation + timestamp delivered; or, the user did not see the content + update because it was superseded or its surface destroyed, + and the content update is discarded. + + Once a presentation_feedback object has delivered a 'presented' + or 'discarded' event it is automatically destroyed. + </description> + + <event name="sync_output"> + <description summary="presentation synchronized to this output"> + As presentation can be synchronized to only one output at a + time, this event tells which output it was. This event is only + sent prior to the presented event. + + As clients may bind to the same global wl_output multiple + times, this event is sent for each bound instance that matches + the synchronized output. If a client has not bound to the + right wl_output global at all, this event is not sent. + </description> + <arg name="output" type="object" interface="wl_output" + summary="presentation output"/> + </event> + + <enum name="kind" bitfield="true"> + <description summary="bitmask of flags in presented event"> + These flags provide information about how the presentation of + the related content update was done. The intent is to help + clients assess the reliability of the feedback and the visual + quality with respect to possible tearing and timings. The + flags are: + + VSYNC: + The presentation was synchronized to the "vertical retrace" by + the display hardware such that tearing does not happen. + Relying on user space scheduling is not acceptable for this + flag. If presentation is done by a copy to the active + frontbuffer, then it must guarantee that tearing cannot + happen. + + HW_CLOCK: + The display hardware provided measurements that the hardware + driver converted into a presentation timestamp. Sampling a + clock in user space is not acceptable for this flag. + + HW_COMPLETION: + The display hardware signalled that it started using the new + image content. The opposite of this is e.g. a timer being used + to guess when the display hardware has switched to the new + image content. + + ZERO_COPY: + The presentation of this update was done zero-copy. This means + the buffer from the client was given to display hardware as + is, without copying it. Compositing with OpenGL counts as + copying, even if textured directly from the client buffer. + Possible zero-copy cases include direct scanout of a + fullscreen surface and a surface on a hardware overlay. + </description> + <entry name="vsync" value="0x1" summary="presentation was vsync'd"/> + <entry name="hw_clock" value="0x2" + summary="hardware provided the presentation timestamp"/> + <entry name="hw_completion" value="0x4" + summary="hardware signalled the start of the presentation"/> + <entry name="zero_copy" value="0x8" + summary="presentation was done zero-copy"/> + </enum> + + <event name="presented"> + <description summary="the content update was displayed"> + The associated content update was displayed to the user at the + indicated time (tv_sec_hi/lo, tv_nsec). For the interpretation of + the timestamp, see presentation.clock_id event. + + The timestamp corresponds to the time when the content update + turned into light the first time on the surface's main output. + Compositors may approximate this from the framebuffer flip + completion events from the system, and the latency of the + physical display path if known. + + This event is preceded by all related sync_output events + telling which output's refresh cycle the feedback corresponds + to, i.e. the main output for the surface. Compositors are + recommended to choose the output containing the largest part + of the wl_surface, or keeping the output they previously + chose. Having a stable presentation output association helps + clients predict future output refreshes (vblank). + + The 'refresh' argument gives the compositor's prediction of how + many nanoseconds after tv_sec, tv_nsec the very next output + refresh may occur. This is to further aid clients in + predicting future refreshes, i.e., estimating the timestamps + targeting the next few vblanks. If such prediction cannot + usefully be done, the argument is zero. + + If the output does not have a constant refresh rate, explicit + video mode switches excluded, then the refresh argument must + be zero. + + The 64-bit value combined from seq_hi and seq_lo is the value + of the output's vertical retrace counter when the content + update was first scanned out to the display. This value must + be compatible with the definition of MSC in + GLX_OML_sync_control specification. Note, that if the display + path has a non-zero latency, the time instant specified by + this counter may differ from the timestamp's. + + If the output does not have a concept of vertical retrace or a + refresh cycle, or the output device is self-refreshing without + a way to query the refresh count, then the arguments seq_hi + and seq_lo must be zero. + </description> + <arg name="tv_sec_hi" type="uint" + summary="high 32 bits of the seconds part of the presentation timestamp"/> + <arg name="tv_sec_lo" type="uint" + summary="low 32 bits of the seconds part of the presentation timestamp"/> + <arg name="tv_nsec" type="uint" + summary="nanoseconds part of the presentation timestamp"/> + <arg name="refresh" type="uint" summary="nanoseconds till next refresh"/> + <arg name="seq_hi" type="uint" + summary="high 32 bits of refresh counter"/> + <arg name="seq_lo" type="uint" + summary="low 32 bits of refresh counter"/> + <arg name="flags" type="uint" enum="kind" summary="combination of 'kind' values"/> + </event> + + <event name="discarded"> + <description summary="the content update was not displayed"> + The content update was never displayed to the user. + </description> + </event> + </interface> + +</protocol> diff --git a/src/3rdparty/protocol/qt_attribution.json b/src/3rdparty/protocol/qt_attribution.json index c49ead4f3..6ced46a2b 100644 --- a/src/3rdparty/protocol/qt_attribution.json +++ b/src/3rdparty/protocol/qt_attribution.json @@ -9,13 +9,11 @@ "Description": "A Wayland shell for displaying a single surface per output", "Homepage": "https://wayland.freedesktop.org", "Version": "unstable v1", - "DownloadLocation": "https://cgit.freedesktop.org/wayland/wayland-protocols", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/raw/1.18/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml", "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", - "Copyright": "Copyright © 2016 Yong Bakos -Copyright © 2015 Jason Ekstrand -Copyright © 2015 Jonas Ådahl" + "Copyright": "Copyright © 2016 Yong Bakos\nCopyright © 2015 Jason Ekstrand\nCopyright © 2015 Jonas Ådahl" }, { @@ -27,14 +25,12 @@ Copyright © 2015 Jonas Ådahl" "Description": "Wayland is a protocol for a compositor to talk to its clients.", "Homepage": "https://wayland.freedesktop.org", - "Version": "1.16.0", - "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland/raw/1.16.0/protocol/wayland.xml", + "Version": "1.19.0", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland/raw/1.19.0/protocol/wayland.xml", "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", - "Copyright": "Copyright © 2008-2011 Kristian Høgsberg -Copyright © 2010-2011 Intel Corporation -Copyright © 2012-2013 Collabora, Ltd." + "Copyright": "Copyright © 2008-2011 Kristian Høgsberg\nCopyright © 2010-2011 Intel Corporation\nCopyright © 2012-2013 Collabora, Ltd." }, { @@ -51,8 +47,24 @@ Copyright © 2012-2013 Collabora, Ltd." "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", - "Copyright": "Copyright (C) 2013 DENSO CORPORATION -Copyright (c) 2013 BMW Car IT GmbH" + "Copyright": "Copyright (C) 2013 DENSO CORPORATION\nCopyright (c) 2013 BMW Car IT GmbH" + }, + + { + "Id": "wayland-pointer-gestures-protocol", + "Name": "Wayland Pointer Gestures Protocol", + "QDocModule": "qtwaylandcompositor", + "QtUsage": "Used in the Qt Wayland platform plugin", + "Files": "pointer-gestures-unstable-v1.xml", + + "Description": "", + "Homepage": "https://wayland.freedesktop.org", + "Version": "unstable v1, version 2", + "DownloadLocation": "https://cgit.freedesktop.org/wayland/wayland-protocols/plain/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml", + "LicenseId": "MIT", + "License": "MIT License", + "LicenseFile": "MIT_LICENSE.txt", + "Copyright": "Copyright © 2015, 2016 Red Hat" }, { @@ -65,11 +77,11 @@ Copyright (c) 2013 BMW Car IT GmbH" "Description": "The primary selection extension allows copying text by selecting it and pasting it with the middle mouse button.", "Homepage": "https://wayland.freedesktop.org", "Version": "1", - "DownloadLocation": "https://cgit.freedesktop.org/wayland/wayland-protocols/plain/unstable/primary-selection/primary-selection-unstable-v1.xml", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/raw/1.18/unstable/primary-selection/primary-selection-unstable-v1.xml", "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", - "Copyright": "Copyright © 2015 2016 Red Hat" + "Copyright": "Copyright © 2015, 2016 Red Hat" }, { @@ -82,7 +94,7 @@ Copyright (c) 2013 BMW Car IT GmbH" "Description": "The Wayland scaler extension allows a client to scale or crop a surface without modifying the buffer", "Homepage": "https://wayland.freedesktop.org", "Version": "2", - "DownloadLocation": "https://cgit.freedesktop.org/wayland/weston/plain/protocol/scaler.xml?h=1.11.1", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/weston/raw/1.11/protocol/scaler.xml", "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", @@ -90,6 +102,39 @@ Copyright (c) 2013 BMW Car IT GmbH" }, { + "Id": "wayland-tablet-protocol", + "Name": "Wayland Tablet Protocol", + "QDocModule": "qtwaylandcompositor", + "QtUsage": "Used in the Qt Wayland platform plugin", + "Files": "tablet-unstable-v2.xml", + + "Description": "", + "Homepage": "https://wayland.freedesktop.org", + "Version": "unstable v2, version 1", + "DownloadLocation": "https://cgit.freedesktop.org/wayland/wayland-protocols/plain/unstable/tablet/tablet-unstable-v2.xml", + "LicenseId": "MIT", + "License": "MIT License", + "LicenseFile": "MIT_LICENSE.txt", + "Copyright": "Copyright 2014 © Stephen \"Lyude\" Chandler Paul\nCopyright 2015-2016 © Red Hat, Inc." + }, + + { + "Id": "wayland-text-input-unstable-v3", + "Name": "Wayland Text Input Protocol", + "QDocModule": "qtwaylandcompositor", + "QtUsage": "Used in the Qt Wayland Compositor, and the Qt Wayland platform plugin.", + "Files": "text-input-unstable-v3.xml", + "Description": "Adds support for compositors to act as input methods and send text to applications.", + "Homepage": "https://wayland.freedesktop.org", + "Version": "unstable v3", + "DownloadLocation": "https://cgit.freedesktop.org/wayland/wayland-protocols/plain/unstable/text-input/text-input-unstable-v3.xml", + "LicenseId": "MIT", + "License": "MIT License", + "LicenseFile": "MIT_LICENSE.txt", + "Copyright": "Copyright © 2012, 2013 Intel Corporation\nCopyright © 2015, 2016 Jan Arne Petersen\nCopyright © 2017, 2018 Red Hat, Inc.\nCopyright © 2018 Purism SPC" + }, + + { "Id": "wayland-viewporter-protocol", "Name": "Wayland Viewporter Protocol", "QDocModule": "qtwaylandcompositor", @@ -99,7 +144,7 @@ Copyright (c) 2013 BMW Car IT GmbH" "Description": "The Wayland viewporter extension allows a client to scale or crop a surface without modifying the buffer", "Homepage": "https://wayland.freedesktop.org", "Version": "1", - "DownloadLocation": "https://cgit.freedesktop.org/wayland/wayland-protocols/plain/stable/viewporter/viewporter.xml", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/raw/1.18/stable/viewporter/viewporter.xml", "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", @@ -107,6 +152,24 @@ Copyright (c) 2013 BMW Car IT GmbH" }, { + "Id": "wayland-xdg-activation", + "Name": "Wayland xdg-activation Protocol", + "QDocModule": "qtwaylandcompositor", + "QtUsage": "Used in the Qt Wayland platform plugin", + "Files": "xdg-activation-v1.xml", + + "Description": "The xdg-activation protocol provides a way for one client to pass focus to another.", + "Homepage": "https://wayland.freedesktop.org", + "Version": "unstable v1, version 1", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/xdg-activation/xdg-activation-v1.xml", + "LicenseId": "MIT", + "License": "MIT License", + "LicenseFile": "MIT_LICENSE.txt", + "Copyright": "Copyright © 2020 Aleix Pol Gonzalez <aleixpol@kde.org>\nCopyright © 2020 Carlos Garnacho <carlosg@gnome.org>" + + }, + + { "Id": "wayland-xdg-decoration-protocol", "Name": "Wayland xdg-decoration Protocol", "QDocModule": "qtwaylandcompositor", @@ -116,7 +179,7 @@ Copyright (c) 2013 BMW Car IT GmbH" "Description": "The xdg-decoration protocol allows a compositor to announce support for server-side decorations.", "Homepage": "https://wayland.freedesktop.org", "Version": "unstable v1, version 1", - "DownloadLocation": "https://cgit.freedesktop.org/wayland/wayland-protocols/plain/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml?h=1.16", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/raw/1.18/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml", "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", @@ -132,8 +195,8 @@ Copyright (c) 2013 BMW Car IT GmbH" "Description": "The XDG Output protocol is an extended way to describe output regions under Wayland", "Homepage": "https://wayland.freedesktop.org", - "Version": "unstable v1, version 2", - "DownloadLocation": "https://cgit.freedesktop.org/wayland/wayland-protocols/plain/unstable/xdg-output/xdg-output-unstable-v1.xml?h=1.16", + "Version": "unstable v1, version 3", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/raw/1.18/unstable/xdg-output/xdg-output-unstable-v1.xml", "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", @@ -145,35 +208,49 @@ Copyright (c) 2013 BMW Car IT GmbH" "Name": "Wayland XDG Shell Protocol", "QDocModule": "qtwaylandcompositor", "QtUsage": "Used in the Qt Wayland Compositor, and the Qt Wayland platform plugin.", - "Files": " xdg-shell-unstable-v5.xml xdg-shell-unstable-v6.xml xdg-shell.xml ../../compositor/extensions/pregenerated/3rdparty/qwayland-server-xdg-shell-unstable-v5.cpp ../../compositor/extensions/pregenerated/3rdparty/qwayland-server-xdg-shell-unstable-v5_p.h ../../compositor/extensions/pregenerated/3rdparty/wayland-xdg-shell-unstable-v5-protocol.c ../../compositor/extensions/pregenerated/3rdparty/wayland-xdg-shell-unstable-v5-server-protocol_p.h ../../plugins/shellintegration/xdg-shell-v5/pregenerated/3rdparty/qwayland-xdg-shell-unstable-v5.cpp ../../plugins/shellintegration/xdg-shell-v5/pregenerated/3rdparty/qwayland-xdg-shell-unstable-v5_p.h ../../plugins/shellintegration/xdg-shell-v5/pregenerated/3rdparty/wayland-xdg-shell-unstable-v5-client-protocol_p.h ../../plugins/shellintegration/xdg-shell-v5/pregenerated/3rdparty/wayland-xdg-shell-unstable-v5-protocol.c", + "Files": "xdg-shell.xml", "Description": "The XDG-Shell protocol is an extended way to manage surfaces under Wayland compositors.", + "Homepage": "https://gitlab.freedesktop.org/wayland/wayland-protocols/", + "Version": "1.18", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/tree/1.18/", + "LicenseId": "MIT", + "License": "MIT License", + "LicenseFile": "MIT_LICENSE.txt", + "Copyright": "Copyright © 2008-2013 Kristian Høgsberg\nCopyright © 2013 Rafael Antognolli\nCopyright © 2013 Jasper St. Pierre\nCopyright © 2010-2013 Intel Corporation\nCopyright © 2015-2017 Samsung Electronics Co., Ltd\nCopyright © 2015-2017 Red Hat Inc.\n" + }, + + { + "Id": "wayland-text-input-unstable-v1", + "Name": "Wayland Text Input Protocol v1", + "QDocModule": "qtwaylandcompositor", + "QtUsage": "Used in the Qt Wayland platform plugin", + "Files": "text-input-unstable-v1.xml", + + "Description": "Adds support for text input and input methods to applications running on Wayland servers that only support text-input-unstable-v1.", "Homepage": "https://wayland.freedesktop.org", - "Version": "1.9.0", - "DownloadLocation": "https://cgit.freedesktop.org/wayland/weston/tag/?id=1.9.0", + "Version": "unstable v1", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/text-input/text-input-unstable-v1.xml", "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", - "Copyright": "Copyright © 2008-2013 Kristian Høgsberg -Copyright © 2013 Rafael Antognolli -Copyright © 2013 Jasper St. Pierre -Copyright © 2010-2013 Intel Corporation" + "Copyright": "Copyright © 2012, 2013 Intel Corporation" }, { - "Id": "wayland-txt-input-unstable", - "Name": "Wayland Text Input Protocol", + "Id": "wayland-text-input-unstable-v2", + "Name": "Wayland Text Input Protocol v2", "QDocModule": "qtwaylandcompositor", "QtUsage": "Used in the Qt Wayland Compositor, and the Qt Wayland platform plugin.", "Files": "text-input-unstable-v2.xml", "Description": "Adds support for text input and input methods to applications.", "Homepage": "https://wayland.freedesktop.org", + "Version": "unstable v2", "LicenseId": "HPND", "License": "HPND License", "LicenseFile": "HPND_LICENSE.txt", - "Copyright": "Copyright © 2012, 2013 Intel Corporation -Copyright © 2015, 2016 Jan Arne Petersen" + "Copyright": "Copyright © 2012, 2013 Intel Corporation\nCopyright © 2015, 2016 Jan Arne Petersen" }, { @@ -185,6 +262,8 @@ Copyright © 2015, 2016 Jan Arne Petersen" "Description": "The linux dmabuf protocol is a way to create dmabuf-based wl_buffers", "Homepage": "https://wayland.freedesktop.org", + "Version": "unstable v1, version 3", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/raw/1.18/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml", "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", @@ -200,9 +279,79 @@ Copyright © 2015, 2016 Jan Arne Petersen" "Description": "Allows clients to request that the compositor creates its EGLStream.", "Homepage": "https://github.com/NVIDIA/egl-wayland", + "Version": "1.1.1", + "DownloadLocation": "https://raw.githubusercontent.com/NVIDIA/egl-wayland/1.1.1/wayland-eglstream/wayland-eglstream-controller.xml", "LicenseId": "MIT", "License": "MIT License", "LicenseFile": "MIT_LICENSE.txt", "Copyright": "Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved." + }, + + { + "Id": "presentation-time.xml", + "Name": "Presentation Time Protocol", + "QDocModule": "qtwaylandcompositor", + "QtUsage": "Used in the Qt Wayland Compositor", + "Files": "presentation-time.xml", + + "Description": "The presentaton time protocol is a way to get presentation timing feedback.", + "Homepage": "https://wayland.freedesktop.org", + "Version": "1", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/raw/1.18/stable/presentation-time/presentation-time.xml", + "LicenseId": "MIT", + "License": "MIT License", + "LicenseFile": "MIT_LICENSE.txt", + "Copyright": "Copyright © 2013, 2014 Collabora, Ltd." + }, + + { + "Id": "xdg-foreign-unstable-v2", + "Name": "Wayland XDG Foreign Protocol", + "QDocModule": "qtwaylandcompositor", + "QtUsage": "Used in the Qt Wayland platform plugin", + "Files": "xdg-foreign-unstable-v2.xml", + + "Description": "Allows referencing surfaces of different clients", + "Homepage": "https://wayland.freedesktop.org", + "Version": "1", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/-/raw/1.25/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml", + "LicenseId": "MIT", + "License": "MIT License", + "LicenseFile": "MIT_LICENSE.txt", + "Copyright": "Copyright © 2015-2016 Red Hat Inc." + }, + + { + "Id": "fractional-scale-v1", + "Name": "Wayland Fractional Scale Protocol", + "QDocModule": "qtwaylandcompositor", + "QtUsage": "Used in the Qt Wayland platform plugin", + "Files": "fractional-scale-v1.xml", + + "Description": "Send a preferred scale to different clients", + "Homepage": "https://wayland.freedesktop.org", + "Version": "1", + "DownloadLocation": "https://gitlab.freedesktop.org/wayland/wayland-protocols/-/raw/1.31/unstable/fractional-scale/fractional-scale-v1.xml", + "LicenseId": "MIT", + "License": "MIT License", + "LicenseFile": "MIT_LICENSE.txt", + "Copyright": "Copyright © 2022 Kenny Levinsen" + }, + + { + "Id": "xdg-dialog-v1", + "Name": "Wayland Dialog Protocol", + "QDocModule": "qtwaylandcompositor", + "QtUsage": "Used in the Qt Wayland platform plugin", + "Files": "xdg-dialog-v1.xml", + + "Description": "Register toplevel as dialogs", + "Homepage": "https://wayland.freedesktop.org", + "Version": "1", + "DownloadLocation": "", + "LicenseId": "MIT", + "License": "MIT License", + "LicenseFile": "MIT_LICENSE.txt", + "Copyright": "Copyright © 2023 Carlos Garnacho" } ] diff --git a/src/3rdparty/protocol/tablet-unstable-v2.xml b/src/3rdparty/protocol/tablet-unstable-v2.xml new file mode 100644 index 000000000..b286d964a --- /dev/null +++ b/src/3rdparty/protocol/tablet-unstable-v2.xml @@ -0,0 +1,1178 @@ +<?xml version="1.0" encoding="UTF-8"?> +<protocol name="tablet_unstable_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. + + 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_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 enter 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"> + 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"> + 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="enter 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/3rdparty/protocol/text-input-unstable-v1.xml b/src/3rdparty/protocol/text-input-unstable-v1.xml new file mode 100644 index 000000000..6ee266522 --- /dev/null +++ b/src/3rdparty/protocol/text-input-unstable-v1.xml @@ -0,0 +1,385 @@ +<?xml version="1.0" encoding="UTF-8"?> +<protocol name="text_input_unstable_v1"> + + <copyright> + Copyright © 2012, 2013 Intel Corporation + + 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_text_input_v1" version="1"> + <description summary="text input"> + An object used for text input. Adds support for text input and input + methods to applications. A text_input object is created from a + wl_text_input_manager and corresponds typically to a text entry in an + application. + + Requests are used to activate/deactivate the text_input object and set + state information like surrounding and selected text or the content type. + The information about entered text is sent to the text_input object via + the pre-edit and commit events. Using this interface removes the need + for applications to directly process hardware key events and compose text + out of them. + + Text is generally UTF-8 encoded, indices and lengths are in bytes. + + Serials are used to synchronize the state between the text input and + an input method. New serials are sent by the text input in the + commit_state request and are used by the input method to indicate + the known text input state in events like preedit_string, commit_string, + and keysym. The text input can then ignore events from the input method + which are based on an outdated state (for example after a reset). + + 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="activate"> + <description summary="request activation"> + Requests the text_input object to be activated (typically when the + text entry gets focus). + + The seat argument is a wl_seat which maintains the focus for this + activation. The surface argument is a wl_surface assigned to the + text_input object and tracked for focus lost. The enter event + is emitted on successful activation. + </description> + <arg name="seat" type="object" interface="wl_seat"/> + <arg name="surface" type="object" interface="wl_surface"/> + </request> + + <request name="deactivate"> + <description summary="request deactivation"> + Requests the text_input object to be deactivated (typically when the + text entry lost focus). The seat argument is a wl_seat which was used + for activation. + </description> + <arg name="seat" type="object" interface="wl_seat"/> + </request> + + <request name="show_input_panel"> + <description summary="show input panels"> + Requests input panels (virtual keyboard) to show. + </description> + </request> + + <request name="hide_input_panel"> + <description summary="hide input panels"> + Requests input panels (virtual keyboard) to hide. + </description> + </request> + + <request name="reset"> + <description summary="reset"> + Should be called by an editor widget when the input state should be + reset, for example after the text was changed outside of the normal + input method flow. + </description> + </request> + + <request name="set_surrounding_text"> + <description summary="sets the surrounding text"> + Sets the plain surrounding text around the input position. Text is + UTF-8 encoded. Cursor is the byte offset within the + surrounding text. Anchor is the byte offset of the + selection anchor within the surrounding text. If there is no selected + text anchor, then it is the same as cursor. + </description> + <arg name="text" type="string"/> + <arg name="cursor" type="uint"/> + <arg name="anchor" type="uint"/> + </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 behaviour"/> + <entry name="default" value="0x7" summary="auto completion, correction and capitalization"/> + <entry name="password" value="0xc0" summary="hidden and sensitive text"/> + <entry name="auto_completion" value="0x1" summary="suggest word completions"/> + <entry name="auto_correction" 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 password or sensitive_data hint)"/> + <entry name="date" value="9" summary="input a date"/> + <entry name="time" value="10" summary="input a time"/> + <entry name="datetime" value="11" summary="input a date and time"/> + <entry name="terminal" value="12" 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. + + When no content type is explicitly set, a normal content purpose with + default hints (auto completion, auto correction, auto capitalization) + should be assumed. + </description> + <arg name="hint" type="uint" enum="content_hint" /> + <arg name="purpose" type="uint" enum="content_purpose" /> + </request> + + <request name="set_cursor_rectangle"> + <arg name="x" type="int"/> + <arg name="y" type="int"/> + <arg name="width" type="int"/> + <arg name="height" type="int"/> + </request> + + <request name="set_preferred_language"> + <description summary="sets preferred language"> + Sets a specific language. This allows for example a virtual keyboard to + show a language specific layout. The "language" argument is an RFC-3066 + format language tag. + + It could be used for example in a word processor to indicate the + language of the currently edited document or in an instant message + application which tracks languages of contacts. + </description> + <arg name="language" type="string"/> + </request> + + <request name="commit_state"> + <arg name="serial" type="uint" summary="used to identify the known state"/> + </request> + + <request name="invoke_action"> + <arg name="button" type="uint"/> + <arg name="index" type="uint"/> + </request> + + <event name="enter"> + <description summary="enter event"> + Notify the text_input object when it received focus. Typically in + response to an activate request. + </description> + <arg name="surface" type="object" interface="wl_surface"/> + </event> + + <event name="leave"> + <description summary="leave event"> + Notify the text_input object when it lost focus. Either in response + to a deactivate request or when the assigned surface lost focus or was + destroyed. + </description> + </event> + + <event name="modifiers_map"> + <description summary="modifiers map"> + Transfer an array of 0-terminated modifier names. The position in + the array is the index of the modifier as used in the modifiers + bitmask in the keysym event. + </description> + <arg name="map" type="array"/> + </event> + + <event name="input_panel_state"> + <description summary="state of the input panel"> + Notify when the visibility state of the input panel changed. + </description> + <arg name="state" type="uint"/> + </event> + + <event name="preedit_string"> + <description summary="pre-edit"> + Notify when a new composing text (pre-edit) should be set around the + current cursor position. Any previously set composing text should + be removed. + + The commit text can be used to replace the preedit text on reset + (for example on unfocus). + + The text input should also handle all preedit_style and preedit_cursor + events occurring directly before preedit_string. + </description> + <arg name="serial" type="uint" summary="serial of the latest known text input state"/> + <arg name="text" type="string"/> + <arg name="commit" type="string"/> + </event> + + <enum name="preedit_style"> + <entry name="default" value="0" summary="default style for composing text"/> + <entry name="none" value="1" summary="style should be the same as in non-composing text"/> + <entry name="active" value="2"/> + <entry name="inactive" value="3"/> + <entry name="highlight" value="4"/> + <entry name="underline" value="5"/> + <entry name="selection" value="6"/> + <entry name="incorrect" value="7"/> + </enum> + + <event name="preedit_styling"> + <description summary="pre-edit styling"> + Sets styling information on composing text. The style is applied for + length bytes from index relative to the beginning of the composing + text (as byte offset). Multiple styles can + be applied to a composing text by sending multiple preedit_styling + events. + + This event is handled as part of a following preedit_string event. + </description> + <arg name="index" type="uint"/> + <arg name="length" type="uint"/> + <arg name="style" type="uint" enum="preedit_style" /> + </event> + + <event name="preedit_cursor"> + <description summary="pre-edit cursor"> + Sets the cursor position inside the composing text (as byte + offset) relative to the start of the composing text. When index is a + negative number no cursor is shown. + + This event is handled as part of a following preedit_string event. + </description> + <arg name="index" type="int"/> + </event> + + <event name="commit_string"> + <description summary="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). It could also be an empty text + when some text should be removed (see delete_surrounding_text) or when + the input cursor should be moved (see cursor_position). + + Any previously set composing text should be removed. + </description> + <arg name="serial" type="uint" summary="serial of the latest known text input state"/> + <arg name="text" type="string"/> + </event> + + <event name="cursor_position"> + <description summary="set cursor to new position"> + Notify when the cursor or anchor position should be modified. + + This event should be handled as part of a following commit_string + event. + </description> + <arg name="index" type="int"/> + <arg name="anchor" type="int"/> + </event> + + <event name="delete_surrounding_text"> + <description summary="delete surrounding text"> + Notify when the text around the current cursor position should be + deleted. + + Index is relative to the current cursor (in bytes). + Length is the length of deleted text (in bytes). + + This event should be handled as part of a following commit_string + event. + </description> + <arg name="index" type="int"/> + <arg name="length" type="uint"/> + </event> + + <event name="keysym"> + <description summary="keysym"> + Notify when a key event was sent. Key events should not be used + for normal text input operations, which should be done with + commit_string, delete_surrounding_text, etc. The key event follows + the wl_keyboard key event convention. Sym is an XKB keysym, state a + wl_keyboard key_state. Modifiers are a mask for effective modifiers + (where the modifier indices are set by the modifiers_map event) + </description> + <arg name="serial" type="uint" summary="serial of the latest known text input state"/> + <arg name="time" type="uint"/> + <arg name="sym" type="uint"/> + <arg name="state" type="uint"/> + <arg name="modifiers" type="uint"/> + </event> + + <event name="language"> + <description summary="language"> + Sets the language of the input text. The "language" argument is an + RFC-3066 format language tag. + </description> + <arg name="serial" type="uint" summary="serial of the latest known text input state"/> + <arg name="language" type="string"/> + </event> + + <enum name="text_direction"> + <entry name="auto" value="0" summary="automatic text direction based on text and language"/> + <entry name="ltr" value="1" summary="left-to-right"/> + <entry name="rtl" value="2" summary="right-to-left"/> + </enum> + + <event name="text_direction"> + <description summary="text direction"> + Sets the text direction of input text. + + It is mainly needed for showing an input cursor on the correct side of + the editor when there is no input done yet and making sure neutral + direction text is laid out properly. + </description> + <arg name="serial" type="uint" summary="serial of the latest known text input state"/> + <arg name="direction" type="uint" enum="text_direction" /> + </event> + </interface> + + <interface name="zwp_text_input_manager_v1" version="1"> + <description summary="text input manager"> + A factory for text_input objects. This object is a global singleton. + </description> + + <request name="create_text_input"> + <description summary="create text input"> + Creates a new text_input object. + </description> + <arg name="id" type="new_id" interface="zwp_text_input_v1"/> + </request> + </interface> + +</protocol> diff --git a/src/3rdparty/protocol/text-input-unstable-v3.xml b/src/3rdparty/protocol/text-input-unstable-v3.xml new file mode 100644 index 000000000..1fae54d7b --- /dev/null +++ b/src/3rdparty/protocol/text-input-unstable-v3.xml @@ -0,0 +1,457 @@ +<?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 with evaluating and + applying the changes as normal, except it should not change the current + state of the zwp_text_input_v3 object. All pending state requests + (set_surrounding_text, set_content_type and set_cursor_rectangle) on + the zwp_text_input_v3 object should be sent and committed after + receiving a zwp_text_input_v3.done event with a matching serial. + </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/3rdparty/protocol/wayland.xml b/src/3rdparty/protocol/wayland.xml index 141038b7a..10e039d6e 100644 --- a/src/3rdparty/protocol/wayland.xml +++ b/src/3rdparty/protocol/wayland.xml @@ -91,18 +91,20 @@ <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"/> + 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, 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. + 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> @@ -175,9 +177,12 @@ <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"> + <event name="done" type="destructor"> <description summary="done event"> Notify the client when the related request is done. </description> @@ -185,7 +190,7 @@ </event> </interface> - <interface name="wl_compositor" version="4"> + <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 @@ -256,6 +261,12 @@ 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> @@ -269,8 +280,8 @@ Clients can create wl_shm_pool objects using the create_pool request. - At connection setup time, the wl_shm object emits one or more - format events to inform clients about the valid pixel formats + 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> @@ -291,10 +302,15 @@ 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. - The formats actually supported by the compositor will be - reported by the format event. + 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"/> @@ -353,6 +369,56 @@ <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"> @@ -381,10 +447,18 @@ <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_drm, wl_shm 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. + 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"> @@ -507,6 +581,9 @@ 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> @@ -523,7 +600,7 @@ 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_drag_source.cancelled. + 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 @@ -544,17 +621,21 @@ 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"/> - <arg name="preferred_action" type="uint" summary="action preferred by the destination client"/> + <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 right after wl_data_device.enter, or anytime the source - side changes its offered actions through wl_data_source.set_actions. + 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"/> + <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"> @@ -595,7 +676,8 @@ 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"/> + <arg name="dnd_action" type="uint" summary="action selected by the compositor" + enum="wl_data_device_manager.dnd_action"/> </event> </interface> @@ -692,7 +774,8 @@ 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"/> + <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"> @@ -748,7 +831,8 @@ 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"/> + <arg name="dnd_action" type="uint" summary="action selected by the compositor" + enum="wl_data_device_manager.dnd_action"/> </event> </interface> @@ -774,7 +858,8 @@ 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. + 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 @@ -789,11 +874,8 @@ a drag-and-drop icon. If the icon surface already has another role, it raises a protocol error. - The current and pending input regions of the icon wl_surface are - cleared, and wl_surface.set_input_region is ignored until the - wl_surface is no longer used as the icon surface. When the use - as an icon ends, the current and pending input regions become - undefined, and the wl_surface is unmapped. + 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"/> @@ -818,7 +900,7 @@ 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 + 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> @@ -888,9 +970,10 @@ 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. The client must - destroy the previous selection data_offer, if any, upon receiving - this event. + 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"/> @@ -978,7 +1061,8 @@ a basic surface. Note! This protocol is deprecated and not intended for production use. - For desktop-style user interfaces, use xdg_shell. + For desktop-style user interfaces, use xdg_shell. Compositors and clients + should not implement this interface. </description> <enum name="error"> @@ -1272,10 +1356,12 @@ </event> </interface> - <interface name="wl_surface" version="4"> + <interface name="wl_surface" version="6"> <description summary="an onscreen surface"> - A surface is a rectangular area that is displayed on the screen. - It has a location, size and pixel contents. + 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 @@ -1302,8 +1388,9 @@ 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. + 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". @@ -1321,6 +1408,10 @@ </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"> @@ -1335,14 +1426,23 @@ 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 the supplied buffer - must be an integer multiple of the buffer_scale. + 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. + 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. @@ -1363,10 +1463,19 @@ 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. However, if the client destroys the - wl_buffer before receiving the wl_buffer.release event, the surface - contents become undefined immediately. + 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. @@ -1397,9 +1506,9 @@ and clears pending damage. The server will clear the current damage as it repaints the surface. - Alternatively, damage can be posted with wl_surface.damage_buffer - which uses buffer coordinates instead of surface coordinates, - and is probably the preferred and intuitive way of doing this. + 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"/> @@ -1543,6 +1652,12 @@ 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> @@ -1658,9 +1773,58 @@ <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="6"> + <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 @@ -1678,6 +1842,14 @@ <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, @@ -1716,7 +1888,8 @@ 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. + 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> @@ -1729,7 +1902,8 @@ 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. + 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> @@ -1742,7 +1916,8 @@ 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. + 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> @@ -1751,9 +1926,22 @@ <event name="name" since="2"> <description summary="unique identifier for this seat"> - In a multiseat configuration this can be used by the client to help - identify which physical devices the seat represents. Based on - the seat configuration used by the compositor. + 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> @@ -1769,7 +1957,7 @@ </interface> - <interface name="wl_pointer" version="6"> + <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 @@ -1813,11 +2001,13 @@ 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. + 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" @@ -2065,6 +2255,9 @@ 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 @@ -2072,7 +2265,8 @@ 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. + 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 @@ -2090,9 +2284,93 @@ <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="6"> + <interface name="wl_keyboard" version="9"> <description summary="keyboard input device"> The wl_keyboard interface represents one or more keyboards associated with a seat. @@ -2106,13 +2384,17 @@ <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; to determine the xkb keycode, clients must add 8 to the key event keycode"/> + 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 to provide a keyboard mapping description. + 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"/> @@ -2123,6 +2405,9 @@ <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"/> @@ -2136,6 +2421,9 @@ 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"/> @@ -2154,6 +2442,12 @@ 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"/> @@ -2203,7 +2497,7 @@ </event> </interface> - <interface name="wl_touch" version="6"> + <interface name="wl_touch" version="9"> <description summary="touchscreen input device"> The wl_touch interface represents a touchscreen associated with a seat. @@ -2347,7 +2641,7 @@ </event> </interface> - <interface name="wl_output" version="3"> + <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 @@ -2402,6 +2696,16 @@ 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"/> @@ -2442,11 +2746,31 @@ 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. + 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"/> @@ -2486,6 +2810,8 @@ 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> @@ -2498,6 +2824,62 @@ 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"> @@ -2569,6 +2951,8 @@ <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"> @@ -2578,14 +2962,18 @@ 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 a protocol - error is raised. + 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> @@ -2621,7 +3009,7 @@ wl_surface state directly. A sub-surface is initially in the synchronized mode. - Sub-surfaces have also other kind of state, which is managed by + 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 @@ -2640,12 +3028,10 @@ synchronized mode, and then assume that all its child and grand-child sub-surfaces are synchronized, too, without explicitly setting them. - If the wl_surface associated with the wl_subsurface is destroyed, the - wl_subsurface object becomes inert. Note, that destroying either object - 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. + 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. @@ -2656,8 +3042,7 @@ 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, and the wl_surface loses its role as - a sub-surface. The wl_surface is unmapped immediately. + to the parent is deleted. The wl_surface is unmapped immediately. </description> </request> diff --git a/src/3rdparty/protocol/xdg-activation-v1.xml b/src/3rdparty/protocol/xdg-activation-v1.xml new file mode 100644 index 000000000..d87e63374 --- /dev/null +++ b/src/3rdparty/protocol/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 <aleixpol@kde.org> + Copyright © 2020 Carlos Garnacho <carlosg@gnome.org> + + 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/3rdparty/protocol/xdg-dialog-v1.xml b/src/3rdparty/protocol/xdg-dialog-v1.xml new file mode 100644 index 000000000..ed2141132 --- /dev/null +++ b/src/3rdparty/protocol/xdg-dialog-v1.xml @@ -0,0 +1,110 @@ +<?xml version="1.0" encoding="UTF-8"?> +<protocol name="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/3rdparty/protocol/xdg-foreign-unstable-v2.xml b/src/3rdparty/protocol/xdg-foreign-unstable-v2.xml new file mode 100644 index 000000000..cc3271dca --- /dev/null +++ b/src/3rdparty/protocol/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/3rdparty/protocol/xdg-output-unstable-v1.xml b/src/3rdparty/protocol/xdg-output-unstable-v1.xml index ccbfe1c9a..fe3a70aab 100644 --- a/src/3rdparty/protocol/xdg-output-unstable-v1.xml +++ b/src/3rdparty/protocol/xdg-output-unstable-v1.xml @@ -54,7 +54,7 @@ reset. </description> - <interface name="zxdg_output_manager_v1" version="2"> + <interface name="zxdg_output_manager_v1" version="3"> <description summary="manage xdg_output objects"> A global factory interface for xdg_output objects. </description> @@ -77,12 +77,17 @@ </request> </interface> - <interface name="zxdg_output_v1" version="2"> + <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"> @@ -157,6 +162,10 @@ 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> @@ -197,10 +206,12 @@ output via :1'. The description event is sent after creating an xdg_output (see - xdg_output_manager.get_xdg_output). This event is only sent once per + 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. The description is optional, and may not be sent - at all. + the wl_output global. </description> <arg name="description" type="string" summary="output description"/> </event> diff --git a/src/3rdparty/protocol/xdg-shell-unstable-v5.xml b/src/3rdparty/protocol/xdg-shell-unstable-v5.xml deleted file mode 100644 index ef0180d01..000000000 --- a/src/3rdparty/protocol/xdg-shell-unstable-v5.xml +++ /dev/null @@ -1,623 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="xdg_shell_unstable_v5"> - - <copyright> - Copyright © 2008-2013 Kristian Høgsberg - Copyright © 2013 Rafael Antognolli - Copyright © 2013 Jasper St. Pierre - Copyright © 2010-2013 Intel Corporation - - 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_shell" version="1"> - <description summary="create desktop-style surfaces"> - xdg_shell allows clients to turn a wl_surface into a "real window" - which can be dragged, resized, stacked, and moved around by the - user. Everything about this interface is suited towards traditional - desktop environments. - </description> - - <enum name="version"> - <description summary="latest protocol version"> - The 'current' member of this enum gives the version of the - protocol. Implementations can compare this to the version - they implement using static_assert to ensure the protocol and - implementation versions match. - </description> - <entry name="current" value="5" summary="Always the latest version"/> - </enum> - - <enum name="error"> - <entry name="role" value="0" summary="given wl_surface has another role"/> - <entry name="defunct_surfaces" value="1" summary="xdg_shell 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"/> - </enum> - - <request name="destroy" type="destructor"> - <description summary="destroy xdg_shell"> - Destroy this xdg_shell object. - - Destroying a bound xdg_shell object while there are surfaces - still alive created by this xdg_shell object instance is illegal - and will result in a protocol error. - </description> - </request> - - <request name="use_unstable_version"> - <description summary="enable use of this unstable version"> - Negotiate the unstable version of the interface. This - mechanism is in place to ensure client and server agree on the - unstable versions of the protocol that they speak or exit - cleanly if they don't agree. This request will go away once - the xdg-shell protocol is stable. - </description> - <arg name="version" type="int"/> - </request> - - <request name="get_xdg_surface"> - <description summary="create a shell surface from a surface"> - This creates an xdg_surface for the given surface and gives it the - xdg_surface role. A wl_surface can only be given an xdg_surface role - once. If get_xdg_surface is called with a wl_surface that already has - an active xdg_surface associated with it, or if it had any other role, - an error is raised. - - 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="get_xdg_popup"> - <description summary="create a popup for a surface"> - This creates an xdg_popup for the given surface and gives it the - xdg_popup role. A wl_surface can only be given an xdg_popup role - once. If get_xdg_popup is called with a wl_surface that already has - an active xdg_popup associated with it, or if it had any other role, - an error is raised. - - This request must be used in response to some sort of user action - like a button press, key press, or touch down event. - - 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="surface" type="object" interface="wl_surface"/> - <arg name="parent" type="object" interface="wl_surface"/> - <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"/> - <arg name="y" type="int"/> - </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. - - 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. - - A compositor is free to ping in any way it wants, but a client must - always respond to any xdg_shell object it created. - </description> - <arg name="serial" type="uint" summary="pass this to the pong request"/> - </event> - - <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 of the ping event"/> - </request> - </interface> - - <interface name="xdg_surface" version="1"> - <description summary="A desktop window"> - 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 windows, allowing to set - properties like maximized, fullscreen, minimized, and to move and resize - them, and associate metadata like title and app id. - - The client must call wl_surface.commit on the corresponding wl_surface - for the xdg_surface state to take effect. Prior to committing the new - state, it can set up initial configuration, such as maximizing or setting - a window geometry. - - Even without attaching a buffer the compositor must respond to initial - committed configuration, for instance sending a configure event with - expected window geometry if the client maximized its surface during - initialization. - - For a surface to be mapped by the compositor the client must have - committed both an xdg_surface state and a buffer. - </description> - - <request name="destroy" type="destructor"> - <description summary="Destroy the xdg_surface"> - Unmap and destroy the window. The window will be effectively - hidden from the user's point of view, and all state like - maximization, fullscreen, and so on, will be lost. - </description> - </request> - - <request name="set_parent"> - <description summary="set the parent of this surface"> - Set the "parent" of this surface. This window should be stacked - above a parent. The parent surface must be mapped as long as this - surface is mapped. - - Parent windows should be set on dialogs, toolboxes, or other - "auxiliary" surfaces, so that the parent is raised when the dialog - is raised. - </description> - <arg name="parent" type="object" interface="xdg_surface" 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". - - 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] http://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. - - 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. 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" 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. - - Desktop environments may extend this enum by taking up a range of - values and documenting the range they chose in this description. - They are not required to document the values for the range that they - chose. Ideally, any good extensions from a desktop environment should - make its way into standardization into this enum. - - The current reserved ranges are: - - 0x0000 - 0x0FFF: xdg-shell core values, documented below. - 0x1000 - 0x1FFF: GNOME - 0x2000 - 0x2FFF: EFL - </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. - </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 must be obeyed by the client. - </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> - </enum> - - <event name="configure"> - <description summary="suggest a surface change"> - The configure event asks the client to resize its surface or to - change its state. - - 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 need 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 should arrange their surface for the new size and - states, and then send a 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="width" type="int"/> - <arg name="height" type="int"/> - <arg name="states" type="array"/> - <arg name="serial" type="uint"/> - </event> - - <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, 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. - - 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. - - The compositor expects that the most recently received - ack_configure request at the time of a commit indicates which - configure event the client is responding to. - </description> - <arg name="serial" type="uint" summary="the serial from the configure event"/> - </request> - - <request name="set_window_geometry"> - <description summary="set the new window geometry"> - The window geometry of a window 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. - - Once the window geometry of the surface is set once, 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 mode is meant for extremely simple clients. - - If responding to a configure event, the window geometry in here - must respect the sizing negotiations specified by the states in - the configure event. - - The arguments are given in the surface local coordinate space of - the wl_surface associated with this xdg_surface. - - The width and height must be greater than zero. - </description> - <arg name="x" type="int"/> - <arg name="y" type="int"/> - <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 with the "maximized" state - and the required window geometry. The client should then update its - content, drawing it in a maximized state, i.e. without shadow or other - decoration outside of the window geometry. 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. - </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 without the "maximized" - state. If available, the compositor will include the window geometry - dimensions the window had prior to being maximized in the configure - request. The client must then update its content, drawing it in a - regular state, i.e. potentially with shadow, etc. 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. - </description> - </request> - - <request name="set_fullscreen"> - <description summary="set the window as fullscreen on a monitor"> - Make the surface fullscreen. - - You can specify an output that you would prefer to be fullscreen. - 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 - black borders filling the rest of the output. - </description> - <arg name="output" type="object" interface="wl_output" allow-null="true"/> - </request> - <request name="unset_fullscreen" /> - - <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="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 your - window. The client may choose to ignore this request, or show - a dialog to ask the user to save their data... - </description> - </event> - </interface> - - <interface name="xdg_popup" version="1"> - <description summary="short-lived, popup surfaces for menus"> - A popup surface is a short-lived, temporary surface that can be - used to implement menus. It takes an explicit grab on the surface - that will be dismissed when the user dismisses the 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. - - When the popup is dismissed, a popup_done event will be sent out, - and at the same time the surface will be unmapped. The xdg_popup - object is now inert and cannot be reactivated, so clients should - destroy it. Explicitly destroying the xdg_popup object will also - dismiss the popup and unmap the surface. - - Clients will receive events for all their surfaces during this - grab (which is an "owner-events" grab in X11 parlance). This is - done so that users can navigate through submenus and other - "nested" popup windows without having to dismiss the topmost - popup. - - Clients that want to dismiss the popup when another surface of - their own is clicked should dismiss the popup using the destroy - request. - - The parent surface must have either an xdg_surface or xdg_popup - role. - - Specifying an xdg_popup for the parent 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. - - If there is an existing popup when creating a new popup, the - parent must be the current topmost popup. - - A parent surface must be mapped before the new popup is mapped. - - When compositors choose to dismiss a popup, they will likely - dismiss every nested popup as well. When a compositor dismisses - popups, it will follow the same dismissing order as required - from the client. - - The x and y arguments passed when creating the popup object specify - where the top left of the popup should be placed, relative to the - local surface coordinates of the parent surface. See - xdg_shell.get_xdg_popup. - - The client must call wl_surface.commit on the corresponding wl_surface - for the xdg_popup state to take effect. - - For a surface to be mapped by the compositor the client must have - committed both the xdg_popup state and a buffer. - </description> - - <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, a protocol error - will be sent. - </description> - </request> - - <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> - - </interface> -</protocol> diff --git a/src/3rdparty/protocol/xdg-shell-unstable-v6.xml b/src/3rdparty/protocol/xdg-shell-unstable-v6.xml index e49d74fcc..1c0f92452 100644 --- a/src/3rdparty/protocol/xdg-shell-unstable-v6.xml +++ b/src/3rdparty/protocol/xdg-shell-unstable-v6.xml @@ -118,7 +118,9 @@ 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. + 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. @@ -941,7 +943,8 @@ The x and y arguments passed when creating the popup object specify where the top left of the popup should be placed, relative to the local surface coordinates of the parent surface. See - xdg_surface.get_popup. + xdg_surface.get_popup. An xdg_popup must intersect with or be at least + partially adjacent to its parent surface. The client must call wl_surface.commit on the corresponding wl_surface for the xdg_popup state to take effect. diff --git a/src/3rdparty/protocol/xdg-shell.xml b/src/3rdparty/protocol/xdg-shell.xml index d524ea9e2..777eaa749 100644 --- a/src/3rdparty/protocol/xdg-shell.xml +++ b/src/3rdparty/protocol/xdg-shell.xml @@ -29,7 +29,7 @@ DEALINGS IN THE SOFTWARE. </copyright> - <interface name="xdg_wm_base" version="1"> + <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 @@ -50,6 +50,8 @@ 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"> @@ -58,7 +60,7 @@ 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 protocol error. + and will result in a defunct_surfaces error. </description> </request> @@ -75,7 +77,9 @@ <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. + 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 @@ -92,7 +96,8 @@ <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. + 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> @@ -101,12 +106,14 @@ <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.ping. + 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. + 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. @@ -115,7 +122,7 @@ </event> </interface> - <interface name="xdg_positioner" version="1"> + <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 @@ -135,7 +142,7 @@ 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 error. + positioning a surface raises an invalid_positioner error. </description> <enum name="error"> @@ -223,7 +230,8 @@ 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. + 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"/> @@ -357,9 +365,49 @@ <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="1"> + <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. @@ -386,6 +434,13 @@ 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. @@ -399,19 +454,30 @@ 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. + 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"/> - <entry name="already_constructed" value="2"/> - <entry name="unconfigured_buffer" value="3"/> + <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. + after its role object has been destroyed, otherwise + a defunct_role_object error is raised. </description> </request> @@ -466,13 +532,22 @@ 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. + 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. - The width and height must be greater than zero. Setting an invalid size - will raise an error. 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 + 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"/> @@ -493,6 +568,8 @@ 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 @@ -501,6 +578,17 @@ 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> @@ -526,9 +614,10 @@ </description> <arg name="serial" type="uint" summary="serial of the configure event"/> </event> + </interface> - <interface name="xdg_toplevel" version="1"> + <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, @@ -540,7 +629,11 @@ 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. + 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> @@ -552,24 +645,37 @@ </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 windows should be set on dialogs, toolboxes, or other + 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 window removes any parent-child - relationship for the child. Setting a null parent for a window which - currently has no parent is a no-op. + 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. - If the parent is unmapped then its children are managed as - though the parent of the now-unmapped parent has become the - parent of this surface. If no parent exists for the now-unmapped - parent then the children are managed as though they have no - parent surface. + 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> @@ -604,11 +710,14 @@ 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] http://standards.freedesktop.org/desktop-entry-spec/ + [0] https://standards.freedesktop.org/desktop-entry-spec/ </description> <arg name="app_id" type="string"/> </request> @@ -622,7 +731,8 @@ 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. + 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. @@ -698,16 +808,17 @@ 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. 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. + 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" summary="which edge or corner is being dragged"/> + <arg name="edges" type="uint" enum="resize_edge" summary="which edge or corner is being dragged"/> </request> <enum name="state"> @@ -723,7 +834,11 @@ <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. + 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"> @@ -750,6 +865,37 @@ 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"> @@ -783,11 +929,11 @@ request. Requesting a maximum size to be smaller than the minimum size of - a surface is illegal and will result in a protocol error. + 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 - protocol error. + 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"/> @@ -824,11 +970,11 @@ request. Requesting a minimum size to be larger than the maximum size of - a surface is illegal and will result in a protocol error. + 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 - protocol error. + invalid_size error. </description> <arg name="width" type="int"/> <arg name="height" type="int"/> @@ -839,12 +985,11 @@ Maximize the surface. After requesting that the surface should be maximized, the compositor - will respond by emitting a configure event with the "maximized" state - and the required window geometry. The client should then update its - content, drawing it in a maximized state, i.e. without shadow or other - decoration outside of the window geometry. The client must also - acknowledge the configure when committing the new content (see - ack_configure). + 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 @@ -854,8 +999,8 @@ a configure event with the "maximized" state. If the surface is in a fullscreen state, this request has no direct - effect. It will alter the state the surface is returned to when - unmaximized if not overridden by the compositor. + effect. It may alter the state the surface is returned to when + unmaximized unless overridden by the compositor. </description> </request> @@ -864,13 +1009,13 @@ Unmaximize the surface. After requesting that the surface should be unmaximized, the compositor - will respond by emitting a configure event without the "maximized" - state. If available, 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 a - regular state, i.e. potentially with shadow, etc. The client must also - acknowledge the configure when committing the new content (see - ack_configure). + 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 @@ -880,8 +1025,8 @@ emit a configure event without the "maximized" state. If the surface is in a fullscreen state, this request has no direct - effect. It will alter the state the surface is returned to when - unmaximized if not overridden by the compositor. + effect. It may alter the state the surface is returned to when + unmaximized unless overridden by the compositor. </description> </request> @@ -890,10 +1035,10 @@ Make the surface fullscreen. After requesting that the surface should be fullscreened, the - compositor will respond by emitting a configure event with the - "fullscreen" state and the fullscreen window geometry. The client must - also acknowledge the configure when committing the new content (see - ack_configure). + 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, @@ -919,8 +1064,9 @@ Make the surface no longer fullscreen. After requesting that the surface should be unfullscreened, the - compositor will respond by emitting a configure event without the - "fullscreen" state. + 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 @@ -987,9 +1133,68 @@ 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="1"> + <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 @@ -1007,21 +1212,12 @@ surface of their own is clicked should dismiss the popup using the destroy request. - The parent surface must have either the xdg_toplevel or xdg_popup surface - role. - 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 x and y arguments passed when creating the popup object specify - where the top left of the popup should be placed, relative to the - local surface coordinates of the parent surface. See - xdg_surface.get_popup. An xdg_popup must intersect with or be at least - partially adjacent to its parent surface. - The client must call wl_surface.commit on the corresponding wl_surface for the xdg_popup state to take effect. </description> @@ -1036,8 +1232,8 @@ 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, a protocol error - will be sent. + If this xdg_popup is not the "topmost" popup, the + xdg_wm_base.not_the_topmost_popup protocol error will be sent. </description> </request> @@ -1069,10 +1265,6 @@ nested grabbing popup as well. When a compositor dismisses popups, it will follow the same dismissing order as required from the client. - The parent of a grabbing popup must either be another xdg_popup with an - active explicit grab, or an xdg_popup or xdg_toplevel, if there are no - explicit grabs already taken. - 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. @@ -1099,6 +1291,11 @@ 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"/> @@ -1116,5 +1313,58 @@ </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/3rdparty/protocol/xdg-toplevel-drag-v1.xml b/src/3rdparty/protocol/xdg-toplevel-drag-v1.xml new file mode 100644 index 000000000..2fe964583 --- /dev/null +++ b/src/3rdparty/protocol/xdg-toplevel-drag-v1.xml @@ -0,0 +1,141 @@ +<?xml version="1.0" encoding="UTF-8"?> +<protocol name="xdg_toplevel_drag_v1"> + + <copyright> + Copyright 2023 David Redondo + + 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_toplevel_drag_manager_v1" version="1"> + <description summary="Move a window during a drag"> + This protocol enhances normal drag and drop with the ability to move a + window at the same time. This allows having detachable parts of a window + that when dragged out of it become a new window and can be dragged over + an existing window to be reattached. + + A typical workflow would be when the user starts dragging on top of a + detachable part of a window, the client would create a wl_data_source and + a xdg_toplevel_drag_v1 object and start the drag as normal via + wl_data_device.start_drag. Once the client determines that the detachable + window contents should be detached from the originating window, it creates + a new xdg_toplevel with these contents and issues a + xdg_toplevel_drag_v1.attach request before mapping it. From now on the new + window is moved by the compositor during the drag as if the client called + xdg_toplevel.move. + + Dragging an existing window is similar. The client creates a + xdg_toplevel_drag_v1 object and attaches the existing toplevel before + starting the drag. + + Clients use the existing drag and drop mechanism to detect when a window + can be docked or undocked. If the client wants to snap a window into a + parent window it should delete or unmap the dragged top-level. If the + contents should be detached again it attaches a new toplevel as described + above. If a drag operation is cancelled without being dropped, clients + should revert to the previous state, deleting any newly created windows + as appropriate. When a drag operation ends as indicated by + wl_data_source.dnd_drop_performed the dragged toplevel window's final + position is determined as if a xdg_toplevel_move operation ended. + + 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="invalid_source" value="0" + summary="data_source already used for toplevel drag"/> + </enum> + + <request name="destroy" type="destructor"> + <description summary="destroy the xdg_toplevel_drag_manager_v1 object"> + Destroy this xdg_toplevel_drag_manager_v1 object. Other objects, + including xdg_toplevel_drag_v1 objects created by this factory, are not + affected by this request. + </description> + </request> + + <request name="get_xdg_toplevel_drag"> + <description summary="get an xdg_toplevel_drag for a wl_data_source"> + Create an xdg_toplevel_drag for a drag and drop operation that is going + to be started with data_source. + + This request 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 such as in + wl_data_device.set_selection will raise an invalid_source error. + + Destroying data_source while a toplevel is attached to the + xdg_toplevel_drag is undefined. + </description> + + <arg name="id" type="new_id" interface="xdg_toplevel_drag_v1"/> + <arg name="data_source" type="object" interface="wl_data_source"/> + </request> + </interface> + + <interface name="xdg_toplevel_drag_v1" version="1"> + <description summary="Object representing a toplevel move during a drag"> + </description> + + <enum name="error"> + <entry name="toplevel_attached" value="0" + summary="valid toplevel already attached"/> + <entry name="ongoing_drag" value="1" + summary="drag has not ended" /> + </enum> + + <request name="destroy" type="destructor"> + <description summary="destroy an xdg_toplevel_drag_v1 object"> + Destroy this xdg_toplevel_drag_v1 object. This request must only be + called after the underlying wl_data_source drag has ended, as indicated + by the dnd_drop_performed or cancelled events. In any other case an + ongoing_drag error is raised. + </description> + </request> + + <request name="attach"> + <description summary="Move a toplevel with the drag operation"> + Request that the window will be moved with the cursor during the drag + operation. The offset is a hint to the compositor how the toplevel + should be positioned relative to the cursor hotspot in surface local + coordinates. For example it might only be used when an unmapped window + is attached. The attached window does not participate in the selection + of the drag target. + + If the toplevel is unmapped while it is attached, it is automatically + detached from the drag. In this case this request has to be called again + if the window should be attached after it is remapped. + + This request can be called multiple times but issuing it while a + toplevel with an active role is attached raises a toplevel_attached + error. + </description> + + <arg name="toplevel" type="object" interface="xdg_toplevel"/> + <arg name="x_offset" type="int" summary="dragged surface x offset"/> + <arg name="y_offset" type="int" summary="dragged surface y offset"/> + </request> + + </interface> +</protocol> + |