[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

Samuel Thibault samuel.thibault at ens-lyon.org
Fri Jun 5 08:28:06 PDT 2015


Dmitry Torokhov, le Thu 23 Apr 2015 10:04:49 -0700, a écrit :
> One thing that I know we'd have to fix is that input device must be
> "opened" before we can engage it, right now LED interface violates
> this requirement.

What do you mean precisely by "engage"?  In the following, I guess
actually calling dev->event(EV_LED)

> It works right now because keyboard handler attaches
> to most input devices with LEDs early enough for it to be
> unnoticeable, but it does not mean that it is correct. It might be as
> easy as calling input_open() unconditionally if devices has LEDs.

This seems like only a workaround, perhaps it should rather be leds.c
which checks for dev->users before calling dev->event(EV_LED)?

> Another issue is that I do not think we should be introducing virtual
> VT leds. I believe LEDs should belong to real devices;

But then how to fix console-setup's bug? (it was actually the starter
for all this work)

See http://bugs.debian.org/514464

console-setup needs a way to tell which kbd modifier should toggle the
capslock LED on all the keyboards used by the VT. Thus the point of VT
leds, which people can use to decide the LED behavior of all keyboards,
including hotplugged ones etc.


More information about the linux-arm-kernel mailing list