Re: [PATCH] new class for led devices

[Vojtech Pavlik <vojtech@suse.cz>]

On Thu, Sep 23, 2004 at 08:02:12PM +0200, 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.
> 
> Looks good to me.
> 
> There's LED_MAX defined to be 0xf. Can we support more than 16 leds?
 
It's a constant that can be changed without breaking anything. Old apps
will keep working (but will only have access to the first 16),
recompiled apps will have access to all. So I think we can leave it as
it is for now and when need arises we can change it.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR