This was originally set to `content_type`, but the protocol defines an enum named `type`. This fixes an issue with the protocol that was noticed when binding the protocol in wayland-rs.
Signed-off-by: i509VCB <git@i509.me>
This protocol adds a xwayland_surface role which allows an Xwayland
server to associate an X11 window to a wl_surface.
Before this protocol, this would be done via the Xwayland server
providing the wl_surface's resource id via the WL_SURFACE_ID atom on the
X window. This was problematic as a race could occur if the wl_surface
associated with a WL_SURFACE_ID for a window was destroyed before the
update of the atom was processed by the compositor and another surface
(or other object) had taken its id due to recycling.
This protocol solves the problem by moving the X11 window to wl_surface
association step to the Wayland side, which means that the association
cannot happen out-of-sync with the resource lifetime of the wl_surface.
This protocol avoids duplicating the race on the other side by adding a
non-zero monotonic serial number which is entirely unique that is set on
both the wl_surface (via. xwayland_surface_v1's associate method) and
the X11 window (via. the `WL_SURFACE_SERIAL` atom) that can be used to
associate them, and synchronize the two timelines.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Clients must send ack_configure in a strictly monotonic order wrt
received configure events. It is an error to send an ack_configure
request for a configure event which was sent prior to the last
ack_configure for that surface, or to send multiple ack_configures for
the same configure event.
Weston and wlroots already use this interpretation, however Mutter and
KWayland are more lax and allow duplicates. This clarification tightens
the spec working to explicitly encode the Weston/wlroots behaviour.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/21
This helps with merge conflicts when a protocol is merged. This is
also more consistent with the other protocol lists above.
Signed-off-by: Simon Ser <contact@emersion.fr>
This protocol lets clients advertise which kind of content they expect
to be displayed on a given surface, so that the compositor can make more
informed decisions about its behavior and output configuration.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
This patch adds a new ext-idle-notify protocol. It allows clients to be
notified when the user is idle. Use-cases include e.g. power management
daemons.
This protocol is based on the org_kde_kwin_idle interface already being
used by KDE and wlroots compositors. The protocol has been sent to
wayland-protocols in 2015 [1]. This version renames and clarifies the
interfaces, and addresses the review comments.
[1]: https://lists.freedesktop.org/archives/wayland-devel/2015-December/026045.html
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/8
Reviewed-by: David Edmundson <davidedmundson@kde.org>
This protocol allows creating single-pixel buffers. It can be useful
to avoid having to allocate a real buffer just to fill it with the
same pixel value. Some use-cases include drawing background surfaces
or toplevel decorations.
Signed-off-by: Simon Ser <contact@emersion.fr>
Some compositors don't implement all of the features of xdg-shell.
This results in UI elements (e.g. buttons) in clients which do
nothing when activated.
Add a wm_capabilities event to allow clients to hide these UI elements
when they don't make sense.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/64
Fixes the following warning:
NOTICE: Future-deprecated features used:
* 0.55.0: {'ExternalProgram.path'}
* 0.56.0: {'dependency.get_pkgconfig_variable'}
Signed-off-by: Simon Ser <contact@emersion.fr>
This mandate makes explicit a practice that's already established in
the writing of the protocol descriptions, and officially clarifies the
meaning of the keywords for readers.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
This paragraph contains an incomplete definition of how
wl_surface.attach x/y arguments functions, and makes no reference to the
similar wl_surface.offset.
The paragraph states that there is no effect on the behavior of
wl_surface.attach. Rather than elaborating on its definition and adding
wl_surface.offset, remove the paragraph and let their definition be up
to wl_surface itself.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Here's a long story. The serial is formerly described as:
When the client receives a done event with a serial different than the
number of past commit requests, it must proceed as normal, except it
should not change the current state of the zwp_text_input_v3 object.
Upon first reading it might be obvious to interpret "proceed as normal"
as "apply the changes made by the done event" and "not change the current
state" as "do not make requests on it until serial matches with
expectations again". This would turn the serial into a flow control
mechanism to avoid pushing state changes that we know might be stale.
GTK however makes another outlandish interpretation, where "proceed as
normal" means "ignore the changes made by the done event" and "not change
state of the zwp_text_input_v3 object" is "not change client state". This
makes the serial a full synchronization mechanism where IM commands that
are deemed out of sync are symply ignored.
This would seem a misinterpretation of the protocol, and I proceeded to
change the behavior in GTK. Then some deja vu feeling struck me and I found
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/384#note_344864, this
change was already done and discussed in the past. Not just that, it is
the right interpretation.
However, there's some notable disadvantages, there's 2 easy ways to
completely break the synchronization between compositor and client:
Having the IM push new state too often (i.e. multiple consecutive
.done events), or having the client .commit too often. If any of both
peers gets ahead of the other slightly, the end result is ignored input.
More specifically, IBus has no provision for this kind of transactional
behavior (probably other IMs too), so implementing "emit .done once after
a set of changes" is not quite possible.
Arguably, ignoring IM input is also a bad thing. IMs expect all commands
to be respected and applied in order and might even rely on that in
their own internal state. Since only state changes are flushed on .done
events, partially ignoring IM commands will end up with the client IM state
out of sync.
The usecase described at that GNOME gitlab comment (edited text changes
happening in parallel to IM interaction) trades the handling of an
inherently racy corner case with the worst kind of mishandling (ignoring
user input) if IM/client don't perfectly sync up.
On the other hand, the flow control approach is more lenient with IMs and
clients "getting a step ahead", and more importantly does not punish the
user whenever either IM/client happens to do that. Double down on this
(already intuitively correct) description, and specify further what it
implies.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Drew is no longer involved in Wayland development and has expressed
interest in being removed from the wayland-protocols project.
Thanks for all your contributions throughout the years, Drew!
Signed-off-by: Simon Ser <contact@emersion.fr>
The protocol states that the edges parameter of the resize request must
be one of the values of the resize_edge enum but does not provide a
protocol error value to handle the case where it is not. This commit
adds that error value.
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
This aims to communicate the maximum size a surface should be created
with, and loosely corresponds to the concept of "work area" in the X11
world.
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/17
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This protocol allows for a privileged Wayland client to lock the
session and display arbitrary graphics while the session is locked.
The client is responsible for performing authentication and informing
the compositor when the session should be unlocked. If the client
dies while the session is locked the session remains locked, possibly
permanently depending on compositor policy.
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Now that compositors must send INVALID to advertise support for
implicit modifiers, we can make it a protocol error to add a
DMA-BUF plane with an unsupported format + modifier pair.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
On multi-GPU setups, multiple devices can be used for rendering. Clients
need feedback about the device in use by the compositor. For instance,
if they render on another GPU, then they need to make sure the memory is
accessible between devices and that their buffers are not placed in
hidden memory.
This commit introduces a new wp_linux_dmabuf_feedback object. This
object advertises a preferred main device, a set of preferred
formats/modifiers and target devices.
Each object is bound to a wl_surface and can dynamically update its
feedback parameters. This enables fine-grained per-surface
optimizations. For instance, when a surface is scanned out on a GPU the
compositor isn't compositing with, the target device can be set to this
GPU to avoid unnecessary roundtrips.
A feedback object can also be standalone for clients that don't support
per-surface feedback.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Closes: https://gitlab.freedesktop.org/wayland/wayland/issues/59
Add a note about pre-multiplied alpha for all DRM formats.
Include an escape hatch in the spec to allow other protocol
extensions to override this.
Essentially the same as [1].
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/187
Signed-off-by: Simon Ser <contact@emersion.fr>
It's been a few releases that we ship Meson support, we should be
able to drop the old autotools build system now.
Signed-off-by: Simon Ser <contact@emersion.fr>
On Genode, graphics drivers run in user space. It is also theoretically
possible for a Wayland compositor to run in kernel space. Therefore,
the phrase “user space” should be avoided in a Wayland protocol
specification.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
When linking for macOS, this linker flag is rejected. Instead of
always passing it, we can check whether it is supported first.
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
Reviewed-by: Simon Ser <contact@emersion.fr>
I am trying to cross-compile from macOS for FreeBSD and this is currently
failing since the tests attempt to build a native binary that links
against the wayland-client and wayland-server libraries for the FreeBSD
system. I believe we should be building them for the target system and
not the current host (especially since there is no way to build
wayland-client and wayland-server for macOS, but I do want to check that
the files build correctly for FreeBSD).
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
Reviewed-by: Simon Ser <contact@emersion.fr>
