| Age | Commit message (Collapse) | Author |
|---|
|
This is based on the Chromium protocol [1].
[1]: https://chromium.googlesource.com/chromium/src/+/main/third_party/wayland-protocols/unstable/cursor-shapes/cursor-shapes-unstable-v1.xml
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/58
References: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/21
|
|
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
This protocols allows for communicating preferred fractional scales to
surfaces, which in combination with wp_viewport can be used to render
surfaces at fractional scales when applicable.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
For some use cases like games or drawing tablets it can make sense to reduce
latency by accepting tearing with the use of asynchronous page flips. This
protocol provides a way for clients to indicate whether or not their content
is suitable for this kind of presentation.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
This protocol adds a xwayland_surface role which allows an Xwayland
server to associate an X11 window to a wl_surface.
Before this protocol, this would be done via the Xwayland server
providing the wl_surface's resource id via the WL_SURFACE_ID atom on the
X window. This was problematic as a race could occur if the wl_surface
associated with a WL_SURFACE_ID for a window was destroyed before the
update of the atom was processed by the compositor and another surface
(or other object) had taken its id due to recycling.
This protocol solves the problem by moving the X11 window to wl_surface
association step to the Wayland side, which means that the association
cannot happen out-of-sync with the resource lifetime of the wl_surface.
This protocol avoids duplicating the race on the other side by adding a
non-zero monotonic serial number which is entirely unique that is set on
both the wl_surface (via. xwayland_surface_v1's associate method) and
the X11 window (via. the `WL_SURFACE_SERIAL` atom) that can be used to
associate them, and synchronize the two timelines.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
This helps with merge conflicts when a protocol is merged. This is
also more consistent with the other protocol lists above.
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
This protocol lets clients advertise which kind of content they expect
to be displayed on a given surface, so that the compositor can make more
informed decisions about its behavior and output configuration.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
|
|
This patch adds a new ext-idle-notify protocol. It allows clients to be
notified when the user is idle. Use-cases include e.g. power management
daemons.
This protocol is based on the org_kde_kwin_idle interface already being
used by KDE and wlroots compositors. The protocol has been sent to
wayland-protocols in 2015 [1]. This version renames and clarifies the
interfaces, and addresses the review comments.
[1]: https://lists.freedesktop.org/archives/wayland-devel/2015-December/026045.html
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/8
Reviewed-by: David Edmundson <davidedmundson@kde.org>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
This protocol allows creating single-pixel buffers. It can be useful
to avoid having to allocate a real buffer just to fill it with the
same pixel value. Some use-cases include drawing background surfaces
or toplevel decorations.
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
Fixes the following warning:
NOTICE: Future-deprecated features used:
* 0.55.0: {'ExternalProgram.path'}
* 0.56.0: {'dependency.get_pkgconfig_variable'}
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
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: Jonas Ådahl <jadahl@gmail.com>
|
|
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>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
This allows clients and compositors to easily use wayland-protocols
as a Meson subproject.
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>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
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>
|
|
"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>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
|
