[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150611080809.GD3184@type.bordeaux.inria.fr>
Date: Thu, 11 Jun 2015 10:08:09 +0200
From: Samuel Thibault <sthibault@...ian.org>
To: Anton Zinoviev <anton@....bas.bg>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Pavel Machek <pavel@....cz>,
Pali Rohár <pali.rohar@...il.com>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
rpurdie@...ys.net, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
514464@...s.debian.org
Subject: Re: Bug#514464: caps lock led does not show up
Hello,
Anton Zinoviev, le Tue 09 Jun 2015 19:03:39 +0300, a écrit :
> On Tue, Jun 09, 2015 at 04:17:23PM +0200, Samuel Thibault wrote:
> >
> > Dmitry Torokhov, le Mon 08 Jun 2015 14:43:07 -0700, a écrit :
> > > If user wants all keyboards to light up CapsLock LED when VT state locks
> > > CtrlL modifier they need to write a udev rule or similar to set up
> > > "kbd-ctrlllock" trigger for all appearing "input%::capslock" LED class
> > > devices.
> >
> > Anton, this is the interface proposed by the input maintainer, Dmitry,
> > to change which modifiers gets to light the keyboard LEDs (the exact
> > names may change, but the principle should be firm). I know this is
> > inconvenient for console-setup for handling hotplugged keyboards,
>
> Ok, the inconvenience is not a problem. The problem is I don't
> understant the meaning of this. :)
>
> Is there some documentation or a sample code I can read?
Putting
SUBSYSTEM=="leds", ENV{DEVPATH}=="*/input*::capslock", ATTR{trigger}="kbd-ctrlllock"
in /etc/udev/rules.d/50-leds.rules seems to be doing the work. It'd be
good to include this in the documentation along the patch.
Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists