[RFC] Automatic modifier update of slave devices

[Daniel Stone]

Hi,
Overall, I think it's close to the best we can make of a bad situation
(in hindsight, I think we both would've done things differently ...),
but Keith's pretty on the money:

On 24 February 2014 06:57, Keith Packard <keithp at keithp.com> wrote:
> Peter Hutterer <peter.hutterer at who-t.net> writes:
>> yeah, it does seem like the most sensible behaviour but right now the
>> keyboards are completely independent and the event routing is based on that.
>> so if you hit ctrl on one keyboard, alt on the other, the master will have
>> ctrl+alt down, while each keyboard only has either modifier set.
>> somewhat similar to the button state.
>
> There is an obvious difference between locking and non-locking
> modifiers. One can imagine wanting to update only the locking modifier
> state and associated indicators and leaving the state of the non-locking
> modifiers alone, so that hitting Shift on one keyboard would not be
> visible if monitoring another slave keyboard device, but that NumLock
> *would* be mirrored across slaves connected to the same master. On
> second thought, that's a crazy plan.
>
> I'd say the correct semantic is for the slave device to report the same
> modifier state through either the slave or master device, and so the
> only sensible plan is to mirror the modifier state across all slave
> keyboards. Otherwise, why would you have tied the two slaves to the same master?

It is a crazy plan indeed - and not just because one of the stated
usecases was for footpedal modifiers to take effect on a keyboard for
accessibility reasons.  But I think the locking thing is actually
pretty close to the money: what if, when pushing state back down to
slave devices, we only push the lock state, rather than
latched/active? I think that solves the immediate problem
(synchronising LEDs and permanent state) whilst not doing anything
surprising like having a base modifier down which was never pressed on
that device.

Cheers,
Daniel