| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
