This is an attempt to provide an alternative to the current arm
specific led interface that is generic for all arches and uses the "one
value, one file" idea of sysfs.
I removed the function attribute that was in the previous patch, and
added the ability for userspace to control the timer on each led
individually. Userspace can also set the delay in milliseconds for the
blink.
John
On Wed, Sep 22, 2004 at 05:07:21AM +0000, John Lenz wrote:
> This is an attempt to provide an alternative to the current arm
> specific led interface that is generic for all arches and uses the "one
> value, one file" idea of sysfs.
>
> I removed the function attribute that was in the previous patch, and
> added the ability for userspace to control the timer on each led
> individually. Userspace can also set the delay in milliseconds for the
> blink.
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 ...
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Wed, 22 Sep 2004, John Lenz wrote:
> This is an attempt to provide an alternative to the current arm specific led
> interface that is generic for all arches and uses the "one value, one file"
> idea of sysfs.
>
> I removed the function attribute that was in the previous patch, and added the
> ability for userspace to control the timer on each led individually.
> Userspace can also set the delay in milliseconds for the blink.
(damned, non-inlined patch)
| - heartbeat: a read/write attribute that controls the heartbeat of this
| led. If heartbeat=0, then this led is controlled by userspace.
| Otherwise, heartbeat gives the time in milliseconds to delay between
| light changes.
That's not the real heartbeat! The real one says thumb-thumb-pause, and goes
faster if the load average increases :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
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
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...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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 <[email protected]>
--- 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
/*
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?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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
On Thu, Sep 23, 2004 at 05:28:25PM +0000, John Lenz wrote:
> >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 <[email protected]>
>
> --- 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
Thanks, applied. Now where is the driver for those Zaurus LEDs?
--
Vojtech Pavlik
SuSE Labs, SuSE CR