fdo-mirrors/libei
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/libinput/libei.git synced 2026-02-18 11:50:31 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

README: add some clarification for why libei

Browse source 
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit is contained in:
Peter Hutterer 2020-07-29 20:21:27 +10:00
parent 7e6afe2373
commit f228927b1f
1 changed files with 42 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

45
README.md
View file

@ -40,8 +40,8 @@ The use-cases **libei** attempts to solve are:
**libei** provides **separation** of emulated input from normal input.
Emulated input is a distinct channel for the compositor and can thus be
handled accordingly. For example, the server may show warning sign in the
task bar while emulated input is active.
handled accordingly. For example, the compositor may show a warning sign in
the task bar while emulated input is active.
The second benefit is **distinction**. Each **libei** client has its own
input device set, the server is always aware of which client is requesting
@ -51,12 +51,51 @@ different emulated input devices differently.
The server is in **control** of emulated input - it can filter input or
discard at will. For example, if the current focus window is a password
prompt, the server can simply discard any emulated input. If the screen is
locked, the server can cancel all emulated input devices.
locked, the server can suspend all emulated input devices.
For the use-case of fowarding input (e.g. `synergy`) **libei** provides
capability monitoring. As with input emulation same benefits apply -
input can only be forwarded if the compositor explicitly does so.
Why not $foo?
-------------
We start from the baseline of: "there is no emulated input in Wayland (the
protocol)".
There is emulated input in X through XTEST but it provides neither
separation, distinction nor control in a useful manner. There are however
many X clients that require XTEST to work.
There are several suggestions that overlap with **libei**, with the main
proposals being:
- a Wayland protocol for virtual input
- a (compositor-specific) DBus interface for virtual input
Emulated input is not specifically Wayland-y. Clients that emulate input
generally don't care about Wayland itself. It's not needed to emulate
events on their own surfaces and Wayland does not provide global state. The
only connection to Wayland is merely that input events are *received*
through the Wayland protocol. So a Wayland protocol for emulating input is
not a great fit, it merely ticks the convenient box of "we already have IPC
through the wayland protocol, why not just do it there".
DBus is the most prevalent generic IPC channel on the Linux desktop but it's
not available in some compositors. Any other specific side-channel requires
an IPC mechanism to be implemented in the sender and receiver.
The current situation looks like that neither proposal will be universally
available. Wayland clients (including Xwayland) would need to support any
combination of methods.
**libei** side-steps this issue by making the *communication* itself a
an implementation detail and providing different *negotiation* backends.
A client can attempt to establish a **libei** context through a Flatpak
Portal first and all back onto a public DBus interface and fall back onto
e.g. a named UNIX socket. All with a few lines of code only. There is only
one spot the client has to care about this, the actual emulation of input is
identical regardless of backend.
High-level summary
------------------