[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100306065250.GD28759@elf.ucw.cz>
Date: Sat, 6 Mar 2010 07:52:50 +0100
From: Pavel Machek <pavel@....cz>
To: Samuel Thibault <samuel.thibault@...-lyon.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
"H. Peter Anvin" <hpa@...or.com>,
Alexey Dobriyan <adobriyan@...il.com>,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
alan@...rguk.ukuu.org.uk, mgarski@...t.pl,
linux-input@...r.kernel.org, Vojtech Pavlik <vojtech@...e.cz>,
Richard Purdie <rpurdie@...ys.net>
Subject: Re: [PATCH] Route kbd leds through the generic leds layer (3rd
version)
On Thu 2010-02-25 22:44:03, Samuel Thibault wrote:
> Dmitry Torokhov, le Thu 25 Feb 2010 02:20:56 -0800, a écrit :
> > I am aunsure about this patch. It ties all LEDs together
>
> For now, yes. There could be an additional per-device layer that the
> user could select instead, but my patch doesn't prevent that.
Well, having one LED device for all the keyboard leds, and separate
LED device for each of them indivudually would not be quite nice, and
once we have the "one for all" device, we can't really get rid of it.
> Being able to assign only some of the devices to the linux console
> would indeed probably be good, but to me it's just a refinement. Users
> a priori assume all keyboards get their leds updated, so my patch
> makes sense. And it won't prevent a further patch that, in addition
> to input::<led> leds, adds per-device leds, which the user could use
> instead of input::<led>.
As I said, having both is ugly... but the triggers could / should be
merged now...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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