Fedora Bug 499961

The current modifier handling does not copy the modifier states around just right. The modifier state is handled separately in slaves and masters, hence some interesting combinations occur. Simplest (visible) test case: 
1. Plug in keyboard
2. Hit Caps Lock - indicator is on, capslock is on
3. Remove keyboard
4. Plug in keyboard

The keyboard is now in a neutral state, with the caps lock indicator off and the keyboard itself with neutral a modifier state. Pressing "a" on this keyboard gives "a" on the slave but "A" on the master (which still has the modifier set). Check with xinput --test-xi2 for the list of modifiers on both.


The same situation applies when pressing the shift key on two different keyboards. The release of the first shift key releases the modifier state in the master, hence even if the user keeps the shift pressed on the keyboard they're typing it's lowercase now.


IRC conversation regarding this.

13:58 < whot> daniels: where do we copy the xkb modifier state from master to 
              slave?
13:59 < whot> oh wait, we don't.
13:59 < whot> how hilarious
14:02 < daniels> whot: it needs to be merging rather than copying
14:10 < whot> not for a newly plugged in keyboard, no?
14:13 < daniels> whot: oh sorry, master to slave.  at a guess, i'd say it 
                 shouldn't happen.
14:14 < whot> daniels: it should on device init for the slave. try the 
              following: hit capslock, remove keyboard, plug in keyboard, type
14:14 < daniels> whot: surely the state of any device should reflect any events 
                 it's posted (even if none were delivered): so slaves only 
                 reflect their own modifier state, whereas masters reflect the 
                 union of all the slaves?
14:14 < whot> now you have the slave posting normal events, the master capslock 
              events
14:15 < daniels> listen to the master then?
14:15 < whot> well, the indicator is off too :)
14:15 < daniels> hah, good point
14:17 < daniels> ok, so it sounds like we should keep track of the slave's real 
                 state internally to compose the master state, but then always 
                 use the master state for everything
14:18 < whot> i think we already compose the master state, don't we?
14:19 < daniels> i think so, but i'd have to check tonight
14:19 < daniels> is there a bug about it?
14:20 < whot> fedora bug yes, i'm upstreaming right now
14:20 < daniels> whot: if you assign it to me, i'll (actually) take care of it
14:20 < whot> yeah, so it looks like the master state is always merged
14:21 < whot> i get 0x12 on the master for a 0x2 and an 0x10 slave
14:21 < whot> that's for locked mods
14:21 < daniels> right, not convinced we do the right thing on device unplug 
                 though?
14:21 < daniels> what happens if you unplug a keyboard with shift depressed?
14:21 < daniels> or caps lock activated
14:21 < whot> unplug releases all keys, doesn't it?
14:22 < whot> yeah, the master keeps the locked_modifiers
14:22 < whot> i really think we should feed back into the slaves from the master
14:23 < daniels> yeah, it'd be relatively simple to do
14:23 < whot> i mean, what's the use-case of someone wanting two different 
              modifier states from two slaves?
14:23 < daniels> it starts getting moderately unpleasant at some stage though
14:23 < whot> "i want to type lowercase on my laptop but uppercase on my usb 
              keyboard". CLOSED -> GETALIFE
14:23 < daniels> haha
14:23 < daniels> the slaves do need to keep individual state though
14:23 < daniels> else what happens when you hold shift down on two keyboards 
                 and release one?
14:24 < daniels> even if we only ever expose the master's state to clients, led 
                 code, whatever, presumably we need to keep the slave state 
                 around for accounting?
14:25 < whot> same thing as for the button code? state is the union of all 
              slaves?
14:26 < whot> or we just take this for locked modifiers? copy them down to the 
              slave on plug, then leave them alone?
14:28 < whot> actually, what happens now with the shift-case above is that once 
              you release one shift key -regardless which one- you get lowercase
14:28 < whot> on the master anyway
14:28 < daniels> right, which is arguably incorrect :)
14:28 < whot> yep