The xdg_surface window geometry can extend outside the base wl_surface
to e.g. accompany subsurfaces that extend outside it but is part of the
window itself. Spell out this bit explicitly.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
The spec says that
When applied, the effective window geometry will be the set
window geometry clamped to the bounding rectangle of the combined
geometry of the surface of the xdg_surface and the associated
subsurfaces.
Thus, a client cannot assume the geometry will adapt to any subsequent
changes to any conditions that constrained the geometry.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Make it explicit in the protocol that [un]set_maximized and
the following configure event can't be reliably matched, and the
clients shouldn't try to do it.
Closes#106
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
This will let command-line Git tools re-map my name and e-mail address properly.
I'm using my personal e-mail address and not my Collabora address because I'm
not actively contributing to Wayland anymore and this is mostly for letting
people find me should they dig me up in the project history.
Signed-off-by: Faith Ekstrand <faith@gfxstrand.net>
The "logical size" as stated by the first paragraph corresponds to the
monitor size in the global compositor space.
To most clients, this is unnecessary information, and should be ignored,
but some used the listed examples to derive information that contradicts
the very definition of what this event communicates.
One example tried to add surface size assumptions, which was not
correct. Remove this part completely, clients should not try to
configure their surface sizes from the logical size of a monitor.
The other is the list of size examples; it tried to communicate that a
compositor sometimes may not scale the viewport of the monitor in its
global compositor coordinate space, in which case, the logical size
itself matches the actual resolution. Tweak this wording to make that
clear that it does not related to any surface size.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
In the past, xdg-output had only the logical_position and
logical_size events, then the name and description events were
added. Later on, they were moved inside wl_output since they aren't
desktop-specific. However the goals section of the protocol overview
hasn't been updated accordingly.
Make it clear that this protocol's name and description events should
not be preferred over wl_output.
Signed-off-by: Simon Ser <contact@emersion.fr>
These have been merged into wl_output. Clients should prefer
using wl_output events instead of relying on xdg-output.
Signed-off-by: Simon Ser <contact@emersion.fr>
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 "ext" and "wp", the document uses the wording "ACKed by at
least 3 members". For "ext", the document uses the wording "ACKed
by at least one other member".
This is confusing, let's just use the same wording everywhere.
Signed-off-by: Simon Ser <contact@emersion.fr>
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>
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>
