fdo-mirrors/libei
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/libinput/libei.git synced 2025-12-25 10:30:07 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

README: some updates for the current implementation state

Browse source 
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit is contained in:
Peter Hutterer 2022-02-16 13:47:30 +10:00
parent 191913a9e3
commit 6801ab188b
1 changed files with 13 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
README.md
View file

@ -96,10 +96,10 @@ 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.
Portal first and fall back onto a public DBus interface and then 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
------------------
@ -116,11 +116,11 @@ A client starts a `libei` context and connects to the server - either
directly, via DBus or via a portal. The server (or the portal) approves or
denies the client. After successful authentication the server sends one or
more seats (a logical group of devices) to the client; the client can
request the creation of a device with capabilities `pointer`, `keyboard` or
request the creation of devices with capabilities `pointer`, `keyboard` or
`touch`, etc. in those seats.
The client triggers input events on this device, the server receives those
as events through `libeis` and can forwards them as if they were libinput
The client triggers input events on these devices, the server receives those
as events through `libeis` and can forward them as if they were regular input
events. The server has control of the client stream. If the stream is
paused, events from the client are discarded. If the stream is resumed, the
server will receive the events (but may discard them anyway depending on
@ -138,8 +138,7 @@ For a `synergy` use-case, the setup requires:
forwards those to the remote `synergy-server` which sends them via `libei`
to the compositor B.
**libei** does not provide a method for capturing events, see the
"Capability monitoring" section below.
**libei** does not provide a method for capturing events.
Using REIS
----------
@ -257,6 +256,9 @@ Some of the capabilities are distinctively display server-specific, for
example the concept of a seat and a device is different between X and
Wayland.
At this point, no implementation of capability monitoring is planned for
**libei**.
### Keyboard layouts
The emulated input may require a specific keyboard layout, for example
@ -264,9 +266,8 @@ for softtokens (usually: constant layout "us") or for the `synergy` case
where the remote keyboard should have the same keymap as the local one, even
where the remote host is configured otherwise.
libei provides keymap negotation: the client can pick a keymap, the server
can accept it, refuse it, or override it with its own. In the latter two
cases it is up to the client to handle the result.
In **libei**, the server informs the client about the keymap it expects and it
is up to the client to provide the correct keyboard events.
Modifier state handling, group handling, etc. is still a private
implementation so even where the server supports individual keymaps. So it