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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
