Skip to content

Add the concept of passive/active libei contexts

Peter Hutterer requested to merge whot/libei:wip/passive-context into master

This is intended as a solution to !51 (closed) for the purpose of capturing input in the Synergy/Barrier use-case.

*Mar 03: Description updated - only the libei context is passive/active, the EIS context is both now

This patchset adds the concept of a "passive" and "active" context for both EIS and libei, referring to which part sends events and which part receives events. The previous use-cases (input emulation) are the equivalent a passive EIS context connected to an active libei context (ei_new() and eis_new() still default to that). The EIS implementation controls seats and the creation of the devices, libei can only send events for existing devices.

In the opposite case, an active EIS context sends events to a passive libei context. The EIS implementation still controls seats and the creation of the devices, libei is thus fully passive, it can only decide which seats/devices to listen to. This enables an EIS implementation to provide an abstracted view of the physical input devices available on the machine and forward events from those devices to a (passive) libei client.

libei (the project) thus becomes less target at input emulation and more a "input event transport layer".

The patchset itself is relatively straightforward, it copies the event sending ability from libei to libeis and then renames things.

In the Barrier/Synergy use-case, the server component would set up a passive libei context and contact the compositor to set up the capture triggers (e.g. screen edge triggers). The compositor provides an EIS implementation and once the edges trigger, the input events can flow between compositor and the Barrier/Synergy server component.

The full architecture looks like this. On the server side we have an active EIS and a passive libei

/dev/input/event0 -> [libinput|compositor|EIS] ----> [libei|barrier-server] ==> <barrier protocol>
                                |                                    |
                                 -- out-of-band trigger negotation --

and on the client side we have an active libei and a passive EIS

<barrier protocol> ==> [barrier-client|libei] -> [EIS|compositor]

The proposed XDG Desktop Portal for the negotiation of when to capture input is this PR: https://github.com/flatpak/xdg-desktop-portal/pull/714

Edited by Peter Hutterer

Merge request reports