On Thu, Feb 27, 2014 at 09:36:36PM +0100, [email protected] 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
