[Git][xorg-team/wayland/wayland-protocols][upstream-unstable] 11 commits: linux-explicit-synchronization: Allow fences with opaque EGL buffers

[Héctor Orón Martínez <zumbi@debian.org>]

Title: GitLab

Héctor Orón Martínez pushed to branch upstream-unstable at X Strike Force / wayland / wayland-protocols

Commits:

• 47914962
  by Alexandros Frantzis at 2018-12-14T12:01:54Z

  linux-explicit-synchronization: Allow fences with opaque EGL buffers
  
  Add opaque EGL buffers to the supported buffer types for use with the
  explicit synchronization protocol. Opaque EGL buffers rely on the same
  EGL implementation in both the compositor and clients, which makes it
  straightforward to manage client expectations about fence support for
  such buffers.
  
  Also make it clearer that implementations are free to support other
  buffer types beyond the required ones.
  
  Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
  Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
  

• 08903bdf
  by Alexandros Frantzis at 2018-12-14T12:01:54Z

  linux-explicit-synchronization: Warn about using the protocol while using graphics APIs
  
  Graphics APIs are expected to use this protocol under the hood, and
  since there can only be one user of explicit synchronization per
  surface, warn about using the protocol directly in such cases.
  
  Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
  Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
  

• 57423eac
  by Alexandros Frantzis at 2018-12-14T12:01:54Z

  linux-explicit-synchronization: Clarify implicit synchronization guarantees of release events
  
  Clarify that after zwp_buffer_release_v1 events, otherwise unused
  buffers can be reused without any additional implicit synchronization.
  This is in contrast to wl_buffer.release, which doesn't guarantee that
  implicit synchronization is not required to safely use a buffer after
  the event is received.
  
  Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
  Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
  

• 70ed9d7e
  by Sebastian Krzyszkowiak at 2019-01-17T14:57:49Z

  xdg-shell: fix a typo
  
  Signed-off-by: Sebastian Krzyszkowiak <dos@dosowisko.net>
  Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
  

• fb9b2a87
  by Chia-I Wu at 2019-05-02T11:30:32Z

  linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID
  
  DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
  It provides legacy support and makes it easier to replace wl_drm.
  
  v3: DRM_FORMAT_MOD_INVALID must be advertised to be supported (which
      requires a version bump)
  v4: no version bump, but a note for now
  
  Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
  Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
  Reviewed-by: Simon Ser <contact@emersion.fr>
  Reviewed-by: Daniel Stone <daniels@collabora.com>
  

• 53624311
  by Jonas Ådahl at 2019-05-22T15:55:41Z

  xdg-shell/README: Update E-mail address
  
  As requested by Mike, update the E-mail address listed in the README.
  
  Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
  

• 962dd535
  by Simon Ser at 2019-07-17T08:04:25Z

  xdg-output: deprecate the xdg_output.done event
  
  This commit makes it so a wl_output.done event is guaranteed to be sent with a
  xdg_output.done event.
  
  This protocol change has been discussed in a recent xorg-devel discussions [1].
  
  First let's recap why a change is needed: Xwayland listens to both wl_output and
  xdg_output changes. When an output's properties change, Xwayland expects to
  receive both a wl_output.done event and an xdg_output.done event. If that's not
  the case, Xwayland doesn't update its state (so old state is still exposed to
  X11 clients).
  
  Most of the time, both objects will be updated at the same time (e.g. the
  current mode is changed, so both wl_output.mode and xdg_output.logical_size are
  sent) so this won't be an issue. However in some situations only one of
  wl_output or xdg_output changes. For instance:
  
  - The mode is changed at the same time as the scale, resulting in the same
    logical_size.
  - The compositor doesn't expose the outputs' position via wl_output, so whenever
    the position changes only xdg_output is updated.
  
  Both KDE [2] and wlroots [3] have experienced this issue.
  
  For this reason, I'd like to update the xdg-output protocol to make it mandatory
  to always send a wl_output.done event after xdg_output changes. This effectively
  makes wl_output.done atomically apply all output state (including the state of
  add-on objects like xdg_output). This approach is pretty similar to
  wl_surface.commit: this request will atomically apply surface state including
  the state of e.g. the xdg_surface object tied to the wl_surface.
  
  To update the protocol to reflect this new requirement we can either:
  
  - **Bump xdg_output version**. The current protocol doesn't specify that
    wl_output.done must be sent, adding this new requirement would be a breaking
    change. We need to fix Xwayland for the current xdg_output version (maybe make
    it non-atomic for the current version, atomic for the new one?). Should we
    deprecate xdg_output.done in the new version?
  - **Don't bump xdg_output version**. This clarifies what is expected in practice
    by Xwayland, a major xdg_output consumer, and what is currently implemented by
    all compositors.
  
  There's one issue with the "don't bump" approach: indeed in practice compositors
  always send wl_output.done and xdg_output.done in pairs, however the ordering
  between those two events is not guaranteed. This means some compositors might
  send this sequence:
  
      wl_output.geometry(…)
      wl_output.done()
      xdg_output.logical_position(…)
      xdg_output.done()
  
  In this case the wl_output.done event fails to atomically apply the xdg_output
  state.
  
  For this reason, I think bumping the version is a better approach.
  
  This commit also deprecates xdg_output.done, which doesn't have any purpose
  anymore.
  
  [1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html
  [2]: https://phabricator.kde.org/D19253
  [3]: https://github.com/swaywm/sway/issues/4064
  
  Signed-off-by: Simon Ser <contact@emersion.fr>
  Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
  Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
  

• b9d427db
  by Simon Ser at 2019-07-17T08:28:43Z

  pointer-gestures: add a release request
  
  This allows clients to destroy a gesture object before they disconnect.
  
  The request isn't named "destroy", as this would conflict with
  wayland-scanner's auto-generated destructor (which just destroys the
  client-side object without sending any request).
  
  Signed-off-by: Simon Ser <contact@emersion.fr>
  Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
  

• e0d6ad1d
  by Jan-Marek Glogowski at 2019-07-17T11:43:00Z

  xdg-shell: use case to change the app ID at runtime
  
  LibreOffice is one big binary with explicit brandings for different
  application modules. This is represented in X11 by a different
  WM_CLASS setting for a window. The WM_CLASS is changed based on the
  loaded document at runtime. As a result LibreOffice already offers
  multiple desktop files with different icons, StartupWMClass
  entries and application names.
  
  This amendment of the set_app_id request just explicitly specifies
  the use case to change a surfaces' app ID at runtime, so a compositor
  implementor is made aware of it. Just as the WM_CLASS, a change of
  the app ID should result in an update of the propertes of a surface
  depending on the app ID, like the window icon specified in the
  desktop file or a re-grouping of the surfaces in a task manager.
  
  Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
  Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
  Reviewed-by: Simon Ser <contact@emersion.fr>
  

• 048102f2
  by Simon Ser at 2019-07-25T09:19:02Z

  xdg-output: make xdg_output.description mutable
  
  The output description is a human-readable text describing the output. Unlike
  the name which uniquely identifies the output, it's intended to be displayed to
  the user.
  
  It might be desirable for a compositor to update an output's description. For
  instance, when only one output is plugged in, it's not necessary to dump make,
  model, serial and connector to the description, something like "Dell U2717D" is
  enough. However when two identical outputs are plugged in it's necessary to add
  e.g. the connector type to tell them apart ("Dell U2717D on HDMI"). See [1] for
  a discussion about this.
  
  This commit bumps xdg_output's version to allow compositors to update the
  property.
  
  [1]: https://github.com/swaywm/wlroots/issues/1623
  
  Signed-off-by: Simon Ser <contact@emersion.fr>
  Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
  Acked-by: Olivier Fourdan <ofourdan@redhat.com>
  

• 630fb089
  by Jonas Ådahl at 2019-07-25T09:19:17Z

  configure.ac: Bump version to 1.18
  
  Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
  

7 changed files:

• configure.ac
• stable/xdg-shell/README
• stable/xdg-shell/xdg-shell.xml
• unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
• unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
• unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
• unstable/xdg-output/xdg-output-unstable-v1.xml

Changes:

configure.ac

---

1	1	AC_PREREQ([2.64])
2	2
3	3	m4_define([wayland_protocols_major_version], [1])
4		-m4_define([wayland_protocols_minor_version], [17])
	4	+m4_define([wayland_protocols_minor_version], [18])
5	5	m4_define([wayland_protocols_version],
6	6	[wayland_protocols_major_version.wayland_protocols_minor_version])
7	7

stable/xdg-shell/README

---

...	...	@@ -2,4 +2,4 @@ xdg shell protocol
2	2
3	3	Maintainers:
4	4	Jonas Ådahl <jadahl@gmail.com>
5		-Mike Blumenkrantz <zmike@osg.samsung.com>
	5	+Mike Blumenkrantz <michael.blumenkrantz@gmail.com>

stable/xdg-shell/xdg-shell.xml

---

...	...	@@ -101,7 +101,7 @@
101	101	<description summary="check if the client is alive">
102	102	The ping event asks the client if it's still alive. Pass the
103	103	serial specified in the event back to the compositor by sending
104		- a "pong" request back with the specified serial. See xdg_wm_base.ping.
	104	+ a "pong" request back with the specified serial. See xdg_wm_base.pong.
105	105
106	106	Compositors can use this to determine if the client is still
107	107	alive. It's unspecified what will happen if the client doesn't
...	...	@@ -604,6 +604,9 @@
604	604	For example, "org.freedesktop.FooViewer" where the .desktop file is
605	605	"org.freedesktop.FooViewer.desktop".
606	606
	607	+ Like other properties, a set_app_id request can be sent after the
	608	+ xdg_toplevel has been mapped to update the property.
	609	+
607	610	See the desktop-entry specification [0] for more details on
608	611	application identifiers and how they relate to well-known D-Bus
609	612	names and .desktop files.

unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml

---

...	...	@@ -28,6 +28,7 @@
28	28	<description summary="factory for creating dmabuf-based wl_buffers">
29	29	Following the interfaces from:
30	30	https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
	31	+ https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
31	32	and the Linux DRM sub-system's AddFb2 ioctl.
32	33
33	34	This interface offers ways to create generic dmabuf-based
...	...	@@ -129,8 +130,16 @@
129	130	binds to this interface. A roundtrip after binding guarantees that
130	131	the client has received all supported format-modifier pairs.
131	132
	133	+ For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
	134	+ 0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event.
	135	+ It indicates that the server can support the format with an implicit
	136	+ modifier. When a plane has DRM_FORMAT_MOD_INVALID as its modifier, it
	137	+ is as if no explicit modifier is specified. The effective modifier
	138	+ will be derived from the dmabuf.
	139	+
132	140	For the definition of the format and modifier codes, see the
133		- zwp_linux_buffer_params_v1::create request.
	141	+ zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add
	142	+ requests.
134	143	</description>
135	144	<arg name="format" type="uint" summary="DRM_FORMAT code"/>
136	145	<arg name="modifier_hi" type="uint"
...	...	@@ -197,6 +206,11 @@
197	206	compression, etc. driver-specific modifications to the base format
198	207	defined by the DRM fourcc code.
199	208
	209	+ Warning: It should be an error if the format/modifier pair was not
	210	+ advertised with the modifier event. This is not enforced yet because
	211	+ some implementations always accept DRM_FORMAT_MOD_INVALID. Also
	212	+ version 2 of this protocol does not have the modifier event.
	213	+
200	214	This request raises the PLANE_IDX error if plane_idx is too large.
201	215	The error PLANE_SET is raised if attempting to set a plane that
202	216	was already set.

unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml

---

...	...	@@ -26,7 +26,7 @@
26	26	DEALINGS IN THE SOFTWARE.
27	27	</copyright>
28	28
29		- <interface name="zwp_linux_explicit_synchronization_v1" version="1">
	29	+ <interface name="zwp_linux_explicit_synchronization_v1" version="2">
30	30	<description summary="protocol for providing explicit synchronization">
31	31	This global is a factory interface, allowing clients to request
32	32	explicit synchronization for buffers on a per-surface basis.
...	...	@@ -66,6 +66,12 @@
66	66
67	67	If the given wl_surface already has an explicit synchronization object
68	68	associated, the synchronization_exists protocol error is raised.
	69	+
	70	+ Graphics APIs, like EGL or Vulkan, that manage the buffer queue and
	71	+ commits of a wl_surface themselves, are likely to be using this
	72	+ extension internally. If a client is using such an API for a
	73	+ wl_surface, it should not directly use this extension on that surface,
	74	+ to avoid raising a synchronization_exists protocol error.
69	75	</description>
70	76
71	77	<arg name="id" type="new_id"
...	...	@@ -76,7 +82,7 @@
76	82	</request>
77	83	</interface>
78	84
79		- <interface name="zwp_linux_surface_synchronization_v1" version="1">
	85	+ <interface name="zwp_linux_surface_synchronization_v1" version="2">
80	86	<description summary="per-surface explicit synchronization support">
81	87	This object implements per-surface explicit synchronization.
82	88
...	...	@@ -101,8 +107,13 @@
101	107	Each surface can be associated with only one object of this interface at
102	108	any time.
103	109
104		- Explicit synchronization is guaranteed to be supported only for buffers
105		- created with any version of the wp_linux_dmabuf buffer factory.
	110	+ In version 1 of this interface, explicit synchronization is only
	111	+ guaranteed to be supported for buffers created with any version of the
	112	+ wp_linux_dmabuf buffer factory. Version 2 additionally guarantees
	113	+ explicit synchronization support for opaque EGL buffers, which is a type
	114	+ of platform specific buffers described in the EGL_WL_bind_wayland_display
	115	+ extension. Compositors are free to support explicit synchronization for
	116	+ additional buffer types.
106	117	</description>
107	118
108	119	<request name="destroy" type="destructor">
...	...	@@ -215,6 +226,11 @@
215	226	signaled when all operations by the compositor on that buffer for that
216	227	commit have finished.
217	228
	229	+ Once the fence has signaled, and assuming the associated buffer is not
	230	+ pending release from other wl_surface.commit requests, no additional
	231	+ explicit or implicit synchronization is required to safely reuse or
	232	+ destroy the buffer.
	233	+
218	234	This event destroys the zwp_linux_buffer_release_v1 object.
219	235	</description>
220	236	<arg name="fence" type="fd" summary="fence for last operation on buffer"/>
...	...	@@ -227,6 +243,11 @@
227	243	using it, or has a guarantee that all its operations on that buffer for
228	244	that commit have finished.
229	245
	246	+ Once this event is received, and assuming the associated buffer is not
	247	+ pending release from other wl_surface.commit requests, no additional
	248	+ explicit or implicit synchronization is required to safely reuse or
	249	+ destroy the buffer.
	250	+
230	251	This event destroys the zwp_linux_buffer_release_v1 object.
231	252	</description>
232	253	</event>

unstable/pointer-gestures/pointer-gestures-unstable-v1.xml

---

1	1	<?xml version="1.0" encoding="UTF-8"?>
2	2	<protocol name="pointer_gestures_unstable_v1">
3	3
4		- <interface name="zwp_pointer_gestures_v1" version="1">
	4	+ <interface name="zwp_pointer_gestures_v1" version="2">
5	5	<description summary="touchpad gestures">
6	6	A global interface to provide semantic touchpad gestures for a given
7	7	pointer.
...	...	@@ -37,9 +37,18 @@
37	37	<arg name="id" type="new_id" interface="zwp_pointer_gesture_pinch_v1"/>
38	38	<arg name="pointer" type="object" interface="wl_pointer"/>
39	39	</request>
	40	+
	41	+ <!-- Version 2 additions -->
	42	+
	43	+ <request name="release" type="destructor" since="2">
	44	+ <description summary="destroy the pointer gesture object">
	45	+ Destroy the pointer gesture object. Swipe and pinch objects created via this
	46	+ gesture object remain valid.
	47	+ </description>
	48	+ </request>
40	49	</interface>
41	50
42		- <interface name="zwp_pointer_gesture_swipe_v1" version="1">
	51	+ <interface name="zwp_pointer_gesture_swipe_v1" version="2">
43	52	<description summary="a swipe gesture object">
44	53	A swipe gesture object notifies a client about a multi-finger swipe
45	54	gesture detected on an indirect input device such as a touchpad.
...	...	@@ -102,7 +111,7 @@
102	111	</event>
103	112	</interface>
104	113
105		- <interface name="zwp_pointer_gesture_pinch_v1" version="1">
	114	+ <interface name="zwp_pointer_gesture_pinch_v1" version="2">
106	115	<description summary="a pinch gesture object">
107	116	A pinch gesture object notifies a client about a multi-finger pinch
108	117	gesture detected on an indirect input device such as a touchpad.

unstable/xdg-output/xdg-output-unstable-v1.xml

---

...	...	@@ -54,7 +54,7 @@
54	54	reset.
55	55	</description>
56	56
57		- <interface name="zxdg_output_manager_v1" version="2">
	57	+ <interface name="zxdg_output_manager_v1" version="3">
58	58	<description summary="manage xdg_output objects">
59	59	A global factory interface for xdg_output objects.
60	60	</description>
...	...	@@ -77,12 +77,17 @@
77	77	</request>
78	78	</interface>
79	79
80		- <interface name="zxdg_output_v1" version="2">
	80	+ <interface name="zxdg_output_v1" version="3">
81	81	<description summary="compositor logical output region">
82	82	An xdg_output describes part of the compositor geometry.
83	83
84	84	This typically corresponds to a monitor that displays part of the
85	85	compositor space.
	86	+
	87	+ For objects version 3 onwards, after all xdg_output properties have been
	88	+ sent (when the object is created and when properties are updated), a
	89	+ wl_output.done event is sent. This allows changes to the output
	90	+ properties to be seen as atomic, even if they happen via multiple events.
86	91	</description>
87	92
88	93	<request name="destroy" type="destructor">
...	...	@@ -157,6 +162,10 @@
157	162
158	163	This allows changes to the xdg_output properties to be seen as
159	164	atomic, even if they happen via multiple events.
	165	+
	166	+ For objects version 3 onwards, this event is deprecated. Compositors
	167	+ are not required to send it anymore and must send wl_output.done
	168	+ instead.
160	169	</description>
161	170	</event>
162	171
...	...	@@ -197,10 +206,12 @@
197	206	output via :1'.
198	207
199	208	The description event is sent after creating an xdg_output (see
200		- xdg_output_manager.get_xdg_output). This event is only sent once per
	209	+ xdg_output_manager.get_xdg_output) and whenever the description
	210	+ changes. The description is optional, and may not be sent at all.
	211	+
	212	+ For objects of version 2 and lower, this event is only sent once per
201	213	xdg_output, and the description does not change over the lifetime of
202		- the wl_output global. The description is optional, and may not be sent
203		- at all.
	214	+ the wl_output global.
204	215	</description>
205	216	<arg name="description" type="string" summary="output description"/>
206	217	</event>

—
View it on GitLab.
You're receiving this email because of your account on salsa.debian.org. If you'd like to receive fewer emails, you can adjust your notification settings.