On Mon, Feb 24, 2014 at 04:00:28PM -0800, Keith Packard wrote: > Peter Hutterer <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
