Simplify the suspend/resume behavior

The use-case of suspending individual capabilities is niche - where a client
needs to rely on this it should create multiple devices with different
capabilities so they can be suspended separately.

Also clarify that the server *must* process events even from a suspended
device. This works around a race condition where a client has sent several
events already before the suspend comes in - it has to assume that any event
sent before the server event is handled updates the state in the server.

Implementation-wise, libei will start filting events once ei_dispatch()
returned the suspend event to the client.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit is contained in:
Peter Hutterer 2020-07-16 10:58:34 +10:00
parent 61bdb2c891
commit 68f9fa4b1c
2 changed files with 21 additions and 34 deletions

View file

@ -75,37 +75,20 @@ enum ei_event_type {
*/
EI_EVENT_DEVICE_REMOVED,
/**
* Any events sent from this device will be discarded until the next
* resume.
*/
EI_EVENT_DEVICE_SUSPENDED,
/**
* The client may send events.
*/
EI_EVENT_POINTER_RESUME = 300,
/**
* Any events sent will be discarded until the next resume.
*/
EI_EVENT_POINTER_SUSPEND,
EI_EVENT_DEVICE_RESUMED,
/**
* The client may send events.
*/
EI_EVENT_KEYBOARD_RESUME = 400,
/**
* Any events sent will be discarded until the next resume.
*/
EI_EVENT_KEYBOARD_SUSPEND,
/**
* Notification of the keymap to be used by the client.
*/
EI_EVENT_KEYBOARD_KEYMAP,
/**
* The client may send events.
*/
EI_EVENT_TOUCH_RESUME = 500,
/**
* Any events sent will be discarded until the next resume.
*/
EI_EVENT_TOUCH_SUSPEND,
EI_EVENT_KEYBOARD_KEYMAP = 400,
};
struct ei_ctx *

View file

@ -217,8 +217,8 @@ eis_device_disable_capability(struct eis_device *device,
*
* If the device is rejected, call eis_device_disconnect() instead.
*
* The device's capabilities are suspended, use
* eis_device_resume_capability() to enable events from the client.
* The device is suspended, use eis_device_resume() to enable events from
* the client.
*/
void
eis_device_connect(struct eis_device *device);
@ -232,24 +232,28 @@ void
eis_device_disconnect(struct eis_device *device);
/**
* Notify the client that the capabilities are suspended and that no events
* from the client for this capability will be processed.
* Notify the client that the device is suspended and that no events
* from the client will be processed.
*
* The library filters events sent by the client **after** the suspend
* notification has been processed by the client but this does not affect
* events already in transit. In other words, the server may still receive
* a number of events from a device after it has been suspended and must
* update its internal state accordingly.
*
* @param device A connected device
* @param cap A bitmask of the capabilities to suspend.
*/
void
eis_device_suspend_capability(struct eis_device *device, uint32_t cap);
eis_device_suspend(struct eis_device *device);
/**
* Notify the client that the capabilities are resumed and that events
* from the client for this capability will be processed.
* from the device will be processed.
*
* @param device A connected device
* @param cap A bitmask of the capabilities to resume.
*/
void
eis_device_resume_capability(struct eis_device *device, uint32_t cap);
eis_device_resume(struct eis_device *device);
/**
* Get the width of the absolute pointer device in 1/1000th of a logical
@ -306,7 +310,7 @@ eis_device_get_touch_height(struct eis_device *device);
* Set the keymap on the device.
* Due to inherent race conditions with changing the keymap on a device in
* an asynchronous communication channel, a server should alway suspend the
* keyboard capability before changing the keymap.
* device before changing the keymap.
*
* @param type the type of the keymap
* @param fd a memmap-able file descriptor to the keymap