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