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>
Hold gestures merely denote "there are fingers on the touchpad but they are
not moving". As touchpad touches are generally fully abstracted, a client
cannot currently know when a user is interacting with the touchpad without
moving - no motion events will be sent in this case.
The two use-cases here are:
- hold-to-interact: where a hold gesture is active for some time
a menu could pop up, or some object is selected, etc.
- hold-to-cancel: where e.g. kinetic scrolling is currently active, the start
of a hold gesture can be used to stop the scroll
Since hold gestures by definition do not have movement, there is no need for
an "update" stage in the gesture.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We use the no-op executables in test() directives, so these will be
run on the host. This fixes the following warning:
tests/meson.build:23: WARNING: add_languages is missing native:, assuming
languages are wanted for both host and build.
Signed-off-by: Simon Ser <contact@emersion.fr>
When we're building C++ test executables, make sure we pull in the
correct libwayland headers, to avoid trying to compile against a version
different from the scanner we built it against.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The newlines prevent the labels from being properly formatted.
Additionally, the second label reference has a typo (extra "s").
Signed-off-by: Simon Ser <contact@emersion.fr>
DRM leasing is a feature which allows the DRM master to "lease" a subset
of its DRM resources to another DRM master via drmModeCreateLease, which
returns a file descriptor for the new DRM master. We use this protocol
to negotiate the terms of the lease and transfer this file descriptor to
clients.
In less DRM-specific terms: this protocol allows Wayland compositors to
give over their GPU resources (like displays) to a Wayland client to
exclusively control.
The primary use-case for this is Virtual Reality headsets, which via the
non-desktop DRM property are generally not used as desktop displays by
Wayland compositors, and for latency reasons (among others) are most
useful to games et al if they have direct control over the DRM resources
associated with it. Basically, these are peripherals which are of no use
to the compositor and may be of use to a client, but since they are tied
up in DRM we need to use DRM leasing to get them into client's hands.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Drew DeVault <sir@cmpwn.com>
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
After a requesting client receives a new token, the client usually forwards the
token string to another client by a different process, which then uses the
token in an activate request. For that the token string must be transferred to
the other process.
Two default ways of doing that were described in the done event, but the
description had some issues and it makes more sense to describe them in the
protocol description itself, which talks about the protocol in a more general
way. Therefore rewrite the paragraphs about token forwarding between clients
and place them in the protocol description.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
The Wayland client requests surface activation directly using the token
that it received from the X11 client.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
