[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1175484539.12355.18.camel@monica.engel.home>
Date: Sun, 01 Apr 2007 23:28:59 -0400
From: Dan Engel <dan@...rceharvest.com>
To: Jiri Kosina <jkosina@...e.cz>
Cc: Dmitry Torokhov <dtor@...ightbb.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hid: add two led codes to hid input mapping
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.
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?
Thanks for any help,
-Dan Engel
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists