fdo-mirrors/libei
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/libinput/libei.git synced 2025-12-20 02:10:08 +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 imposes.
The current implemtation 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
device is ultimately made by the caller implementation and
non-deterministic. For **libei** to support a batch request, *someone* would
have to wait. It cannot be the server as the exact requirements are unknown: do
we pause processing on the client altogether? We may miss a disconnect
event? Do we pause processing for one device only? But then we may be
re-ordering input events and cause havoc.
The current implementation of the protocol does not allow for a `libei` client
to connect, send all requests in bulk and exit. The decision on which devices
are available is made by the EIS implementation and that requires the `libei`
client to wait until such devices are available. On a technical level the
protocol is object-oriented and requests cannot be sent until the respective
device object is available.
It could be `libei` itself to implement these event queues but this too can
mess with the input order. And implementing an event queue is not hard, so
this issue is punted to the caller instead. Xwayland in its current
implementation already does this.
The duration until devices become available is non-deterministic, and so is
what types of devices are available to a client. For **libei** to support a
connect-send-exit approach, it would still require the client process to stay
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