Even though it is part of wayland.xml, wl_shell is not mandatory for
compositors to implement, and may be removed in a future version.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
These events are for high-resolution wheels. Each logical wheel click
represents an axis value120 value of 120, fractions of a wheel click an
integer fraction thereof. The new event replaces
wl_pointer.axis_discrete for wl_pointer versions 8 and above.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Protocol documentation mistakenly specified that wl_shm.format
events are sent at connection setup time, but that's impossible
(clients do not yet know ID of wl_shm object at the time) and
contradicts implementation in libwayland.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Add a note that the request only changes the size of the memory mapping
and does not touch the mapped file.
Signed-off-by: Max Ihlenfeldt <mihlenfeldt@igalia.com>
Clearly specify that switching focus within the same client
doesn't mean a new selection will be send.
Signed-off-by: Jan Grulich <jgrulich@redhat.com>
The four new formats added (all 16 bpc, RGB colorspace) are very useful
for applications providing high bit depth content and rendering their
buffers on CPU, as computations with 16 bit unsigned integers are often
more efficient than with the (half float, 10 bit) alternative formats.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Add a note about pre-multiplied alpha for all wl_shm formats.
Include an escape hatch in the spec to allow other protocol
extensions to override this.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/61
This is inspired from xdg-output-unstable-v1. This allows clients to
get the name and description without having to use xdg_output. This
should eventually allow us to restrict xdg_output to clients like
Xwayland.
The name is a unique non-persistent user-friendly string that can be
used to refer to an output. This can be used by Wayland clients to
refer to a specific wl_output (e.g. across processes or in CLI
arguments).
The description is a non-unique user-friendly string that can be
displayed to the user.
Signed-off-by: Simon Ser <contact@emersion.fr>
References: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/7
This is meant to address the issue where the call to 'wl_surface.attach'
is done by e.g. Vulkan, meaning applications cannot affect the values of
the offset passed as the x and y arguments.
The lack of ability to pass these is problematic when using the Vulkan
for e.g. drawing DND surfaces, as the buffer offset is used to implement
the drag icon hotspots.
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/148
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
It may be obvious that the mapping must be established in read-only
mode, but it wasn't specified in the specification text.
Signed-off-by: Simon Ser <contact@emersion.fr>
Allow wl_buffer objects to be destroyed without having to wait for
wl_buffer.release if the underlying storage isn't going to be
re-used.
The main motivation for this is to avoid glitches when a client is
torn down. When a client disconnects, all of its objects are destroyed
in arbitrary order. However some compositors will still need to
access the destroyed buffer's underlying storage afterwards, e.g. for
visual effects (fade-out) or for atomic layout updates (wait for other
clients to commit a new buffer before hiding the buffer).
It's still incorrect for clients to destroy a wl_buffer and mutate
the underlying storage without waiting for wl_buffer.release.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/185
Change the wl_drm reference to linux-dmabuf. wl_drm is a legacy,
private Mesa protocol that shouldn't be used by regular clients.
Signed-off-by: Simon Ser <contact@emersion.fr>
Serial is supposed to contain the latest wl_pointer.enter value received
by clients but it was not even mentioned in the docs, so add it to avoid
misinterpretations.
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
This adds 4 new formats.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
The current wl_output.mode event has several issues when used to advertise
modes that aren't current:
- It's not possible to remove some modes. This is an issue for virtual
outputs and when the kernel prunes some modes because of link limitations.
- wl_output.mode fails to carry metadata such as aspect ratio, which results
in duplicated or missing modes.
- It's not clear, given the current set of protocols, how non-current modes
are useful to clients. Xwayland ignores non-current modes.
GNOME and wlroots already only advertise the current mode because of these
issues.
If a protocol needs the clients to know about all available modes, it should
advertise these modes itself instead of relying on wl_output.mode.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/92
Some clients rely on wl_surface.enter/leave to start/stop their rendering
loop.
There are cases where this doesn't work:
- Some compositors don't send wl_surface.leave when a toplevel is hidden.
For instance Sway doesn't send this event when a toplevel is on an inactive
workspace (but doesn't send wl_surface.frame events).
- Some compositors might still want applications to continue to render even if
away from outputs. For instance a compositor that allows to screen record
individual toplevels might not send a wl_surface.enter event for hidden
toplevels.
Signed-off-by: Simon Ser <contact@emersion.fr>
Explicitly say that destroying a wl_data_source previously used in a
wl_data_device::start_drag request will cancel the DND session. This
is currently the only way to do it from client side (besides those
"indirect" ones already documented) and all compositors work like that
but it is not clear spec-wise it is the expected behaviour.
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
Explain that wl_keyboard.key yields platform-specific key codes.
Some compositors use Linux key codes (defined in the
linux/input-event-codes.h header file, e.g. KEY_ESC), however
clients should not assume that this is always the case. The only
reliable way for clients to interpret key codes is to feed them
into a keyboard mapping.
Signed-off-by: Simon Ser <contact@emersion.fr>
Clients must assume that every key, including modifiers, are lifted
after getting wl_keyboard.leave event, not doing so could lead to key repeat
keep going after the user changes focus, or stuck modifiers, when the user
interacts with client without keyboard focus.
Signed-off-by: Kirill Chibisov <contact@kchibisov.com>
Consider that we set the modifier for the modifier key as well, and that
you have the option to change your layout when both shifts pressed. This
realized by making the shift keys produce 'Group_switch' when you press
the shift key and the shift modifier is already active. So sending modifier
before the key event will result in 'Group_switch' each time you press
shift.
That being said, the order of modifiers should be updated after the
key/enter event, so it'll only affect future keypresses, not the current one.
See: https://lists.x.org/archives/xorg-devel/2014-July/043110.html
Signed-off-by: Kirill Chibisov <contact@kchibisov.com>
The protocol says:
> It is a protocol violation to issue this request on a seat that
> has never had the pointer capability.
But never defines an error code.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/165
This is the style used in wayland.xml which is the only file we really
care about for git blame information. So let's adjust all others to that
style for consistency and fix editorconfig to avoid messing this up in
the future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This allows the compositor to send an error when the client submits a buffer
whose size is not divisible by the buffer scale. Previously, the protocol said
it was a client error but didn't specify any error code.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland/issues/145
Currently libwayland sends a wl_display.invalid_method when arguments provided
with a request are invalid (e.g. too short, see wl_client_connection_data).
Clarify the protocol by adding that invalid_method can be sent on malformed
request.
Signed-off-by: Simon Ser <contact@emersion.fr>
Add a comment to wl_shm.format to advise contributors to use the automated
script (generate-shm-formats.py) instead of updating the list manually.
Signed-off-by: Simon Ser <contact@emersion.fr>
The original text makes some assumptions about surfaces which may not be
true and fails to capture some details which are important to the
essential traits of a wl_surface.
Fixes#46
The way wl_buffer is specified makes this situation inherently racy,
meaning there is no way this can be done unambiguously. Current real
compositor implementations already have differing behaviour for this, so
any client relying on it was already broken, if any such client exists.
This specifically only singles out wl_buffer.release as being undefined;
every other aspect of it should still be valid. This is so existing and
correct uses of multiple attaches are still valid, where a
"static"/immutable wl_buffer is being used (i.e. they don't care about
the release event).
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
libwayland-server only sends wl_display.delete_id events when
it responds to a client's destruction of a client-allocated
object. server-allocated objects are silently removed, as per
`wl_resource_destroy`.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Fixed refresh rate doesn't always make sense for all outputs. In case
it's not available or not relevant, allow compositors to send zero.
For instance the can be the case for virtual outputs.
Signed-off-by: Simon Ser <contact@emersion.fr>
Explicitly state that the invalid_finish protocol error would be raised
when wl_data_offer.finish request is sent for non drag-and-drop
operations.
Signed-off-by: Harish Krupo <harishkrupo@gmail.com>
All wl_output properties don't always make sense for all
compositors.
Some compositors might not implement a "global compositor space",
(e.g. 3D compositors) in which case properties like x and y don't
make sense.
Some compositors might expose virtual outputs, in which case modes,
make and model are not relevant.
In a lot of these situations, information from xdg_output is better
suited.
Compositors also expose output refresh rate, which shouldn't be used
for synchronization purposes.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Derek Foreman <derek.foreman.wayland@gmail.com>
Many languages such as C++ or Rust have an unwinding error-reporting
mechanism. Code in these languages can (and must!) wrap request handling
callbacks in unwind guards to avoid undefined behaviour.
As a consequence such code will detect internal server errors, but have
no way to communicate such failures to the client.
This adds a WL_DISPLAY_ERROR_IMPLEMENTATION error to wl_display so that
such code can notify (and disconnect) clients which hit internal bugs.
While servers can currently abuse other wl_display errors for the same
effect, adding an explicit error code allows clients to tell the
difference between errors which are their fault and errors which are the
server's fault. This is particularly interesting for automated bug
reporting.
v2: Rename error from "internal" to "implementation", in sympathy with
X11's BadImplementation error.
Add more justification in the commit message.
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This commit makes wl_surface.damage_buffer preferred over wl_surface.damage.
wl_surface.damage can be implemented in a non-optimal way by the compositor
(e.g. by always damaging the whole buffer).
Having two requests makes it complicated for the compositor to handle damage,
making it necessary to transform one into the other's coordinates.
Moreover, integration with wp_viewporter is tricky.
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Weston commit 76829fc4eaea329d2a525c3978271e13bd76c078 (and similar
commits for other compositors) protects the compositor's keyboard
mapping from client damage by duplicating the keymap for every
client.
On some systems there are other potential fixes for this - such as
using sealed memfds on linux - but we can't use them since
essentially all client code anywhere has mapped the keyboard map
with a MAP_SHARED mmap() call.
While we can't break years worth of code, we can require any future
clients to use MAP_PRIVATE if they use a seat version above 6.
If a compositor can't use sealing or a similar facility, it should
still protect itself with copied keymaps, but clients must always
assume shared mapping of a keymap will fail.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Philipp Kerling <pkerling@casix.org>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Physical size doesn't always make sense for all outputs. In case
it's not available or not relevant, allow compositors to send zero.
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
The existing specification was not explicitly clear on when
wl_subcompositor.get_subsurface request actually adds the sub-surface to
the parent in the compositor's scenegraph. The implicit assumption was
that this happens immediately, but it was not written anywhere.
If it happens immediately, the client doing things in a wrong order may
cause a glitch on screen. Particularly, if the wl_surface B that is
going to be a sub-surface for wl_surface A (the parent) already has a
buffer committed, and the parent surface is mapped, then get_subsurface
will (may?) cause wl_surface B to become mapped immediately. That leaves
no time to set up the sub-surface z-order or position before mapping,
hence there can be a visible glitch.
The way to avoid that, given that the parent surface is mapped, is to
not commit a buffer to wl_surface B until all the sub-surface setup is
done.
However, doing the sub-surface setup always requires a wl_surface.commit
on the parent surface unless the defaults happen to be correct.
To make setting up a subsurface slightly easier by removing one
possibility for a glitch, this patch amends the specification to require
a wl_surface.commit on the parent surface for get_subsurface to
complete. The sub-surface cannot become mapped before a parent commit.
This change may break existing clients that relied on the glitchy
sequence to not need a parent surface commit to map the sub-surface.
However, presumably all uses would at least issue a
wl_subsurface.set_position, which requires a parent surface commit to
apply. That would guarantee that there is a parent surface commit after
get_subsurface, and so reduces the chances of breaking anything.
In other cases, this change may simply remove a possibility for the
glitch.
This patch also adds a note about changing wl_surface.commit behaviour
on wl_subcompositor.get_subsurface. (That could be a separate patch.)
The behaviour of wl_subsurface.destroy remains as specified, even though
it is now slightly asymmetrical to get_subsurface. This is emphasized by
adding the word "immediately". The effects of destruction were already
explicitly documented, as is the way to achieve synchronized unmapping,
so changing destruction behaviour would likely be more disruptive, and
also open up more corner cases (what would happen between destroy and
unmapping?).
Bug: https://phabricator.freedesktop.org/T7358
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Martin Gräßlin <mgraesslin@kde.org>
Now that xdg_shell is stable and much better defined than wl_shell we
can finally deprecate wl_shell and guide users towards xdg_shell
instead.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
