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

README: reword the blurb about short lived applications

Browse source 
This particular wording dates to when libei created devices and the EIS
implementation would ack/nack those devices. This isn't the case anymore
so let's reword this a bit.

Closes #62
This commit is contained in:
Peter Hutterer 2024-08-22 12:12:20 +10:00
parent 997b7c0f37
commit 6230e187fd
1 changed files with 12 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
README.md
View file

@ -319,19 +319,19 @@ like `xdotool`. It provides context and device negotiation between the
server and the client - the latter must be able to adjust to limitations the server and the client - the latter must be able to adjust to limitations the
server imposes. server imposes.
The current implemtation of the protocol does not allow for a `libei` client The current implementation of the protocol does not allow for a `libei` client
to send all requests in bulk and exit. The decision on whether to accept a to connect, send all requests in bulk and exit. The decision on which devices
device is ultimately made by the caller implementation and are available is made by the EIS implementation and that requires the `libei`
non-deterministic. For **libei** to support a batch request, *someone* would client to wait until such devices are available. On a technical level the
have to wait. It cannot be the server as the exact requirements are unknown: do protocol is object-oriented and requests cannot be sent until the respective
we pause processing on the client altogether? We may miss a disconnect device object is available.
event? Do we pause processing for one device only? But then we may be
re-ordering input events and cause havoc.
It could be `libei` itself to implement these event queues but this too can The duration until devices become available is non-deterministic, and so is
mess with the input order. And implementing an event queue is not hard, so what types of devices are available to a client. For **libei** to support a
this issue is punted to the caller instead. Xwayland in its current connect-send-exit approach, it would still require the client process to stay
implementation already does this. alive until device negotiation is complete within libei and all events have
been sent. And since the client process must stay alive, we might as well
have the device negotiation handled in the caller.
### uinput vs libei ### uinput vs libei