Some tablets provide one or more rotary controls (see e.g. the Huion
Inspiroy Dial 2) that provide delta information effectively equivalent
to a mouse wheel. Expose those in the same way as the strip or ring
controls, with the event matching the wl_pointer.axis_v120 approach.
Like a typical mouse wheel we do not expect there to be a source
information, so this is left out of the interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Just VID/PID is not enough, we need the bustype too. And since we now
have that event remove the mention of USB from zwp_tablet_v2.id.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unfortunately all the objects depend on each other so any change in any
requires bumping all versions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Replace the EGL links and AddFb2 reference with a link to the
kernel docs. The kernel docs explain all the subtleties of dmabuf
exchange, and already link to EGL (and more).
Signed-off-by: Simon Ser <contact@emersion.fr>
When this extension was developed, we did not yet know how VRR hardware
would behave in practice as it was not standardised, and the KMS
interface was equally unstandardised.
Now things have shaken out to an acceptable level, we have a good idea
of what we need, which is simply to include a base refresh rate - the
rate the compositor would drive the display for non-VRR clients.
Bump the protocol to version 2 and require the compositor to provide
a rate.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
It wasn't clear that it's important clients set up their initial
xdg_surface state before they send the initial commit. This is
required for the compositor to be able to send a proper configure
event depending on size constraints and any policies it might want
to apply (e.g. specific app ID always shows up in a designated
workspace).
Signed-off-by: Simon Ser <contact@emersion.fr>
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 extension has not changed in a long time, is
widely supported, and no upcoming breaking changes are planned.
The interface names are left unchanged, so that compositors and
clients don't need to be updated. In particular, the legacy "z"
prefix is still part of the interface name.
Signed-off-by: Simon Ser <contact@emersion.fr>
Port the changes made in 31236887df ("xdg-shell: move maximized
state definition together") to the various tiled states.
Signed-off-by: Simon Ser <contact@emersion.fr>
xdg-shell assumes that the client provides all parts of a toplevel
window, i.e. things like titlebar, drop shadow. There are already things
here and there implies it, but it could be helpful to spell it out.
This doesn't change any semantics - it's still valid, from the
perspective of the protocol, to create a toplevel without any
decorations, and it always has been, it just means that the semantical
intention is for them to be exactly so.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This protocol extension is ubiquitous. It's time to mark it as
stable.
The interface names are left unchanged, so that compositors and
clients don't need to be updated. In particular, the legacy "z"
prefix is still part of the interface name.
Signed-off-by: Simon Ser <contact@emersion.fr>
Clarify how and when initial wl_surface state provided by the core
protocol or by extensions to the wl_surface, like as
wp_fractional_scale_v1, is being delivered.
The motivation for such change is to make it clear that the first frame
for xdg-shell will be perfect, which implies that scaling and similar
properties affecting presentation would be delivered in time.
Signed-off-by: Kirill Chibisov <contact@kchibisov.com>
Add a toplevel state to indicate that surface repaints have been
suspended. This may arise due to occlusion, output power state, etc.
In this state, clients can choose to take meaningful action such as
suspending any processing which would drive a repaint loop, or
communicating to the active browser tab that the tab is not
system-visible, or any other action that would be taken by a client not
expecting to repaint until further notice.
cf. discussion in wayland/wayland-protocols!99
Signed-off-by: Daniel Stone <daniels@collabora.com>
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>
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
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
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>
The protocol states that the edges parameter of the resize request must
be one of the values of the resize_edge enum but does not provide a
protocol error value to handle the case where it is not. This commit
adds that error value.
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
This aims to communicate the maximum size a surface should be created
with, and loosely corresponds to the concept of "work area" in the X11
world.
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/17
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
On Genode, graphics drivers run in user space. It is also theoretically
possible for a Wayland compositor to run in kernel space. Therefore,
the phrase “user space” should be avoided in a Wayland protocol
specification.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Instead of describing each enum entry in the enum description,
use enum entry descriptions. This avoids the awkward list of
flags in the top-level description.
This has been possible for a long time, but wasn't correctly
handled by wayland-scanner until recently [1].
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/151
Signed-off-by: Simon Ser <contact@emersion.fr>
It is illegal for a surface to have more than one role. The only thing
which can be done with an xdg_surface (apart from destroying it) is to
assign the surface a role with the get_toplevel, get_popup, etc
requests.
On Mutter, calling get_xdg_surface on a surface which already has an
assigned role generates the 'role' protocol error. Weston will not send
an error, however it may later abort on a failed assert during cleanup.
wlroots allows this case, and only sends the role error when assigning
an explicit role through creating a toplevel or popup.
On the grounds that it makes no sense to create an xdg_surface for a
wl_surface which already has a role, make it explicitly illegal.
cf. wayland/weston!559, wayland/weston!627
Signed-off-by: Daniel Stone <daniels@collabora.com>
This commit adds protocol additions making it possible to request that a
popup should be repositioned according to a new xdg_positioner object.
Explicit popup moving is done using a new request on xdg_popup:
xdg_popup.reposition. What it does is change the parameters used for
positioning a popup by providing a new xdg_positioner object. This
request is coupled with a new event; xdg_popup.repositioned, sent
together with the configure events (xdg_popup.configure and
xdg_surface.configure) to notify about the completion of the reposition
request. The reposition request also takes a token that is later passed
via the repositioned event; this is done so that a client may determine
for which reposition request the compositor has sent configure events.
Synchronization between surfaces to avoid state application race
condition are deliberately left out, and should be handled by an
external protocol.
To brief the compositor of the future dimension of the parent that the
compositor should position the popup against, a
xdg_positioner.set_parent_size request is added.
Lastly, a request to couple a xdg_positioner object with a parent
configure event is added (xdg_positioner.set_parent_configure) in
order for a compositor to pair a popup reposition request with a pending
configure event, and it's resulting window geometry. This is necessary
to, for example, properly constrain a popup given a future parent state.
An example of when this may be necessary is an interactive resize where
both the toplevel position and the relative popup position changes.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This commit adds protocol additions making it possible to implicitly
reposition an already mapped popup if the conditions for the constraint
changed (e.g. toplevel moved).
Implicit popup moving is done by setting a adjustment flag on the
positioner used to create it that will cause the compositor to adjust
the position as the conditions used to constrain it change.
These changes may include, for example, changes in the position of the
parent window or the geometry of the work area. To allow the client to
update its content in response to the updated position, the client must
ack the configure event, optionally with new content. Until the client
acks this configure event, the existing positioner will continue to be
used.
Implicit repositioning by itself is racy regarding inter-surface
synchronization of applied state. Inter-surface synchronization is
deliberately left out of xdg-shell, and left to be handled externally.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
It mentioned the now removed x, y parameters of xdg_surface.get_popup.
The xdg_positioner now has the relevant documentation that was
previously documented by the now removed paragraph.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
