On multi-GPU setups, multiple devices can be used for rendering. Clients
need feedback about the device in use by the compositor. For instance,
if they render on another GPU, then they need to make sure the memory is
accessible between devices and that their buffers are not placed in
hidden memory.

This commit introduces a new wp_linux_dmabuf_feedback object. This
object advertises a preferred main device, a set of preferred
formats/modifiers and target devices.

Each object is bound to a wl_surface and can dynamically update its
feedback parameters. This enables fine-grained per-surface
optimizations. For instance, when a surface is scanned out on a GPU the
compositor isn't compositing with, the target device can be set to this
GPU to avoid unnecessary roundtrips.

A feedback object can also be standalone for clients that don't support
per-surface feedback.

Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Closes: wayland#59

No change in behavior, just a doc fix.

Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

Add a note about pre-multiplied alpha for all DRM formats.
Include an escape hatch in the spec to allow other protocol
extensions to override this.

Essentially the same as [1].

[1]: wayland!187



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

It's been a few releases that we ship Meson support, we should be
able to drop the old autotools build system now.

Signed-off-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>

When linking for macOS, this linker flag is rejected. Instead of
always passing it, we can check whether it is supported first.

Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
Reviewed-by: Simon Ser <contact@emersion.fr>

I am trying to cross-compile from macOS for FreeBSD and this is currently
failing since the tests attempt to build a native binary that links
against the wayland-client and wayland-server libraries for the FreeBSD
system. I believe we should be building them for the target system and
not the current host (especially since there is no way to build
wayland-client and wayland-server for macOS, but I do want to check that
the files build correctly for FreeBSD).

Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
Reviewed-by: Simon Ser <contact@emersion.fr>

wayland-scanner is only needed for tests so don't require it if tests
are disabled

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

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

Peter Hutterer authored 3 years ago and Simon Ser committed 3 years ago

Hold gestures merely denote "there are fingers on the touchpad but they are
not moving". As touchpad touches are generally fully abstracted, a client
cannot currently know when a user is interacting with the touchpad without
moving - no motion events will be sent in this case.

The two use-cases here are:
- hold-to-interact: where a hold gesture is active for some time
  a menu could pop up, or some object is selected, etc.
- hold-to-cancel: where e.g. kinetic scrolling is currently active, the start
  of a hold gesture can be used to stop the scroll

Since hold gestures by definition do not have movement, there is no need for
an "update" stage in the gesture.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: David Edmundson <davidedmundson@kde.org>
Signed-off by: Eike Hein <hein@kde.org>

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

We use the no-op executables in test() directives, so these will be
run on the host. This fixes the following warning:

    tests/meson.build:23: WARNING: add_languages is missing native:, assuming
    languages are wanted for both host and build.

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

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

The rest of the file uses tabs, not spaces.

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

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

This allows clients and compositors to easily use wayland-protocols
as a Meson subproject.

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

When we're building C++ test executables, make sure we pull in the
correct libwayland headers, to avoid trying to compile against a version
different from the scanner we built it against.

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

The newlines prevent the labels from being properly formatted.
Additionally, the second label reference has a typo (extra "s").

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

Xaver Hugl authored 3 years ago and Simon Ser committed 3 years ago

DRM leasing is a feature which allows the DRM master to "lease" a subset
of its DRM resources to another DRM master via drmModeCreateLease, which
returns a file descriptor for the new DRM master. We use this protocol
to negotiate the terms of the lease and transfer this file descriptor to
clients.

In less DRM-specific terms: this protocol allows Wayland compositors to
give over their GPU resources (like displays) to a Wayland client to
exclusively control.

The primary use-case for this is Virtual Reality headsets, which via the
non-desktop DRM property are generally not used as desktop displays by
Wayland compositors, and for latency reasons (among others) are most
useful to games et al if they have direct control over the DRM resources
associated with it. Basically, these are peripherals which are of no use
to the compositor and may be of use to a client, but since they are tied
up in DRM we need to use DRM leasing to get them into client's hands.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Drew DeVault <sir@cmpwn.com>
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>

After a requesting client receives a new token, the client usually forwards the
token string to another client by a different process, which then uses the
token in an activate request. For that the token string must be transferred to
the other process.

Two default ways of doing that were described in the done event, but the
description had some issues and it makes more sense to describe them in the
protocol description itself, which talks about the protocol in a more general
way. Therefore rewrite the paragraphs about token forwarding between clients
and place them in the protocol description.

Signed-off-by: Roman Gilg <subdiff@gmail.com>

The Wayland client requests surface activation directly using the token
that it received from the X11 client.

Signed-off-by: Roman Gilg <subdiff@gmail.com>

rst requires two backticks to format text as inline code.

Signed-off-by: Roman Gilg <subdiff@gmail.com>

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!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>