The wl_output events should not be used anymore for guessing the
preferred scale and transform of a surface. We have explicit events
for that now.
Signed-off-by: Simon Ser <contact@emersion.fr>
Allows clients to cleanly release wl_shm objects. Useful for clients
using multiple wl_registry objects (e.g. via libraries).
Signed-off-by: Simon Ser <contact@emersion.fr>
Since the positivity of zero is debatable, and, in some cases scale was simply
underspecified, clarify the situation.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
The spec does not describe which actions cause the compositor to assign
keyboard focus to a surface, leaving this up to the compositor.
Compositors differ in their behavior when the user clicks on a
sub-surface. Some will move the keyboard focus to the subsurface whereas
others will only ever assign the keyboard focus to toplevel surfaces.
Some applications (e.g. firefox) seem to require the second behavior.
This patch specifies that sub-surfaces never get the keyboard focus.
Signed-off-by: Julian Orth <ju.orth@gmail.com>
Don't mention when the parent surface state is applied; the parent
surface isn't necessarily a sub-surface.
Signed-off-by: Kirill Primak <vyivel@eclair.cafe>
This should be sufficient for clients to not decide to fallback to
output based logic to determine scaling/transform when compositor
doesn't send any of the v6 events.
Signed-off-by: Kirill Chibisov <contact@kchibisov.com>
The offset in wl_surface.attach has been superseded by
wl_surface.offset. Refer to the new request instead of using the
deprecated one.
Signed-off-by: Simon Ser <contact@emersion.fr>
There are two ways to do pre-multiplication of the alpha channel into
the color channels: on optical values or on electrical values. While
pre-multiplication with optical values is arguably more correct, because
operations like blending or scaling require pre-multiplied, optical
color channels, wayland and compositors by default work with
pre-multiplied electrical values. This is most likely a convention that
Wayland took from Cairo.
This commit makes sure that the expectation of pre-multiplied electrical
values is properly documented.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
The compositor must not send any key events while a surface is not focused,
but in order to allow for common actions like ctrl+scroll for zooming to work
with unfocused surfaces it may do so with modifiers.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
As pointed out in [1], re-using a wl_data_source for multiple start_drag or
set_selection requests has bad consequences, because this object has events
that allo tracking the state of a selection/drag-and-drop operation. Tracking
two operations at the same time isn't possible with this interface.
[1]: https://lists.freedesktop.org/archives/wayland-devel/2019-January/039936.html
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Input region is ignored for cursors, DnD icons. Current wording
implies that this state is temporary, but surfaces never lose the
role once assigned, so reword to make it clearer.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Most compositors send the wl_data_offer.source_actions event before the
wl_data_device.enter event, i.e. after creation of the data offer. This
contradicts to the wayland spec.
On the other hand, it's reasonable to send all the information useful to
the client before the enter event, rather than send mime types before the
enter event and source actions (that don't depend on drop target) after
the enter event.
On the client side, toolkits such as Qt and GTK already expect to see the
source actions before receiving the enter event.
Given all of that, this change adjusts the spec to match the behavior
observed in the compositors in the wild.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Attaching a buffer with interface version 5 requires clients to pass
zero to x and y but it still affects the pending surface state.
Attaching a buffer after a request to offset therefore sets the pending
x and y to zero. The intent of version 5 was to allow exactly this
sequence of requests to work so let's just make sure the protocol
actually spells it out.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
This event adds the physical direction of the axis motion, relative to the
axis event we get. Right now, when natural scrolling is enabled things like
virtual volume sliders move the wrong way round.
By adding the axis motion direction, we can have toolkits swap the scroll
direction for applicable widgets, getting the right behavior on all widgets.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Same as the new wl_surface.preferred_buffer_scale event but for
transform.
No version bump needed since the previous commit did that.
Signed-off-by: Simon Ser <contact@emersion.fr>
Right now, clients need to bind to wl_output globals, listen to wl_output.scale,
listen to wl_surface.enter/leave, pick the highest scale factor.
This is an issue because it breaks Wayland's "policy, not mechanism" motto.
Clients take the decision of which scale to use depending on the outputs they're
on, compositors have no say in this (apart from faking output events, which
isn't great).
This commit introduces a new wl_surface.preferred_buffer_scale event to allow
compositors to directly indicate the preferred scale factor for each surface.
This unlocks features which require dynamically changing the scale such as:
- Accessibility features such as screen magnifier
- In a VR environment, render surfaces close to the eye at a higher scale
- HiDPI screenshots on LoDPI screens
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/271
Role assigned to wl_surface cannot be removed.
Delete contradicting text from wl_subsurface::destroy documentation.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
This commit adds wl_surface.defunct_role_object error, which has
semantics similar to xdg_wm_base.defunct_surfaces error, and is sent
when a client destroys a surface while the corresponding role object
still exists.
Signed-off-by: Kirill Primak <vyivel@eclair.cafe>
This statement assumes that a wl_surface can be destroyed before the
corresponding wl_subsurface, which is not true, as wl_surface
description explicitly states that the role object must be destroyed
before the wl_surface itself.
Signed-off-by: Kirill Primak <vyivel@eclair.cafe>
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 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
