It's needed for the deprecated-since attribute [1] introduced with [2],
at least when building the tests, which pass the '--strict' parameter to
wayland-scanner.
[1] ee12e69b8f
[2] 6c214e6dc0
Signed-off-by: Heiko Becker <mail@heiko-becker.de>
with great NACKs come great responsibility:
* if you abuse this power, you should be held accountable
* if you should not be using this power, you should be held accountable
Signed-off-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
these have a lower bar to clear for inclusion and are intended to
promote rapid development with greater community involvement
Signed-off-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
We were using 'member' to generally mean 'member project', but this
wasn't super clear, and sometimes it also meant an individual person.
Clarify it such that project vs. individual is clear where it's
relevant, leaving 'member' only for when it's not relevant.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Drew is no longer active in the Wayland community. Simon Zeni is
the wlroots point-of-contact and is very familiar with DRM leasing.
Signed-off-by: Simon Ser <contact@emersion.fr>
This protocol allows a privileged client to control data devices. In
particular, the client will be able to manage the current selection and take
the role of a clipboard manager.
This is a straight port from wlr-data-control-unstable-v1 to ext-, as it
has not changed in five years and has near-universal compositor adoption.
Signed-off-by: Neal Gompa <neal@gompa.dev>
When this extension was developed, we did not yet know how VRR hardware
would behave in practice as it was not standardised, and the KMS
interface was equally unstandardised.
Now things have shaken out to an acceptable level, we have a good idea
of what we need, which is simply to include a base refresh rate - the
rate the compositor would drive the display for non-VRR clients.
Bump the protocol to version 2 and require the compositor to provide
a rate.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Add a new protocol for adding timestamps to wayland surface state to
allow deferring processing until later.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Add a new protocol to allow a content update to require a
display refresh pass before it is ready to present.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Originally we wanted to have an official website to document
adoption. However this never materialized.
I don't think the governance document is the right place for this
anyways.
Signed-off-by: Simon Ser <contact@emersion.fr>
This is meant to let applications ring the system bell. It needs to be a
Wayland protocol because a system bell is not necessarily audiable; for
for example accessibility reasons, it might need be a visual feedback,
which may be tied to a specific window. Accessibility features are
usually configured globally, and one likely wants identical visual
feedback for all system bell ringings, so it doesn't fit as a client
side only feature.
This aims to replaced and deprecate the `gtk_shell1.system_bell`
request.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
It was undefined before how long the wp_cursor_shape_device_v1 has any
effect. Let's specify that the object becomes inert when the pointer cap
goes away or the tablet tool is removed. In those cases the client has
to create a new pointer/tablet tool, and also a new cursor shape device
when the cursor caps or a new tablet tool reappears.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/186
Generate and install headers containing enums. See [1].
Meson requires us to generate headers in a "include/wayland-protocols"
directory, so that include paths can be properly set up when used
as a sub-project.
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/312
Signed-off-by: Simon Ser <contact@emersion.fr>
The current description is not clear about it, though the only available
implementation works like that, so make it explicit in the protocol
description.
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
The protocol as-is doesn't allow clients to mutate wl_buffers.
Let's make it clear that wl_buffer.release is not used for that
purpose. Buffer re-use can be added in a future protocol version
if desirable.
Add a small note to explain that no wl_buffer mutation implies no
wl_shm_pool's backing storage mutation as well.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/201
It wasn't clear that it's important clients set up their initial
xdg_surface state before they send the initial commit. This is
required for the compositor to be able to send a proper configure
event depending on size constraints and any policies it might want
to apply (e.g. specific app ID always shows up in a designated
workspace).
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Simon Ser <contact@emersion.fr>
Co-authored-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Simon Zeni <simon@bl4ckb0ne.ca>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Simon Ser <contact@emersion.fr>
Co-authored-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Simon Zeni <simon@bl4ckb0ne.ca>
GitLab understands the "Draft:" prefix and will mark the MR
accordingly. GitLab used to understand the "WIP:" prefix, but
that's no longer the case.
Signed-off-by: Simon Ser <contact@emersion.fr>
This protocol allows clients to set icons for their toplevel windows.
Icons can be loaded from the XDG icon stock using their name, or can
alternatively be provided by the client as wl_shm-backed wl_buffer.
A toplevel icon represents the individual toplevel (unlike the
application or launcher icon, which represents the application as a
whole), and may be shown in window switchers, window overviews and
taskbars that list individual windows.
Resolves: #52
Signed-off-by: Matthias Klumpp <matthias@tenstral.net>
