linux-kernel - Re: [PATCH] hid: add two led codes to hid input mapping

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: <200704020004.51861.dtor@insightbb.com>
Date:	Mon, 2 Apr 2007 00:04:51 -0400
From:	Dmitry Torokhov <dtor@...ightbb.com>
To:	Dan Engel <dan@...rceharvest.com>
Cc:	Jiri Kosina <jkosina@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hid: add two led codes to hid input mapping

Hi Dan,

On Sunday 01 April 2007 23:28, Dan Engel wrote:
> On Sun, 2007-04-01 at 19:43 +0200, Jiri Kosina wrote:
> > On Sun, 1 Apr 2007, Dmitry Torokhov wrote:
> > 
> > > No, I do not want to add any more LED constants to input. In fact I 
> > > think that adding constants beyond keyboard indicators was a mistake. We 
> > > have led subsystem that provides interface to control arbitrary leds and 
> > > we should use it.
> > 
> > Ah, of course. Dan, could you please redo the patch to use the leds 
> > infrastructure and send it to me?
> 
> Perhaps I could find a way to do that, but it seem rather a round-about
> way to go about it. The fact is that the input subsystem is already the
> home of this device.
> 
> As far as I can tell, the led subsystem doesn't already provide any
> framework for mapping LED's to HID input events. I could possibly create
> a driver in the led subsystem that sends the corresponding events to the
> input subsystem, but those events would be dropped by the input system,
> anyway, since the event class would still have to be EV_LED and the code
> would still be unrecognized without those two mappings.
>

No, no, do not try to route the control through evdev. Since the LED
override is device-sepcific (i.e yours is the only device which will
react in that way) I'd recommend using sysfs attributes to control it.
Hm, we may need to wait for HID bus to clearly do that in a separate
driver...
 
> Given that the HID or input subsystem still needs to be in the loop,
> however the driver is written, can you give any advice for accomplishing
> that without adding the extra LED mappings?

Actually I want to keep input subystm out of the loop here, since LEDs
such as mail, charging, etc have nothing to do with user input but
rather reflect overall system/application state.

-- 
Dmitry
-
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/