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 allows specifying events to be destructors, which is useful for
non-C language bindings. It is unused in wayland-scanner.
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
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>
This prevents mismatches and missing formats between wl_shm.formats and
drm_fourcc.h.
The script collects DRM_FORMAT_* constants from drm_fourcc.h, compares the list
with the current wayland.xml entries (checking for any mismatch) and then
appends missing entries to wayland.xml.
Enum values are obtained by executing a generated C file which prints the
constants. There is no other reliable way to get these values as they are
defined via various macros.
There is no widespread Python library able to parse an XML file and format it
with all whitespace preserved. For this reason, we don't use an XML library to
create the new XML elements. Instead, we keep track of the line number of the
last wl_shm.format enum entry and add new entries right after. To be able to
read the line number of an element, we use lxml (the standard library doesn't
retain line number information).
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>
Until recently, if an event attempting to deliver an fd to a zombie
object was demarshalled after the object was made into a zombie, we
leaked the fd and left it in the buffer.
If another event attempting to deliver an fd to a live object was in that
same buffer, the zombie's fd would be delivered instead.
This test recreates that situation.
While this is a ridiculously contrived way to force this race - delivering
an event from a destruction handler - I do have reports of this race
being hit in real world code.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Until recently, if a client destroying a resource raced with the
server generating an event on that resource that delivered a file
descriptor, we would leak the fd.
This tests for a leaked fd from that race condition.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Derek Foreman <derekf@osg.samsung.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>
I've heard some complaints that wl_display.get_registry "leaks"
server memory because wl_registry has no destructor. While this isn't
strictly true - all those resources are freed when the client
disconnects - it's a bit of a gotcha for neophytes.
Since wl_registry's version is not requested in any way through
wl_display.get_registry, we can't add a destructor request without
breaking ABI. So let's be a little more clear about the result
of getting too many wl_registry objects.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Unlike a wheel rotation, a wheel tilt is a discrete-only axis. Wheel rotations
are mapped to degrees in libinput but that that does not apply to wheel tilt
axes where there is no physical equivalent.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
8 spaces changed to one tab
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Bryce Harrington <bryce@osg.samsung.com>
Because we already rely on it in the callers anyway. This is a retrofit, which
is not ideal but I'm not sure any compositor out there uses anything else.
Might as well define it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This CL updates the wl_touch interface with a shape and
orientation event.
The shape/orientation of a touch point is not relevant for most UI
applications, but allows a better experience in some cases
such as drawing apps.
The events are used by the compositor to inform the client
about changes in the shape and orientation of a touchpoint, which is
approximated by an ellipse and it's angle to the y-axis.
The event is optional and only sent when compositor and the
touch device support this type of information. The client is
responsible for making a reasonable assumption about the
touch shape if no shape is reported.
Signed-off-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Enum entries and message arguments are sometimes preceded by a blank line, but
often aren't.
Standardize the format of the protocol specification by removing blank lines
preceding a list of message arguments and enum entries.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The protocol describes wl_shm as a "global singleton" rather than
"singleton global," which is the order used throughout other protocol
object descriptions.
Re-order the terms for consistency.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
