[RFC] Automatic modifier update of slave devices

[Peter Hutterer]

On Mon, Feb 24, 2014 at 04:00:28PM -0800, Keith Packard wrote:
> Peter Hutterer <peter.hutterer at who-t.net> writes:
> 
> > there is no good solution here, it's just a question which foot we
> > prefer shooting at.
> 
> Yeah, that part seems clear enough at least. So, it seems like we have a
> list of options:
> 
>  1) Mirror nothing.
> 
>     Indicators and modifiers for each slave are independent. Events seen
>     through the slave device will not have modifier bits set. Event
>     seen through the master device will have the union of all slave
>     device modifiers.
> 
>     Problems: Users may be confused by the mis-match between indicator
>     state and locking modifier state for master devices.
> 
>     Benefits: Slave devices will operate independently and will not
>     report mysterious modifier bits.

again, I need to point out here that slaves operate independently, but this
is not what the user would see. XI2 applications (should) care about master
devices and floating slaves, if an application cares about attached slaves
that should only be for very device-specific handling. gnome-settings-daemon
currently does this for wacom pad buttons, but this is not for your average
client, and _certainly_ not for core clients which see the merged master
device state.

(see also my reply to JimC here)

>  2) Mirror indicators.
> 
>     Indicators for slave devices are driven by the master; all slave
>     device indicators match the master state.
> 
>     Problems: Users may be confused by the mis-match between indicator
>     state and associated locking modifier state on slave devices.
> 
>     Question: Will the locking keys operate oddly on the other slave
>     devices? If the state of the local locking key is not reflected by
>     the local indicator, what happens when you press the local locking
>     modifier which is logically 'up' while the matching indicator says 'down'?
> 
>     Benefit: Users will see correct indicators for locking modifiers for
>     events sent through the master device.

see my comment on 1, the only time this would be noticed is in XI2
applications that handle attached slave devices.

>  3) Mirror locking modifiers and indicators.
> 
>     Locking modifiers and their associated indicators are driven by the
>     master. All slave indicators and locking modifiers are sent to the
>     master and then distributed to all other slaves.
> 
>     Problems: Slave devices will end up sending locking modifier state
>     from other associated slave devices, but not other modifier state.
> 
>     Benefit: Slave locking modifiers should act consistently with the
>     associated indicators (see question for 2 above).
> 
>  4) Mirror all modifiers
> 
>     All modifiers for all slave devices are mirrored through the master
>     so that all slaves exactly track all modifiers.
> 
>     Problem: Slave devices will see shift/ctrl/alt modifiers from other
>     slaves, as well as seeing locking modifiers from other slaves.
> 
>     Benefit: All modifiers will the same as seen through both the slave
>     and master devices, and all indicators will match everywhere.
> 
> 
> 1) is what we do today, and the lack of indicator tracking sucks for
> users.
> 
> 2) and 3) differ only slightly, and the question I have for 2) is
> whether the locking keys will act 'funny'. If so, then 3) is clearly a
> better plan.

yes, they will act "funny" as in the indicator still doesn't reflect the
slave device's state. so you still get situations where master has caps lock
on, slave 1 has caps lock on, but slave 2 has the LED on but caps off. you'd
then get two different xkb syms from master and slave (XI2 only, core won't
see it, XI1 won't ever see the master device).

> I do lean to 3) at this point, just because that way the indicators
> correctly reflect events sent to both slave and master devices, which at
> least seems a bit more consistent.

I'm fine with either 3 or 4 tbh, though note that from the user's POV we
already do 4. open xterm, hit ctrl one one keyboard and C on the other and
you'll get a ctrl+c through the core protocol and from the XI2 master.

Cheers,
   Peter