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
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>
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>
There's no protocol error for making requests on the object after the wl_surface
has been destroyed, so the object has to become inert in that case.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
The strict "mailbox" model of wayland past is not how modern compositors
process commits, and many explanations of how double buffered state is
applied throughout wayland-protocols are no longer strictly accurate.
Instead of trying to define double-buffered state at every point of use,
just reference the evolving definition of wl_surface.commit.
This still leaves a few old definitions that weren't trivially updated.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This protocol allows clients to set an alpha multiplier for the whole surface,
which allows it to offload alpha changes for the whole surface to the compositor,
which in turn can offload them to KMS.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
This simple protocol definition allows clients to express a "dialog"
relationship of a toplevel with its parent and extend the possible
hints. This allows compositors to attach certain behavior according
to these hints.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com>
This protocol allows applications to request that a window is moved
at the same time as a drag operation - effectively dragging windows.
With this features such as detaching a tab from a window and reattaching
it, dragging tabs between windows or (un)dockable tool windows can
be implemented.
Based on the previously proposed extended drag protocol but trimmed
down.
Signed-off-by: David Redondo <kde@david-redondo.de>
Specifically this also changes the well-known name for flatpak from
"flatpak" to "org.flatpak". This would be a breaking change but there is
no released version of flatpak yet with security-context support.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Specifically that after calling create_listener the only valid operation
on the sockets is to close them. They also must stay open and valid
until a round-trip after the call.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
This is a variation of the unveil protocol I suggested in the Weston
issue about security contexts. This lets sandbox engines such as Flatpak
attach a security context to sandboxed clients. The compositor can then
restrict which features are made available to that client.
The protocol is designed around the assumption that the sandbox engine
uses this protocol when setting up the sandboxed application. After this
inital setup, the sandbox engine isn't necessarily running anymore.
For this reason, a special "close FD" is used to indicate when to stop
the security context listener: the sandbox engine can leak the FD into
the sandboxed app's process, and the OS will automatically close the FD
when the sandboxed app exits.
Signed-off-by: Simon Ser <contact@emersion.fr>
References: https://gitlab.freedesktop.org/wayland/weston/-/issues/206
All other protocols in wayland-protocols are released under the MIT
license and this one was only merged with the ISC license by accident.
I am the only person who has touched this protocol in commits and the
only copyright holder, so relicensing to bring this protocol in line
with the rest is easy in this case.
References: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/119
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
Clients such as swaylock [1] or waylock [2] provide options to fork and
detach from the controlling terminal when the session is locked. The
point of these options is avoid a race on suspending the system. A
command to suspend the system (e.g. zzz) may safely be chained with
e.g. waylock as so:
waylock -fork-on-lock && zzz
However, there is no guarantee that the compositor has actually
blanked all outputs before sending the locked event. Therefore there
is still a race as new "locked" frames may not have been presented on
all outputs before the system is suspended.
On my Linux system at least, the current framebuffer seems to be
preserved on suspend and restored on resume, leading to an "unlocked"
frame potentially being displayed when the system is resumed. Blanking
all outputs before suspend eliminates this vulnerability.
Currently clients could theoretically implement such -fork-on-lock
options a bit better if the compositor supports the presentation-time
protocol, however no clients I've seen currently do this and it seems
wise to make clients to do the right thing by default in this security
sensitive context. The presentation-time protocol is also not sufficient
in all cases, for example if the compositor has turned off power of an
output but still exposes it to clients. In this case the client would
wait forever to get a presentation feedback that will never come.
Unfortunately, the protocol currently states that the locked event will
be sent immediately on creation of the ext_session_lock_v1 object rather
than after all normal content is hidden.
Several different approaches have been considered for how to fix this in
the protocol specification.
One possibility would be to add a new event sent when all normal content
is hidden. This is however opt-in for clients and therefore less likely
to be properly implemented by all clients in practice.
Another alternative is to bump the version of the ext_session_lock_v1
interface and state that the semantics of when the compositor will send
the locked event. However, this still requires clients to opt-in by
binding version 2 of the interface. The compositor could technically
deny the attempts of any version 1 clients to lock the session, but this
would likely be a bad breaking change for users of version 1 clients.
While session lock clients should inform the user in some way that their
attempt to lock the session was denied (e.g. by exiting non-zero) it
does not seem to be the case that such exit codes are widely checked.
The option to fix the protocol that is all around the most secure is
changing the semantics of the locked event without bumping the version
of the interface. This is technically a breaking change, but the failure
mode is that a client relying on the locked event being sent immediately
hangs or crashes and the session stays locked.
I also have been unable to find any session lock client in the wild that
relies on the locked event being sent immediately.
The river wayland compositor [3] in fact already implements the fix for
this race condition since the 0.2.0 release and has not received any bug
reports about broken session lock clients yet.
Therefore, I think that making this technically breaking change to the
protocol is our all around best option in this situation. Prioritizing
security over compatibility seems like the right trade-off to make for a
security critical protocol.
[1]: https://github.com/swaywm/swaylock
[2]: https://github.com/ifreund/waylock
[3]: https://github.com/riverwm/river
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
If the compositor advertises an output as a wp_drm_lease_connector_v1
and as wl_output, it should make the names match to allow clients to
identify the connection between the two outputs.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
This protocols allows for communicating preferred fractional scales to
surfaces, which in combination with wp_viewport can be used to render
surfaces at fractional scales when applicable.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
For some use cases like games or drawing tablets it can make sense to reduce
latency by accepting tearing with the use of asynchronous page flips. This
protocol provides a way for clients to indicate whether or not their content
is suitable for this kind of presentation.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
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>
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>
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>
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>
