Instead of writing the link in brackets use the rst link functionality.

Signed-off-by: Roman Gilg <subdiff@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]: wayland/wayland!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. weston!559, weston!627

Signed-off-by: Daniel Stone <daniels@collabora.com>

Make it clearer what the requests are used for.

Signed-off-by: Simon Ser <contact@emersion.fr>

We haven't mentionned the DCO anywhere, yet we were requiring all
contributions to have a Signed-off-by line to accept it.

Add a reference to the DCO in our README's "development procedure"
section.

Signed-off-by: Simon Ser <contact@emersion.fr>

Unused arguments warnings are treated as errors in those tests
otherwise.

Fixes: #53.

Signed-off-by: Xavier Claessens <xavier.claessens@collabora.com>

Manuel Stoeckl authored 3 years ago and Simon Ser committed 3 years ago

Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Reviewed-by: Simon Ser <contact@emersion.fr>

Vlad Zahorodnii authored 3 years ago and Simon Ser committed 3 years ago

The spec uses the terms "presentation token" and "activation token"
interchangeably, which can cause confusion.

Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>

Stop hardcoding the Python path to /usr/bin/python3. Not all systems
have Python installed to /usr/bin, and some users might have installed
Python to a custom location.

Instead, use /usr/bin/env, which performs a $PATH lookup to find the
Python executable.

Signed-off-by: Issam E. Maghni <issam.e.maghni@mailbox.org>

Add GitLab usernames for all members, so that they can easily be
mentionned in merge requests or issues.

The only missing username is for Alan Griffiths, I don't think they
have a GitLab account at the moment.

Signed-off-by: Simon Ser <contact@emersion.fr>

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>

This makes it possible to use both autotools and meson to build and
install the tarball.

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>

Carlos Garnacho authored 4 years ago and Aleix Pol committed 3 years ago

X11 had its own startup notification protocol, describe how could Wayland
compositors implement interoperation between Wayland and X11 clients,
should this be desired.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>

Signed-off-by: Aleix Pol Gonzalez <aleixpol@kde.org>
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>

Jonas Ådahl authored 4 years ago and Simon Ser committed 3 years ago

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: #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>

Vlad Zahorodnii authored 4 years ago and Simon Ser committed 3 years ago

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]: https://gitlab.freedesktop.org/xorg/xserver/-/blob/6c51818a0f55282cbe5a870f58ca82ca45ee472d/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: freedesktop/ci-templates#32



Signed-off-by: Jonas Ådahl <jadahl@gmail.com>

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>

Apart from the autotools build system, also test the meson build system.

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>

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>

Only tested by the meson build system.

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>

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>

Signed-off-by: onox <denkpadje@gmail.com>

Signed-off-by: onox <denkpadje@gmail.com>

Signed-off-by: onox <denkpadje@gmail.com>

Signed-off-by: onox <denkpadje@gmail.com>

Signed-off-by: onox <denkpadje@gmail.com>

Bhushan Shah authored 4 years ago and Bhushan Shah committed 4 years ago

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>

Jonas Ådahl authored 4 years ago and Simon Ser committed 4 years ago

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>

Since the abbreviation "XDG" starts with a vowel sound, the correct
article is "an."

Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>

This wasn't explicit reading the mapping requirements.

Signed-off-by: Simon Ser <contact@emersion.fr>

Signed-off-by: Simon Ser <contact@emersion.fr>

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>