Commit 96bdc156 added a check for <sys/eventfd.h> to enable DRI3.
DragonFly and OpenBSD however rely on epoll-shim for <sys/eventfd.h>,
so that must be added as a dependency for the <sys/eventfd.h> check.
Fixes: commit 96bdc156 - xwayland: Do not enable DRI3 without eventfd
Suggested-by: Jan Beich <jbeich@freebsd.org>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 8fe15a60c5)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
DragonFly and OpenBSD rely on epoll-shim to provide eventfd.
Move the check for epoll dependency to the root meson.build script so
that we can use that for the <sys/evenfd.h> check as well.
This is preparation work for the following commits, no functional change
intended at this point.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 673b56e61c)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1702>
DRI3 version 1.4 which supports explicit buffers synchronization relies
on the eventfd interface.
As result, building would fail with DRI3 enabled on platforms without
the eventfd interface.
Check for the availability of the sys/eventfd.h header and disable DRI3
support if missing.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 96bdc156a1)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
This protocol allows for explicit synchronization of GPU operations by
Wayland clients and the compositor. Xwayland can make use of this to
ensure any rendering it initiates has completed before the target image
is accessed by the compositor, without having to rely on kernel-level
implicit synchronization.
Furthermore, for X11 clients that also support explicit synchronization
using the mechanisms exposed in the DRI3 and Present extensions, this
Wayland protocol allows us to simply forward the timeline, acquire, and
release points directly to the compositor, ideally avoiding any
premature stalls in the presentation pipeline.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
Together, DRI3 1.4 and Present 1.4 allow clients to explicitly
synchronize GPU rendering with presentation using DRM syncobjs. Here we
add the necessary support to Xwayland's glamor and Present
infrastructure to enable this functionality.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
Adds the required infrastructure in the core DRI3 code to support
importing DRM synchronization objects from clients. This includes
support for the two new protocol requests from DRI3 version 1.4, an
internal representation of these objects in the form of the dri3_syncobj
structure, and an import_syncobj screen info callback.
The following operations are defined for dri3_syncobj objects
* free - release any server-side resources associated with the object
* has_fence - check if the fence for a timeline point is submitted
* is_signaled - check if a timeline point is signaled
* export_fence - return a sync fd corresponding to a timeline point
* import_fence - submit a sync fd as the fence for a timeline point
* signal - immediately signal a timeline point
* submitted_eventfd and signaled_eventfd - register an eventfd to be
signaled when the given timeline point is either submitted or
signaled
Implementations will be responsible for populating these function
pointers when importing a syncobj.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
DRI3 version 1.3 introduced a new request which allows clients to
provide a hint to the server about which DRM device they are using, so
that the server might return DRM format modifiers specific to that
device. However, implementing such functionality, for Xwayland in
particular, will require fairly significant architectural changes.
To avoid blocking future versions of the DRI3 extension, we provide here
a stub implementation for the request in question. The spec explicitly
states that it is only a hint that the server is free to ignore, so
strictly speaking this implementation is still correct.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
When X11 isn't installed directly at /usr hierarchy (eg. NetBSD uses
/usr/X11R7/), build breaks:
../test/list.c:31:10: fatal error: X11/Xlib.h: No such file or directory
31 | #include <X11/Xlib.h>
| ^~~~~~~~~~~~
Needs explicitly dependency on libX11, so the include path is added.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1442>
This is needed to support the "wp-fractional-scale-v1" protocol.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-By: Kenny Levinsen <kl@kl.wtf>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197>
Now that the NVIDIA proprietary driver has grown support for GBM, the
EGLStream backend for NVIDIA GPUs is now superseded by the standard
GBM backend in Xwayland.
This code path is therefore not used and hardly ever tested.
Remove support for EGLStream in Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
This header is never exported and belongs to OS layer, thus no need to have it
in include/ directory, where all the public ones are - better off under os/.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1350>
* this symbol is a server configuration flag (can be passed via cmdline)
for limiting the max size of big-requests. there shouldn't be any need
to use it outside the core X server (in server modules like drivers
or external extension) - therefore unexport it
* in order to reduce namespace pollution of public (server module API)
headers, create a new internal header for those tings (more to come)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1275>
Without this, systemd will be used if installed on the system automagically,
which is a problem if the built e.g. Xwayland is going to be used on a non-systemd
machine.
Bug: https://bugs.gentoo.org/908254
Signed-off-by: Sam James <sam@gentoo.org>
This allows applications to respond to changes of power level
of a monitor, e.g. an application may stop rendering and related
calculations when the monitor is off.
Related bug: https://bugs.freedesktop.org/57120
Signed-off-by: Alexander Volkov <avolkov@astralinux.ru>
Most X servers, even those which do not have specific configuration
files, can use the directory specified by SERVER_MISC_CONFIG_PATH when
they have either the XSECURITY or XSELINUX extensions enabled, or when
support for DTRACE is enabled at build time, because this is also where
the "protocol.txt" file is searched for at runtime.
Unfortunately, the SERVER_MISC_CONFIG_PATH is set from serverconfigdir
which is hardcoded in the build system to "$prefix/$libdir/xorg", and
all X server builds share the same path.
That makes it harder for different X servers such as Xwayland to install
in the same path without sharing the same server configuration path
(and hence the same "protocol.txt" file).
Allow for the customization of server configuration path from the build
options so that different X servers can use completely different and
independent paths.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is more portable than libbsd as everything Just Works, even on BSD systems,
and is the recommended method of consuming libbsd nowadays.
It also helpfully lets things work with glibc-provided functions for new
enough glibc.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/973
Co-authored-by: Guillem Jover <guillem@hadrons.org>
Signed-off-by: Sam James <sam@gentoo.org>
This adds support for XTEST in Xwayland using EIS, the emulated input
library [1].
To differentiate between X11 clients using XTEST, initiate a EI context
for each client and use the actual client name, from its command
line.
When an X11 client first tries to use XTEST to generate emulated input
events, a new connection to libEI is initiated by Xwayland on behalf
of the X11 client.
During that connection phase, the EI server will not be accepting
events until the emulated device is actually created, meaning that any
XTEST request from the X11 client will be discarded until the EI server
is willing to accept events.
To avoid that issue, add an event queue in Xwayland per X11 client that
will keep those requests, and dequeue them as soon as the EI server is
ready, i.e. once the EI device is added.
If the X11 client disconnects from the Xserver before the EI server is
ready, or if the connection is closed by the EI server, those events are
discarded and the queue cleared from any pending events.
For 10 minutes after the client disconnects, keep the internal struct
alive. If a client with the same commandline arguments connects again,
re-use the same struct. This means we are faster with the events the
second time around but it also allows the EIS server to pause individual
clients that keep sending intermittent events and disconnect immediately
(e.g. it'd be possible to pause xdtotool while an authentication prompt
is active).
[1] https://gitlab.freedesktop.org/libinput/libei
Thanks to Jan Beich <jbeich@FreeBSD.org> for fixing the build on BSD.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Co-authored-by: Olivier Fourdan <ofourdan@redhat.com>
Co-authored-by: David Redondo <kde@david-redondo.de>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This is needed for tearing-updates-v1
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
With Wayland 1.21 being our baseline, we do not need to compile
wl_pointer.axis_v120 conditionally.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
