From 1ef00d449c83405671e42d036db428ffc4bf4707 Mon Sep 17 00:00:00 2001 From: Olivier Fourdan Date: Mon, 18 Jul 2022 10:25:56 +0200 Subject: [PATCH] README: Xwayland is a Wayland client Xwayland is not a compositor, it's a Wayland client. Also fix a few typos while at it (XWayland -> Xwayland). Signed-off-by: Olivier Fourdan --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 426c219..eb333fb 100644 --- a/README.md +++ b/README.md @@ -310,7 +310,7 @@ the compositor instead. | libinput | libeis | \_wayland______ +----------+---------+ \ | | +-------+------------------+ - /dev/input/ +---brei----| libei | XWayland | + /dev/input/ +---brei----| libei | Xwayland | +-------+------------------+ | | XTEST @@ -319,7 +319,7 @@ the compositor instead. | X client | +-----------+ ``` -Of course, XWayland is just another Wayland compositor, so the connection +Of course, Xwayland is just another Wayland client, so the connection between libei and libeis could be handled through a portal. ### Short-lived applications @@ -340,7 +340,7 @@ re-ordering input events and cause havoc. 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 +this issue is punted to the caller instead. Xwayland in its current implementation already does this. ### uinput vs libei