[RFC] Automatic modifier update of slave devices
Keith Packard
keithp at keithp.com
Mon Feb 24 16:00:28 PST 2014
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.
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.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140224/990ca8b6/attachment-0001.pgp>
More information about the xorg-devel
mailing list