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

[Dmitry Torokhov <dtor@insightbb.com>]

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