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 <peter.hutterer@who-t.net>

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

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);

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,