linux-kernel - Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

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]

Message-ID: <20150605152806.GE2267@type>
Date:	Fri, 5 Jun 2015 20:58:06 +0530
From:	Samuel Thibault <samuel.thibault@...-lyon.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Pali Rohár <pali.rohar@...il.com>,
	Pavel Machek <pavel@....cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Jiri Slaby <jslaby@...e.cz>, Bryan Wu <cooloney@...il.com>,
	Richard Purdie <rpurdie@...ys.net>,
	lkml <linux-kernel@...r.kernel.org>,
	Evan Broder <evan@...oder.net>,
	Arnaud Patard <arnaud.patard@...-net.org>,
	Peter Korsgaard <jacmet@...site.dk>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Rob Clark <robdclark@...il.com>,
	Niels de Vos <devos@...oraproject.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>, blogic@...nwrt.org
Subject: Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic
 LEDs layer

Hello,

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.

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/