[RFC] Automatic modifier update of slave devices

[wettstein509 at solnet.ch]

Sorry for joining late, and sorry for doing so with yet another option.

I had a look at section 9.2.1 of the XKB protocol specification.  This
section describes how keyboard state affects LEDs, called "indicators".
And it specifies the opposite: How LED state affect keyboard state.  It
is possible, for each LED separately, to forbid the state an LED being
changed from the "outside" (IM_NoExplicit flag, or "allowExplicit" in
xkbcomp syntax).  If the state of an LED can be changed, a further flag
(IM_LEDDrivesKB, "drivesKeyboard" in xkbcomp) decides whether this change
changes the keyboard state associated to it.  For example, when the Caps
Lock LED is turned on, whether the Lock flag should be added to the
locked modifiers as a consequence.

So option number 5 would be that the master request the LED to be
set/reset, and the rest proceeds according to what is specified in the
keymap -- whether the LED is affected at all, and how this translates to
keyboard state.  The advantage of the approach that there is a means for
users to select the desired behaviour, using existing tools.

There are caveats, of course.  One of them is that the defaults in
xkeyboard-config will prevent the LED state to propagate to keyboard
state, but that should not be a big deal to change.

Andreas