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,