lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 6 Mar 2010 07:54:57 +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)

Hi!

> > > 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>.
> > 
> > I think that if we want to go LED route we shoudl start with adding led
> > devices to individual keyboard drivers first
> 
> Mmm, thinking again, I think my patch could be rather easily converted
> into creating led instances for each device, with proper trigger
> defaults.  Something like input-devicename::numlock? (devicename::numlock
> might get conflicts with non-input devices I guess?)

Yep, that would be cool.

> That being said, usermode tools which want to set up the modifiers and
> connect the input LEDs to them need an easy and proper way to do so.
> Having central input::numlock and such still seems a good thing.

This is something where I'm not too sure. Opening few files in
sequence is not that hard to the userland so "group of leds"
abstraction does not make too much sense...
									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

Powered by Openwall GNU/*/Linux Powered by OpenVZ