The idea of a better-defined governance model for wayland-protocols has
been discussed for quite a while [1].
A new GOVERNANCE document describes how changes to the wayland-protocols
repository are accepted. A set of members representing projects can vote
on merge requests sent via GitLab. The initial list of members is
available in the MEMBERS file.
[1]: https://lists.freedesktop.org/archives/wayland-devel/2019-February/040076.html
Signed-off-by: Drew DeVault <sir@cmpwn.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: Johan Helsing <johan.helsing@qt.io>
Acked-by: Roman Gilg <subdiff@gmail.com>
Acked-by: Christopher James Halse Rogers <raof@ubuntu.com>
Acked-by: Alan Griffiths <alan.griffiths@canonical.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Cc: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Cc: Carlos Garnacho <carlosg@gnome.org>
Cc: David Edmundson <david@davidedmundson.co.uk>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Victor Berger <victor.berger@m4x.org>
The output description is a human-readable text describing the output. Unlike
the name which uniquely identifies the output, it's intended to be displayed to
the user.
It might be desirable for a compositor to update an output's description. For
instance, when only one output is plugged in, it's not necessary to dump make,
model, serial and connector to the description, something like "Dell U2717D" is
enough. However when two identical outputs are plugged in it's necessary to add
e.g. the connector type to tell them apart ("Dell U2717D on HDMI"). See [1] for
a discussion about this.
This commit bumps xdg_output's version to allow compositors to update the
property.
[1]: https://github.com/swaywm/wlroots/issues/1623
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
LibreOffice is one big binary with explicit brandings for different
application modules. This is represented in X11 by a different
WM_CLASS setting for a window. The WM_CLASS is changed based on the
loaded document at runtime. As a result LibreOffice already offers
multiple desktop files with different icons, StartupWMClass
entries and application names.
This amendment of the set_app_id request just explicitly specifies
the use case to change a surfaces' app ID at runtime, so a compositor
implementor is made aware of it. Just as the WM_CLASS, a change of
the app ID should result in an update of the propertes of a surface
depending on the app ID, like the window icon specified in the
desktop file or a re-grouping of the surfaces in a task manager.
Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This allows clients to destroy a gesture object before they disconnect.
The request isn't named "destroy", as this would conflict with
wayland-scanner's auto-generated destructor (which just destroys the
client-side object without sending any request).
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This commit makes it so a wl_output.done event is guaranteed to be sent with a
xdg_output.done event.
This protocol change has been discussed in a recent xorg-devel discussions [1].
First let's recap why a change is needed: Xwayland listens to both wl_output and
xdg_output changes. When an output's properties change, Xwayland expects to
receive both a wl_output.done event and an xdg_output.done event. If that's not
the case, Xwayland doesn't update its state (so old state is still exposed to
X11 clients).
Most of the time, both objects will be updated at the same time (e.g. the
current mode is changed, so both wl_output.mode and xdg_output.logical_size are
sent) so this won't be an issue. However in some situations only one of
wl_output or xdg_output changes. For instance:
- The mode is changed at the same time as the scale, resulting in the same
logical_size.
- The compositor doesn't expose the outputs' position via wl_output, so whenever
the position changes only xdg_output is updated.
Both KDE [2] and wlroots [3] have experienced this issue.
For this reason, I'd like to update the xdg-output protocol to make it mandatory
to always send a wl_output.done event after xdg_output changes. This effectively
makes wl_output.done atomically apply all output state (including the state of
add-on objects like xdg_output). This approach is pretty similar to
wl_surface.commit: this request will atomically apply surface state including
the state of e.g. the xdg_surface object tied to the wl_surface.
To update the protocol to reflect this new requirement we can either:
- **Bump xdg_output version**. The current protocol doesn't specify that
wl_output.done must be sent, adding this new requirement would be a breaking
change. We need to fix Xwayland for the current xdg_output version (maybe make
it non-atomic for the current version, atomic for the new one?). Should we
deprecate xdg_output.done in the new version?
- **Don't bump xdg_output version**. This clarifies what is expected in practice
by Xwayland, a major xdg_output consumer, and what is currently implemented by
all compositors.
There's one issue with the "don't bump" approach: indeed in practice compositors
always send wl_output.done and xdg_output.done in pairs, however the ordering
between those two events is not guaranteed. This means some compositors might
send this sequence:
wl_output.geometry(…)
wl_output.done()
xdg_output.logical_position(…)
xdg_output.done()
In this case the wl_output.done event fails to atomically apply the xdg_output
state.
For this reason, I think bumping the version is a better approach.
This commit also deprecates xdg_output.done, which doesn't have any purpose
anymore.
[1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html
[2]: https://phabricator.kde.org/D19253
[3]: https://github.com/swaywm/sway/issues/4064
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
It provides legacy support and makes it easier to replace wl_drm.
v3: DRM_FORMAT_MOD_INVALID must be advertised to be supported (which
requires a version bump)
v4: no version bump, but a note for now
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Clarify that after zwp_buffer_release_v1 events, otherwise unused
buffers can be reused without any additional implicit synchronization.
This is in contrast to wl_buffer.release, which doesn't guarantee that
implicit synchronization is not required to safely use a buffer after
the event is received.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Graphics APIs are expected to use this protocol under the hood, and
since there can only be one user of explicit synchronization per
surface, warn about using the protocol directly in such cases.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add opaque EGL buffers to the supported buffer types for use with the
explicit synchronization protocol. Opaque EGL buffers rely on the same
EGL implementation in both the compositor and clients, which makes it
straightforward to manage client expectations about fence support for
such buffers.
Also make it clearer that implementations are free to support other
buffer types beyond the required ones.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This primary selection is similar in spirit to the eponimous
in X11, allowing a quick "select text + middle click" shortcut
to copying and pasting.
It's otherwise very similar to its Wayland counterpart, and
explicitly made consistent with it.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
This protocol enables explicit synchronization of asynchronous graphics
operations on buffers on a per-commit basis. Support is currently
limited to dmabuf buffers and dma_fence fence FDs.
Explicit synchronization provides a more versatile notification
mechanism for buffer readiness and availability, and can be used to
improve efficiency by integrating with related functionality in display
and graphics APIs.
This protocol is also useful in ChromeOS ARC++ (running Android apps
inside ChromeOS, using Wayland as the communication protocol), where it
can enable integration of the ChromeOS compositor with the explicit
synchronization mechanisms of the Android display subsystem.
Finally, the per-commit nature of the release events provided by this
protocol potentially offers a solution to a deficiency of the
wl_buffer.release event (see
https://gitlab.freedesktop.org/wayland/wayland/issues/46).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
[Pekka: dropped Reveman from maintainers]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Although it would probably default to the license at the root of the
repository anyway, it's best to be explicit about it, and also be
consistent with the other extensions.
The copyright holders have been assembled from git history and the
README.
Signed-off-by: Johan Klokkhammer Helsing <johan.helsing@qt.io>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
The wording in xdg-shell's `set_*` requests implies the compositor
*will* honour the client's request.
This would give clients the control over their actual state, while the
general expectation is that clients kindly ask for state changes which
the compositor may follow.
This patch ensures the actual protocol text reflects these expectations.
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The xdg-shell documentation had part of the maximized state render
implications in the `set_maximized` request documentation, not the
actual state.
This moves the relevant lines into the state description.
Signed-off-by: Markus Ongyerth <wl@ongy.net>
Reviewed-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This new protocol description is an evolution of v2.
- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
Compositors are still free to handle situations where the keyboard
focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
interface instead.
- All state is double-buffered, with specified defaults.
- The compositor can be notified about external changes to the state.
- The client can detect outdated requests.
Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Pass --strict to wayland-scanner in order to make it exit with failure
if something wasn't correct.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
The wayland-scanner sub-commands private-code and public-code replaced
the old code command, so lets use those in the tests instead.
This requires at least wayland-scanner 1.15.0.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This adds a new protocol to negotiate server-side rendering of window
decorations for xdg-toplevels. This allows compositors that want to draw
decorations themselves to send their preference to clients, and clients that
prefer server-side decorations to request them.
This is inspired by a protocol from KDE [1] which has been implemented in
KDE and Sway and was submitted for consideration in 2017 [2]. This patch
provides an updated protocol with those concerns taken into account.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Drew DeVault <sir@cmpwn.com>
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Eike Hein <hein@kde.org>
Reviewed-by: Alan Griffiths <alan.griffiths@canonical.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
[1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
[2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
It seems that this was partially done in
a3cf97ff982638bf7ed23b4303eba280c521b54d; this patch just corrects an
oversight.
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
da33164726 added a compatiblity macro for
old versions of pkg-config. However, the file in which that macro
resides was not included. From the autoconf docs: "Note that if you use
aclocal from Automake to generate aclocal.m4, you must also set
ACLOCAL_AMFLAGS = -I dir in your top-level Makefile.am.".
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This adds two events to the protocol. The goal is to allow clients to
give the user the ability to select outputs with the same names the
compositor uses and to identify outputs consistently across sessions.
The output name is a short and stiff identifier with strict limits on
permitted characters, which is suitable for storing in config files,
command line arguments, etc. A warmer "description" event is also
provided to (optionally) provide a more human readable name, and has
much broader restrictions on its form.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
[Jonas: Fixed formatting and commit subject]
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
this adds implementation from a related discussion long ago in which
it was decided that it would be useful for clients to know if/where their
windows were tiled so that various behaviors and visuals could be modified
to improve UX
a window which is e.g., tiled on the right side of the screen would set the
right|top|bottom tiled states in configure
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
[Jonas: Minor formatting fixes]
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Changes since v2: simplified docs
Changes since v1: added since=2 to enum members
wl_pointer, wl_keyboard and wl_touch events currently use a 32-bit
timestamp with millisecond resolution. In some cases, notably latency
measurements, this resolution is too coarse to be useful.
This protocol provides additional high-resolution timestamps events,
which are emitted before the corresponding input event. Each timestamp
event contains a high-resolution, and ideally higher-accuracy, version
of the 'time' argument of the first subsequent supported input event.
Clients that care about high-resolution timestamps just need to keep
track of the last timestamp event they receive and associate it with the
next supported input event that arrives.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Having a strict requirement on clients obeying the configured window
geometry for fullscreen toplevel surfaces might have the side effect of
making it harder or impossible to implement various hardware
optimizations on certain system configurations. By softening
requirements on the geometry while loosely defining the border fill, we
remove that restriction.
Clients that still want total control of the surrounding area can
still for example prepare the attached buffers to match the configured
surface size, or use subsurfaces in combination with wp_viewporter to
make up a surface matching the fullscreen window geometry dimensions.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Arnaud Vrac <rawoul@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@samsung.com>
The description for xdg_toplevel.unset_fullscreen was completely
missing, so add it.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@samsung.com>
It was not explicitly specified (as it is in set/unset_maximize) that
the compositor will respond with a configure event when a client asks to
be fullscreened, and the meaning of the output parameter was somewhat
awkwardly described.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@samsung.com>
Specify that the maximize/unmaximize state requests only affects the
state a surface will return to if it is currently fullscreen.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@samsung.com>
There is no configure 'request' only configure 'events'.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@samsung.com>
While there is no currently known usages of setting an anchor offset on
the same axis as the 'flip' constraint action is set, it must still be
specified so compositors behave the same.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Bitfields allowed for impossible combinations of anchor edges, such as
being on the left and right edge. Use of explicit enumerations means we
don't need to handle that case.
Signed-off-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
ensure that this is as precise and explicit as possible for all useful
cases and also define previously-unspecified behavior
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Allow using some other protocol (custom, or future xdg_* based) to set
up the parent-child relationship of a popup. This allows future
protocols to use xdg_popup when mapping popups over surfaces not based
on xdg_surface.
An example use case for this is the window menu, where a shells UI
client can use xdg_popup to create popup menus over windows it does not
have a xdg_surface of by having a custom protocol setting up the proper
parent-child relationship.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-By: Mike Blumenkrantz <zmike@osg.samsung.com>
Change the semantics of xdg_toplevel.set_parent to allow chaining
multiple parent-child relationships together, while allowing
arbitrarily unmapping parents, while keeping what is left over of the
chain intact.
This makes things easier to manage when parent-child relationships
cross client borders, for example when using xdg_foreign.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Setting a null-surface as a toplevel parent should unset the
parent-child relationship. This was not specified, so lets do that.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
A client might want to change the window geometry without wanting the
window to be moved, for example when changing the width of the border.
Point out that the compositor should treat the (x,y) coordinate of the
geometry as the top-left corner of the window, and not change the
position of the window as it appears on the screen if the (x,y)
coordinate changes.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-By: Mike Blumenkrantz <zmike@osg.samsung.com>
There is no such thing as 'monitor' in Wayland, only outputs.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-By: Mike Blumenkrantz <zmike@osg.samsung.com>
