Re: [PATCH] new class for led devices

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

On 09/22/04 02:27:27, Vojtech Pavlik wrote:
> 
> 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).

Secondly, there is no good way through the input layer to query which  
leds and what colors are present.  I guess you can look at /proc/bus/ 
input/devices and if we agreed on a common name format or something.   
If you look around in arch/arm/mach-sa1100 and arch/arm/mach-pxa you  
can see we already have around 15 led devices, each one of them  
different.  Some support a green and a red led, some only a red led,  
some an amber and green, some control a single led that can be multiple  
colors, etc.  Userspace needs a way to ask which leds are available and  
which color will be turned on by which codes.

We could solve these problems in the input layer by adding some more  
information into /sys/class/input/.  If we could add an attribute  
saying, this is a led (or better yet, returning the info found in / 
proc/bus/input/devices for this device), and moreover an attribute  
specifying the mapping between led code numbers and a description (be  
it a color or numlock or whatever), then userspace would not need to  
use the LED_NUML symbols from input.h and we wouldn't need to add  
entries into that enumeration for every possible led type in the  
future.

Userspace would look in /sys/class/input/event2/mapping or whatever and  
realize there are two entries, 0 = green, 1 = amber or something.  Then  
when writing to /dev/input/event2 userspace fills in 0 in  
input_event.code to change the green and 1 to change the amber.

It's still not as intuitive as going /sys/class/leds and having two  
directories, one for each led, a color attribute to see color and a  
light attribute to toggle the led, but in the interest of using already  
available interfaces I could scrap it and use the input layer.

John