Re: [PATCH] new class for led devices
From: John Lenz
Date: Wed Sep 22 2004 - 14:59:03 EST
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/