[RFC] Automatic modifier update of slave devices

[Peter Hutterer]

On Thu, Feb 27, 2014 at 09:36:36PM +0100, wettstein509 at solnet.ch wrote:
> 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.

tbh, at this point I'm in preference of 3 (i.e. mirroring locking modifiers),
mainly because it seems the most obvious and intuitive solution.

This way the LED indicator behaviour is also as configured. On a test here,
if I assign grp_led:num to a single keyboard, toggling numlock will light up
all keyboards but that one, though the numlock state is preserved across
all.

With your option 5 above, that would probably be harder. And it gets harder
due to XKB allowing the indicators to light up in almost arbitrary
circumstances. For example, if IM_LEDDrivesKB is set we may end up with a
situation where lighting up the LED toggles the group on an otherwise
unrelated slave device.

The problem we're trying to solve here is that if capslock or numlock are
triggered, we want the other keyboards to reflect that in the most obvious
way. for the 95%, this is achieved by mirroring the locked modifiers and
letting each keyboard do what it's set up to do (grp_led:num
where needed, etc.). I think the simple solution is the best here.

Cheers,
   Peter