Add an option to InputCapture::Activated signal to pass current key modifier states

[gabeklavans]

My understanding and the problem scenario

An application wishing to achieve input forwarding, such as Deskflow, fully via portals uses InputCapture on the Deskflow server and RemoteDesktop on the Deskflow client with libei serving as the mechanism for handling key events themselves on either end.

I've noticed that, due to InputCapture not being active until the compositor determines a barrier is crossed, the application (e.g. Deskflow) has no chance to keep key modifier states in sync. For example, if the physical keyboard toggles CapsLock on while InputCapturing is inactive in a libei receiver context (e.g. a Deskflow server), the application will (likely) not receive any events. Then, when InputCapture activates, and the user is emulating input under a libei sender context (e.g. a Deskflow client), the libei receiver context will have no way of knowing that CapsLock had been enabled and will not be able to convey this state to the libei sender context, and the CapsLock state will be out-of sync between the host and emulated devices.

My proposal

So, my idea to get around this with as little change to protocols as possible is: add a new option key to the activated signal that contains the current modifer state in the form of an EI_EVENT_KEYBOARD_MODIFIERS event so that it can be parsed by all the EI_EVENT_KEYBOARD_MODIFIERS handlers available in libei. If not an event itself, at least the necessary information to be able to be parsed by some function in the stack.

Let me know if I'm missing something on the application-side or if I'm misunderstanding something in the protocol stack.

Deskflow specific context

[jadahl]

I think it'd make more sense to have this information passed via libei upon activation. There is an activation ID that can be used to couple an activation signal with the libei event stream starting, so it would be a matter of specifying that once emulation is started, a keyboard modifier event must always be sent.

[whot]

yeah, I agree, sending this via the portal would mean we'd have to also specify which device the modifier event belongs to (libei may have multiple keyboard devices with different keymaps), so putting this into the dbus events is not really workable anyway.

[gabeklavans]

From the comments here and some discussion with @Sodivad , it does seem like this portal isn't the proper place to handle this problem. It will be attempted to be handled at the compositor level (such as kwin). Thanks for the feedback!