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 <[email protected]> wrote: > Peter Hutterer <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
