lp://staging/wayland-protocols

Related source package recipes

1 recipe using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

184. By Simon Ser <email address hidden> on 2019-11-20

Add governance document

The idea of a better-defined governance model for wayland-protocols has
been discussed for quite a while [1].

A new GOVERNANCE document describes how changes to the wayland-protocols
repository are accepted. A set of members representing projects can vote
on merge requests sent via GitLab. The initial list of members is
available in the MEMBERS file.

[1]: https://lists.freedesktop.org/archives/wayland-devel/2019-February/040076.html

Signed-off-by: Drew DeVault <email address hidden>
Signed-off-by: Simon Ser <email address hidden>
Acked-by: Daniel Stone <email address hidden>
Acked-by: Pekka Paalanen <email address hidden>
Acked-by: Johan Helsing <email address hidden>
Acked-by: Roman Gilg <email address hidden>
Acked-by: Christopher James Halse Rogers <email address hidden>
Acked-by: Alan Griffiths <email address hidden>
Acked-by: Jonas Ådahl <email address hidden>
Cc: Mike Blumenkrantz <email address hidden>
Cc: Carlos Garnacho <email address hidden>
Cc: David Edmundson <email address hidden>

183. By Ivan Molodetskikh on 2019-09-06

presentation-time: add missing bitfield marker

Signed-off-by: Pekka Paalanen <email address hidden>
Reviewed-by: Simon Ser <email address hidden>
Acked-by: Daniel Stone <email address hidden>
Acked-by: Victor Berger <email address hidden>

182. By Jonas Ådahl on 2019-07-25

configure.ac: Bump version to 1.18

Signed-off-by: Jonas Ådahl <email address hidden>

181. By Simon Ser <email address hidden> on 2019-07-25

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 <email address hidden>
Reviewed-by: Jonas Ådahl <email address hidden>
Acked-by: Olivier Fourdan <email address hidden>

180. By Jan-Marek Glogowski on 2019-07-17

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 <email address hidden>
Reviewed-by: Jonas Ådahl <email address hidden>
Reviewed-by: Simon Ser <email address hidden>

179. By Simon Ser <email address hidden> on 2019-07-17

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 <email address hidden>
Reviewed-by: Jonas Ådahl <email address hidden>

178. By Simon Ser <email address hidden> on 2019-07-17

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 <email address hidden>
Reviewed-by: Olivier Fourdan <email address hidden>
Reviewed-by: Jonas Ådahl <email address hidden>

177. By Jonas Ådahl on 2019-05-22

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 <email address hidden>

176. By Chia-I Wu <email address hidden> on 2019-05-02

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 <email address hidden>
Reviewed-by: Pekka Paalanen <email address hidden>
Reviewed-by: Simon Ser <email address hidden>
Reviewed-by: Daniel Stone <email address hidden>

175. By Sebastian Krzyszkowiak on 2019-01-17

xdg-shell: fix a typo

Signed-off-by: Sebastian Krzyszkowiak <email address hidden>
Reviewed-by: Pekka Paalanen <email address hidden>