From f228927b1f9be60ea4609fb10229452b5d38faba Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 29 Jul 2020 20:21:27 +1000 Subject: [PATCH] README: add some clarification for why libei Signed-off-by: Peter Hutterer --- README.md | 45 ++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 42 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index f16caa1..6d0e72f 100644 --- a/README.md +++ b/README.md @@ -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 ------------------