Re: [PATCH] new class for led devices

[John Lenz <lenz@cs.wisc.edu>]

On 09/22/04 17:07:15, Pavel Machek wrote:
> Hi!
> 
> > >Well, we already have an interface for setting LEDs through the input
> > >layer, it'd be trivial to create an input device driver with just  
> > >LEDs
> > >and no buttons/keys ...
> > >
> > 
> > It's not really a nice fit with what we are trying to do.  In the input  
> > layer, there is a whole list of led types, none of which make sense...  
> > For example, on the Sharp Zaurus, we have two leds, one green, one  
> > amber.  Which one is LED_NUML?  We don't enforce anything on the policy  
> > userspace has for the leds, sometimes it might use the amber led to let  
> > the user know they have new mail, and sometimes to show the power is  
> > plugged in, sometimes for something else (maybe even that caps lock or  
> > numlock is on).
> 
> Actually on zaurus one led is labeled "CHARGING" and second is labeled
> "MAIL". There are PC keyboards with "MAIL" led already, I
> believe... It does not seem to be that bad fit. I do not think you
> want to label leds by colors, machine may well have three green leds
> (see normal pc keyboard). And on most machines you do not even know
> what color the leds are (new notebooks like blue leds :-().
> 
> So right solution seems to be adding LED_MAIL and LED_CHARGING and be
> done with that...

Yeah, that would work.  And if userspace wants to use the led for something
else, just uses MAIL and CHARGING as the names of the leds.

Signed-off-by: John Lenz <lenz@cs.wisc.edu>

--- bk/include/linux/input.h~input
+++ bk/include/linux/input.h
@@ -542,6 +542,8 @@
 #define LED_SUSPEND		0x06
 #define LED_MUTE		0x07
 #define LED_MISC		0x08
+#define LED_MAIL		0x09
+#define LED_CHARGING		0x0a
 #define LED_MAX			0x0f
 
 /*