GitLab

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

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>

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>

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>

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>

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>

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>

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>

Eskil is the team lead for the Qt Oslo Graphics team.

This helps binding generators such as the one in wayland-rs.
Signed-off-by: Ivan Molodetskikh <yalterz@gmail.com>