From 68fe48c02f40e69d3c82964a7f88cd0517f8f73a Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 31 Jul 2020 14:02:33 +1000 Subject: [PATCH] README: make a note about the Xwayland PoC and short-lived apps Signed-off-by: Peter Hutterer --- README.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/README.md b/README.md index 6d0e72f..4ca02fc 100644 --- a/README.md +++ b/README.md @@ -178,3 +178,22 @@ cases it is up to the client to handle the result. Modifier state handling, group handling, etc. is still a private implementation so even where the server supports individual keymaps. So it remains to be seen if this approach is sufficient. + +### Xwayland and XTEST + +There are PoC implementations of using `libei` within Xwayland and +connecting it to a `libeis` context in the compositor (PoC with Weston). +This allows Xwayland to intercept XTEST events and route those through +the compositor instead. + +### Short-lived applications + +**libei** is not primarily designed for short-lived fire-and-forget-type +applications like `xdotool`. It provides context 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 however allows for a `libei` client +to send all requests in bulk and exit. Data is however processed in-sequence +by the `libeis` server so where the connection and device creation is +accepted by the server as-is, the requested events can be processed as-is.