Currently, we would start dequeuing events as soon as a device is
resumed, regardless of its capabilities.
If the capabilities are not available, we would just fallback to the
regular XTEST code path and not use input emulation.
As a result, it is very likely that we shall lose the first events until
the compositor resumes first a device with the requested capabilities.
To avoid that issue, start emulating only once we have the requested
capabilities, if they match the seat capabilities.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1732
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1631>
This is a small code refactoring to help with clarity, simply move the
code from the switch case for device resume to a dedicated function.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1631>
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
Currently, we would log only the event type, use the libei API to also
log the name in plain text, so we can quickly identify the events we're
missing out.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1620>
Xwayland uses OEFFIS_DEVICE_ALL_DEVICES to get all possible device types
enabled.
Be more selective and specify explicitly keyboard and pointer instead of
relying on what "all devices" translates to in the stack.
See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/3194
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Xwayland maintains a connection to EI up for 10 minutes after an X11
client has vanished, to avoid going through the connection phase every
time a short lived X11 client comes and goes.
However, if the EI client gets freed (through some other event, e.g. the
user decides to terminate the EI session), Xwayland would still keep the
callback alive and end up trying to free an already freed EI client:
Invalid read of size 4
at 0x4C5E6F9: object_unref (util-object.h:89)
by 0x4C5E6F9: ei_unref (libei.c:77)
by 0x429525: free_ei (xwayland-xtest.c:224)
by 0x429A6E: disconnect_timer_cb (xwayland-xtest.c:404)
by 0x5E63FF: DoTimer (WaitFor.c:276)
by 0x5E6463: DoTimers (WaitFor.c:290)
by 0x5E6164: check_timers (WaitFor.c:133)
by 0x5E61E9: WaitForSomething (WaitFor.c:195)
by 0x4AD50E: Dispatch (dispatch.c:487)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
Address 0x15cc6ee8 is 8 bytes inside a block of size 240 free'd
at 0x48452AC: free (vg_replace_malloc.c:974)
by 0x4C5E729: object_destroy (util-object.h:73)
by 0x4C5E729: object_unref (util-object.h:91)
by 0x4C5E729: ei_unref (libei.c:77)
by 0x429525: free_ei (xwayland-xtest.c:224)
by 0x42A946: xwl_handle_ei_event (xwayland-xtest.c:804)
by 0x5EA977: HandleNotifyFd (connection.c:809)
by 0x5EE8E3: ospoll_wait (ospoll.c:657)
by 0x5E624D: WaitForSomething (WaitFor.c:208)
by 0x4AD50E: Dispatch (dispatch.c:487)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
Block was alloc'd at
at 0x484782C: calloc (vg_replace_malloc.c:1554)
by 0x4C5E777: ei_create (libei.c:73)
by 0x4C5E777: ei_create_context (libei.c:97)
by 0x42994B: setup_ei (xwayland-xtest.c:366)
by 0x42A383: xwayland_xtest_send_events (xwayland-xtest.c:658)
by 0x54ED4C: ProcXTestFakeInput (xtest.c:441)
by 0x54EE56: ProcXTestDispatch (xtest.c:475)
by 0x4AD6E6: Dispatch (dispatch.c:546)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
To avoid that issue, make sure to cancel the timer as soon as a EI
client is freed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
See-also: https://bugzilla.redhat.com/2243076
If we fail to setup EI, give up on using EI for XTEST and restore the
default XTEST handlers.
This happens when neither the portal nor the socket backends are usable.
This does not affect the portal operation though, if the user choose not
to allow a particular client, Xwayland would continue to use EI.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
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
With optional EI support in Xwayland, we would route XTEST events to EI
so that they get actually emulated in the Wayland compositor.
However, this implies that EI is actually supported in various places,
including the Wayland compositor of course. If, for whatever reason, we
fail to use EI, the actual XTEST events will be dropped.
That might be seen as a regression, as previously those would go through
the usual X11 processing of events and might have worked with X11 native
clients.
So, to keep backward compatibility, fallback to the plain old XTEST
method if EI is not available or not usable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
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>
YaoBing Xiao
Enrico Weigelt, metux IT consult
Olivier Fourdan
Joshua Ashton
Peter Hutterer