[RFC] Automatic modifier update of slave devices

[Keith Packard]

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>