To update your local repository to use the new default branch, these
commands may help:
$ git fetch origin
$ git checkout master
$ git branch -m main
$ git branch --set-upstream-to=origin/main
Signed-off-by: Daniel Stone <daniels@collabora.com>
Time has told us that the effort going from `unstable` to `stable` is
enough of a burdon meaning very few protocols are ever declared stable.
To mitigate this, and thus avoid having protocols being "stuck" being
"unstable" indefinitely, replace the "unstable" -> "stable" procedure
with a "staging" -> "stable" procedure, where declaring a protocol
stable does not involve any changes to any implementations.
The only side effect of this is that version numbers are to forever be
part of all interface names and protocol XML files.
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/30
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
The protocol states that the client must provide xdg_toplevel surfaces,
but doesn't specify protocol error values that can be sent by the
compositor.
Signed-off-by: Simon Ser <contact@emersion.fr>
This is being picky, but "pinch/spread" is the physical gesture, zoom and
rotate is the effect that clients provide in response to that gesture.
Let's use pinch only here since spread is more ambiguous in english, as anyone
who's ever had butter on their bread would know.
Also, everything else is referring to it as pinch anyway, so zoom/rotate here
is the odd one out.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently, the spec doesn't say explicitly that present requests assign
a surface role. Given that, it can be viewed as the protocol modifies
an already assigned surface role, e.g. xdg-toplevel, and present requests
only act as hints.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
This commit makes it clear that compositors can send valid modifiers and
DRM_FORMAT_MOD_INVALID for a given format. This means that the compositor
supports both implicit and explicit modifiers. See the warning further
down:
> Warning: It should be an error if the format/modifier pair was not
> advertised with the modifier event. This is not enforced yet because
> some implementations always accept DRM_FORMAT_MOD_INVALID. Also
> version 2 of this protocol does not have the modifier event.
Xwayland already requires compositors to send DRM_FORMAT_MOD_INVALID
for importing buffers with an implicit modifier [1].
In a future protocol version, it would be nice to make it a protocol
error (or at least a soft failure) to use any format/modifier pair that
wasn't advertised. A use-case for this is Vulkan compositors: the Vulkan
DMA-BUF extensions require an explicit modifier and cannot import
buffers which have an implicit modifier.
[1]: 6c51818a0f/hw/xwayland/xwayland-glamor-gbm.c (L328)
Signed-off-by: Simon Ser <contact@emersion.fr>
ci-fairy doesn't know how to to look at $CI_MERGE_REQUEST_PROJECT_PATH
right now, so if we don't manually set $FDO_UPSTREAM_REPO, ci-fairy will
(without verbose logging turned on) silently fall back on the source
repository project path for finding the branch point. This might fail if
the owner of the source repository hasn't updated the `master` branch of
their fork.
Related: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/32
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
"datadir" is not the same thing in meson and autotools.
In autoconf "datadir" is "${datarootdir}", which expands to
"${prefix}/share". @datarootdir@ expands to "${prefix}/share". There
seems to be no variable that expands to "share".
In meson "datadir" is "share".
So, avoid the "datadir" variable, just expand "datarootdir" it manually
instead. This unbreaks the recently broken autotools setup.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This switches to the ci-templates that is found on
https://gitlab.freedesktop.org/freedesktop/ci-templates/
While at it, switch to Debian bullseye, as this contains more reasonably
versioned build tools, i.e. a new enough version of meson.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This was prompted by the discussion from
https://lists.freedesktop.org/archives/dri-devel/2020-May/266611.html
which is not the final wording.
When a DRM device is hot-unplugged, particularly if it is the Wayland
compositor's compositing GPU, EGL may start returning errors from trying to use
the client's dmabuf. Or, if the client is rendering on another GPU which gets
hot-unplugged, the dmabuf the compositor already has may start failing.
Hot-unplug is an abrupt global action, and there is no way a client or a
compositor could ensure they clean up before things start failing. It is not
the client's fault, so the client should not get disconnected if already
existing wl_buffer objects start failing. This patch add the wording to the
protocol to this effect.
The intention is that the compositor replaces the failed buffers with some
placeholder content. There is no way this could be glitch-free. In its own pace
the client should discover the DRM device is gone, clean up, and perhaps use
something else. How exactly that should happen depends on the rendering API the
client is using.
This is a tiny step towards making DRM device hot-unplug not crash
applications that wish to handle the unplug gracefully.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Currently protocol does not specify what should happen if multiple
text-inputs are created by same client, which is why this is more or
less undefined behavior currently in compositor implementations.
If client has created more than one text-input objects and surface owned
by the client is focused, then compositor must send enter event to all
text-input objects, in case of enable request however only one
text-input must be enabled per client per seat.
Signed-off-by: Bhushan Shah <bshah@kde.org>
Add documented Gitlab procedures to help protocol reviewers and
maintainers to get a better picture of the state of merge requests. To
make this more reliable, document procedures how to triage and manage
merge requests using labels.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
README was distributed by default due to implicit autotools rules, so
when we renamed to README.md, it stopped being included. While at it,
also add the two other new files.
Signed-off-by: Jonas Ådahl <jadahl@gmail.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>
This converts GOVERNANCE, MEMBERS and README to Markdown documents.
These are only cosmetic changes, the actual contents and wording have
been retained.
GitLab pretty-prints Markdown and adds anchors. We can now add links
from one document to another.
Unfortunately GOVERNANCE lettered lists have been converted to numbered
lists, because Markdown doesn't support the former.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/issues/3
510188250e ("Add governance document") adds a GOVERNANCE document
describing development based on GitLab merge requests. Update the README
file accordingly.
Some information is duplicated across README and GOVERNANCE, this is
intentional to make README provide a more human-friendly, less
bureaucratic version. GOVERNANCE is still the authoritative version.
Signed-off-by: Simon Ser <contact@emersion.fr>
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>
