...
 
Commits (11)
AC_PREREQ([2.64])
m4_define([wayland_protocols_major_version], [1])
m4_define([wayland_protocols_minor_version], [17])
m4_define([wayland_protocols_minor_version], [18])
m4_define([wayland_protocols_version],
[wayland_protocols_major_version.wayland_protocols_minor_version])
......
......@@ -2,4 +2,4 @@ xdg shell protocol
Maintainers:
Jonas Ådahl <jadahl@gmail.com>
Mike Blumenkrantz <zmike@osg.samsung.com>
Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
......@@ -101,7 +101,7 @@
<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
......@@ -604,6 +604,9 @@
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.
......
......@@ -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.
......
......@@ -26,7 +26,7 @@
DEALINGS IN THE SOFTWARE.
</copyright>
<interface name="zwp_linux_explicit_synchronization_v1" version="1">
<interface name="zwp_linux_explicit_synchronization_v1" version="2">
<description summary="protocol for providing explicit synchronization">
This global is a factory interface, allowing clients to request
explicit synchronization for buffers on a per-surface basis.
......@@ -66,6 +66,12 @@
If the given wl_surface already has an explicit synchronization object
associated, the synchronization_exists protocol error is raised.
Graphics APIs, like EGL or Vulkan, that manage the buffer queue and
commits of a wl_surface themselves, are likely to be using this
extension internally. If a client is using such an API for a
wl_surface, it should not directly use this extension on that surface,
to avoid raising a synchronization_exists protocol error.
</description>
<arg name="id" type="new_id"
......@@ -76,7 +82,7 @@
</request>
</interface>
<interface name="zwp_linux_surface_synchronization_v1" version="1">
<interface name="zwp_linux_surface_synchronization_v1" version="2">
<description summary="per-surface explicit synchronization support">
This object implements per-surface explicit synchronization.
......@@ -101,8 +107,13 @@
Each surface can be associated with only one object of this interface at
any time.
Explicit synchronization is guaranteed to be supported only for buffers
created with any version of the wp_linux_dmabuf buffer factory.
In version 1 of this interface, explicit synchronization is only
guaranteed to be supported for buffers created with any version of the
wp_linux_dmabuf buffer factory. Version 2 additionally guarantees
explicit synchronization support for opaque EGL buffers, which is a type
of platform specific buffers described in the EGL_WL_bind_wayland_display
extension. Compositors are free to support explicit synchronization for
additional buffer types.
</description>
<request name="destroy" type="destructor">
......@@ -215,6 +226,11 @@
signaled when all operations by the compositor on that buffer for that
commit have finished.
Once the fence has signaled, and assuming the associated buffer is not
pending release from other wl_surface.commit requests, no additional
explicit or implicit synchronization is required to safely reuse or
destroy the buffer.
This event destroys the zwp_linux_buffer_release_v1 object.
</description>
<arg name="fence" type="fd" summary="fence for last operation on buffer"/>
......@@ -227,6 +243,11 @@
using it, or has a guarantee that all its operations on that buffer for
that commit have finished.
Once this event is received, and assuming the associated buffer is not
pending release from other wl_surface.commit requests, no additional
explicit or implicit synchronization is required to safely reuse or
destroy the buffer.
This event destroys the zwp_linux_buffer_release_v1 object.
</description>
</event>
......
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="pointer_gestures_unstable_v1">
<interface name="zwp_pointer_gestures_v1" version="1">
<interface name="zwp_pointer_gestures_v1" version="2">
<description summary="touchpad gestures">
A global interface to provide semantic touchpad gestures for a given
pointer.
......@@ -37,9 +37,18 @@
<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="1">
<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.
......@@ -102,7 +111,7 @@
</event>
</interface>
<interface name="zwp_pointer_gesture_pinch_v1" version="1">
<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.
......
......@@ -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>
......