From a27276b4c546d7f2bca05419166cffef5b6e78a2 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 23 Sep 2020 09:59:06 +1000 Subject: [PATCH] Drop mentions of capability monitoring The original idea here was that a libei client could request the Pointer capability to be notified of any pointer movements, thus providing a simple way to capture input for the synergy use-case. This is a can of worms better left untouched. How input events are captured and what information is available is quite specific to the display server, let alone the triggers for when it needs to start and stop. To have that in libei requires something like triggers ("start when pointer hits the edge") which again opens a new can of worms. Which seat are we referring to? What is a screen edge? How about shortcuts? Receiving input events can be handled by libeis anyway: any EIS server is capable of receiving input events by definition so the capability monitoring could be solved by making the capturing compositor a libei client and the other process an EIS server. i.e. the circle is closed with: [compositor|libei] -> [EIS|synergy-client] || [synergy-server|libei] -> [EIS|compositor] Signed-off-by: Peter Hutterer --- README.md | 35 ++++++++++++++++++++--------------- src/libeis.c | 2 -- src/libeis.h | 9 --------- 3 files changed, 20 insertions(+), 26 deletions(-) diff --git a/README.md b/README.md index e2c5c92..9ab3243 100644 --- a/README.md +++ b/README.md @@ -54,10 +54,6 @@ discard at will. For example, if the current focus window is a password prompt, the server can simply discard any emulated input. If the screen is locked, the server can suspend all emulated input devices. -For the use-case of fowarding input (e.g. `synergy`) **libei** provides -capability monitoring. As with input emulation same benefits apply - -input can only be forwarded if the compositor explicitly does so. - Why not $foo? ------------- @@ -122,20 +118,18 @@ local state). The above caters for the `xdotool` use-case. -The client may request to monitor a capability. When the server deems the -client to be in-focus, it forwards events from real devices to the client. -The decision of what constitutes logical focus and what events to forward -are up to the server. For a `synergy` use-case, the setup requires: -- `synergy-client` on host A monitoring the mouse and keyboard capabilities +- `synergy-client` on host A capturing mouse and keyboard events via an + unspecified protocol - `synergy-server` on host B requesting a mouse/keyboard capability device -- when `synergy-client` receives events via `libei` from compositor A it + from the compositor +- when `synergy-client` receives events via from compositor A it forwards those to the remote `synergy-server` which sends them via `libei` to the compositor B. -The compositor may choose to implement a hotkey to start/stop the events or -it may implement the screen edges to be the hot key. +**libei** does not provide a method for capturing events, see the +"Capability monitoring" section below. Using REIS ---------- @@ -236,12 +230,23 @@ desirable, esp. outside flatpak. The simplest solution is the client announcing the name so the UI can be adjusted accordingly. API wise-maybe an opaque key/value system so the exact auth can be left to the implementation. -### Triggers +### Capability monitoring -For `synergy` we need capability monitoring started by triggers, e.g. the -client requests a pointer capability monitoring when the real pointer hits +For the use-case of fowarding input (e.g. `synergy`) we need a method of +capturing input as well as forwarding input. An initial idea was for +**libei** to provide capability monitoring, i.e. a client requests all +events from a specific capability. As with input emulation same benefits +would apply - input can only be forwarded if the compositor explicitly does so. + +However, this fails in the details. For example, for `synergy` we need +capability monitoring started by triggers, e.g. the client requests a +pointer capability monitoring when the real pointer hits the screen edge. Or in response to a keyboard shortcut. +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. + ### Keyboard layouts The emulated input may require a specific keyboard layout, for example diff --git a/src/libeis.c b/src/libeis.c index 580ce1b..4c003f3 100644 --- a/src/libeis.c +++ b/src/libeis.c @@ -105,8 +105,6 @@ eis_event_type_to_string(enum eis_event_type type) CASE_RETURN_STRING(EIS_EVENT_CLIENT_DISCONNECT); CASE_RETURN_STRING(EIS_EVENT_DEVICE_ADDED); CASE_RETURN_STRING(EIS_EVENT_DEVICE_REMOVED); - CASE_RETURN_STRING(EIS_EVENT_REQUEST_CAPABILITY); - CASE_RETURN_STRING(EIS_EVENT_CANCEL_CAPABILITY); CASE_RETURN_STRING(EIS_EVENT_POINTER_MOTION); CASE_RETURN_STRING(EIS_EVENT_POINTER_MOTION_ABSOLUTE); CASE_RETURN_STRING(EIS_EVENT_POINTER_BUTTON); diff --git a/src/libeis.h b/src/libeis.h index 02a5998..8646cbc 100644 --- a/src/libeis.h +++ b/src/libeis.h @@ -76,15 +76,6 @@ enum eis_event_type { */ EIS_EVENT_DEVICE_REMOVED, - /** - * The client requests monitoring of a capability. - */ - EIS_EVENT_REQUEST_CAPABILITY, - /** - * The client cancelled the request to monitor that capability. - */ - EIS_EVENT_CANCEL_CAPABILITY, - EIS_EVENT_POINTER_MOTION = 300, EIS_EVENT_POINTER_MOTION_ABSOLUTE, EIS_EVENT_POINTER_BUTTON,