| Age | Commit message (Collapse) | Author |
|---|
|
This protocol allows for a privileged Wayland client to lock the
session and display arbitrary graphics while the session is locked.
The client is responsible for performing authentication and informing
the compositor when the session should be unlocked. If the client
dies while the session is locked the session remains locked, possibly
permanently depending on compositor policy.
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
|
|
Signed-off-by: Max Ihlenfeldt <mihlenfeldt@igalia.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Now that compositors must send INVALID to advertise support for
implicit modifiers, we can make it a protocol error to add a
DMA-BUF plane with an unsupported format + modifier pair.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
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: https://gitlab.freedesktop.org/wayland/wayland/issues/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]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/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>
|
|
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>
|
|
The rest of the file uses tabs, not spaces.
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
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>
|
|
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]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/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. wayland/weston!559, wayland/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>
|
|
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: 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]: 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: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/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>
|
