For the Wayland compositors who do not implement XkbBellNotifyMask but
support the Wayland protocol xdg-system-bell, use that to ring the
bell.
v2: Be more selective on the device, make sure it's a keyboard and it
has core events.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1742>
Remove the previous change which ensured that the xwayland pkgconfig
file was installed into $libdir. This is a breaking change for build
systems searching for the xwayland pkg-config file. The sharedir
location fits xwayland better since the pkg-config file does not contain
linking information, it only contains the data on how to locate the
xwayland binary and which features are enabled.
Signed-off-by: Rouven Czerwinski <rouven@czerwinskis.de>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1543>
Before this change, the xwayland pkgconfig file will always contain an
includedir directive, even though xwayland is not a linkable shared
library:
prefix=/nix/store/3spcjqp5zcyg8arz6dnsj59fal5yk3jy-xwayland-23.2.6
includedir=${prefix}/include
exec_prefix=${prefix}
xwayland=/nix/store/3spcjqp5zcyg8arz6dnsj59fal5yk3jy-xwayland-23.2.6/bin/Xwayland
[…]
Cflags: -I${includedir}
According to a bug reporter this trips up cmake [1], which expects that
the include directory exists, which it does not since xwayland does not
install any header files.
Add the dataonly directive to pkgsconfig.generate() which will remove
the default "." subdir and ensures that includedir is not set inside the
pkgconfig file. Additionally enforce the install directory to
$libdir/pkgconfig, since it otherwise will be installed to
$datadir/pkgconfig, which precludes programs from finding the pkgconfig
because share/pkgconfig is usually not included in the search path.
The resulting pkgconfig does not contain an includedir:
prefix=/nix/store/p7xhdzl65hfhzf36vxykzp2i9cyy7y6c-xwayland-23.2.6
exec_prefix=${prefix}
xwayland=/nix/store/p7xhdzl65hfhzf36vxykzp2i9cyy7y6c-xwayland-23.2.6/bin/Xwayland
have_glamor=true
have_eglstream=true
have_initfd=true
have_listenfd=true
have_verbose=true
have_terminate_delay=true
have_no_touch_pointer_emulation=true
have_force_xrandr_emulation=true
have_geometry=true
have_fullscreen=true
have_host_grab=true
have_decorate=false
have_enable_ei_portal=true
have_byteswappedclients=true
Name: Xwayland
Description: X Server for Wayland
Version: 23.2.6
[1]: https://github.com/NixOS/nixpkgs/pull/309075#issuecomment-2108381428
Signed-off-by: Rouven Czerwinski <rouven@czerwinskis.de>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1543>
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>
Recompute and update the global screen scale based on the different
outputs the root window is placed on.
For backward compatibility, this functionality is however disabled by
default and can be enabled using a new command line option "-hidpi".
That option has no effect if Xwayland is running rootless.
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>
That will be used between the generic Xwayland GLAMOR functions and the
GBM implementation.
Move the definition of xwl_glamor_init_gbm() to that new header rather
than in the generic Xwayland GLAMOR header.
This is preparation work to eventually replace the xwl_egl_backend now
that we have only one backend left.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
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>
The dmabuf support code is scattered across different source files,
making it hard to follow and bloating unrelated sources.
Move the dmabuf related source code to its own source files.
This is just a cleanup aimed at helping with code readability, no
functional change intended.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1111>
glamor needs to be disabled if neither gbm nor eglstream is available,
otherwise build breaks.
Closes: xorg/xserver#1631
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This allows e.g.
xfwm4 --vblank=xpresent
to hit the page flip path instead of copies.
In the future, Mesa might also use the Present extension with software
rendering.
This code is almost entirely ddx-agnostic already, and I'd like to use
it from the other EGL glamor consumers. Which, right now that's just
Xorg, but soon it'll be Xephyr too.
With EI support wired to XTEST, and oeffis being enabled unconditionally
means that Xwayland will always go through the XDG portal for XTEST when
supported.
While this the intended behavior for the general use case of Xwayland
running rootless on a desktop compositor, that breaks when Xwayland is
running on a nested compositor, because the portal is for the entire
session and not limited to the nested Wayland compositor.
Xwayland itself, as a regular Wayland client, has no way to tell that it
is running on a nested compositor.
So to keep backward compatibility with existing (and also common) use
cases such as nested compositors, best is to disable support for the XDG
portal by default, and add a new command line option "-enable-ei-portal"
for the Wayland compositors (who spawn Xwayland rootless) to explicitly
enable support for the input emulation XDG portal in Xwayland.
A Wayland compositor running nested should not use that command line
option with Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Fixes: a1333342 - xwayland: Add XTEST support using EIS
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1586
See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/3047
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>
The present code in Xwayland cannot be used without GBM, so if GBM is
not available (or too old), the build would fail.
Make sure we do not use the present code without GBM support.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This allows developers to setup Xwayland as a subproject of a
Wayland compositor, and have it correctly pick up the features
advertised in the dependency variables.
Signed-off-by: Simon Ser <contact@emersion.fr>
Remove the xwayland.pc.in file:
- This avoids writing down each pkg-config variable twice: once in
the Meson files to set the configuration data, once in the .pc.in
file to print it.
- We'll be able to re-use the same variables for use as a
subproject.
Signed-off-by: Simon Ser <contact@emersion.fr>
Implements the xwayland_shell protocol which makes the surface
association happen via a shared serial, rather than sharing a wl_surface
resource ID across an X atom.
This solves a race that can happen 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.
Closes: #1157
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
hw/xwayland/xwayland.c:306:10: fatal error: 'X11/extensions/xwaylandproto.h' file not found
#include <X11/extensions/xwaylandproto.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 2700bc6045 ("xwayland: add support for the XWAYLAND extension")
When running rootful, the Xwayland window is not decorated (as all
Wayland surfaces), which makes it quite inconvenient to move on screen.
libdecor is "a client-side decorations library for Wayland clients"
which can be used precisely for adding decorations to Wayland surfaces.
Add optional support for libdecor in Xwayland to gain decorations when
running rootful and a new command line option "-decorate".
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1332
The app_id is used to identify applications (and group windows), some
desktops (such as GNOME Shell) use it in their top bar.
Set the XDG toplevel "app_id" to "org.freedesktop.Xwayland" and install
a desktop file for Xwayland rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Add a new command line option "-host-grab" to disable the keyboard
shortcuts and confine the pointer on the host so that Xwayland can
receive all keyboard events.
This is useful when running a complete desktop environment within
Xwayland rootful.
Use [CTRL]+[SHIFT] to release the keyboard and pointer.
This option is not compatible with rootless mode.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This commit allows X11 clients running through Xwayland to lease
non-desktop connectors from the Wayland compositor by implementing
support for drm-lease-v1.
In order to not deadlock with the Wayland compositor if its response
to a lease request is delayed, the new interface in _rrScrPriv
introduced in the last commit is used, which makes it possible to
block the X11 client while a response is pending.
Leasing normal outputs is not yet supported, all connectors offered
for lease will be advertised as non-desktop.
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
The implementation is relatively straightforward because both wayland
and Xorg use libinput semantics for touchpad gestures.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
When using autoconf/automake to build Xwayland, the actual path to
Xwayland is not fully qualified and refers to the "exec_prefix".
As a result, the path provided by the generated pkg-config file is wrong
when using autoconf to build the Xserver.
Fix the xwayland.pc file to also set the variable "prefix" and
"exec_prefix" so that the path to Xwayland is fully resolved.
Add those variables to the meson build as well for good measure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Not all extensions can be enabled or disabled at runtime, list the
extensions which can from the help message rather than on error only.
v2:
* Print the header message in the ListStaticExtensions() (Peter
Hutterer)
* Do not export ListStaticExtensions() as Xserver API
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
It runs XTS via piglit on (non-rootless) Xwayland on weston using the
headless backend.
Xwayland might use glamor if enabled in the build, but we're making sure
it uses software rendering.
v2:
* Use weston-info to wait for weston to be ready, instead of just a
fixed sleep. (Martin Peres)
v3:
* Build wayland 1.18 & weston 9.0 locally, since the packages in Debian
buster are too old for current Xwayland.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Xwayland is usually spawned by the Wayland compositor which sets the
command line options.
If a command line option is not supported, Xwayland will fail to start.
That somehow makes the Xwayland command line option sort of ABI, the
Wayland compositor need to know if a particular option is supported by
Xwayland at build time.
Also, currently, Xwayland is being installed along with the rest of the
common executable programs that users may run, which is sub-optimal
because, well, Xwayland is not a common executable program, it's meant
to be a proxy between the Wayland compositor and the legacy X11 clients
which wouldn't be able to run on Wayland otherwise.
Xwayland would be better installed in `libexec` but that directory is
(purposedly) not in the user `PATH` and therefore the Wayland compositor
may not be able to find Xwayland in that case.
To solve both problems (which options are supported by Xwayland and
where to look for it), add a `pkg-config` file specifically for Xwayland
which gives the full path to Xwayland (`xwayland`) and which options it
supports (using `pkg-config` variables).
The `pkg-config` file also provides the `Version` so the build scripts
can check for a particular version if necessary.
Obviously, Wayland compositors are not required to use the `pkg-config`
file and can continue to use whatever mechanism they deem preferable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Recently, rooted Xwayland crashes on wlroots-based compositors, because
wlroots removed the deprecated wl_shell protocol.
This MR fixes this by changing the code in question to the xdg-shell
protocol. My motivation do this: on etnaviv-based embedded platforms,
rooted Xwayland is much faster and doesn't cause UI rendering bugs
compared to rootless Xwayland.
Signed-off-by: Lukas F. Hartmann <lukas@mntre.com>
Move the Xwayland GLX declaration to its own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland vidmode declaration to its own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland CVT declaration to its own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move Xwayland screen related code to a separate source file and header.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland cursor declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland output declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland input declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland Present declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move Xwayland generic pixmap code to a separate source file and header.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Over time, Xwayland main source file `xwayland.c` has grown in size
which makes it look cluttered and harder to read.
Move the code dealing with Xwayland window to its own source and header
files.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Alan Coopersmith
Olivier Fourdan
Rouven Czerwinski
Simon Ser
Erik Kurzinger
Enrico Weigelt, metux IT consult
Michel Dänzer
Adam Jackson
Konstantin
Peter Hutterer
Xaver Hugl
Joshua Ashton
Jan Beich
Drew DeVault
Povilas Kanapickas
mntmn