aboutsummaryrefslogtreecommitdiff
path: root/protocol/wayland.xml
diff options
context:
space:
mode:
Diffstat (limited to 'protocol/wayland.xml')
-rw-r--r--protocol/wayland.xml152
1 files changed, 128 insertions, 24 deletions
diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index b1c930d..471daf6 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -91,7 +91,7 @@
<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"
@@ -101,10 +101,10 @@
<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>
@@ -293,10 +293,12 @@
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.
</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"/>
@@ -355,6 +357,52 @@
<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"/>
</enum>
<request name="create_pool">
@@ -509,6 +557,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>
@@ -525,7 +576,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
@@ -546,8 +597,10 @@
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">
@@ -556,7 +609,8 @@
will be sent right after wl_data_device.enter, 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">
@@ -597,7 +651,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>
@@ -694,7 +749,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">
@@ -750,7 +806,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>
@@ -776,7 +833,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
@@ -1276,8 +1334,10 @@
<interface name="wl_surface" version="4">
<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
@@ -1323,6 +1383,7 @@
</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"/>
</enum>
<request name="destroy" type="destructor">
@@ -1337,8 +1398,9 @@
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
@@ -1365,6 +1427,12 @@
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
@@ -1545,6 +1613,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>
@@ -1680,6 +1754,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,
@@ -1718,7 +1800,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>
@@ -1731,7 +1814,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>
@@ -1744,7 +1828,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>
@@ -2128,6 +2213,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"/>
@@ -2141,6 +2229,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"/>
@@ -2159,6 +2250,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"/>
@@ -2454,6 +2551,10 @@
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,
@@ -2462,6 +2563,9 @@
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).
+
Clients should not use the refresh rate to schedule frames. Instead,
they should use the wl_surface.frame event or the presentation-time
protocol.
@@ -2643,7 +2747,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