Peter Hutterer <peter.hutte...@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. 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. 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. 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. -- keith.pack...@intel.com
pgpGppIUwW3lU.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel