Building BarGraph with LED subsystem

Building BarGraph with LED subsystem

[simon]

Hi all,
I have a couple of questions about the (user-land) use of the LED subsystem.

I recently offered a patch for controlling the LEDs of the G27 gaming
wheel, on which the LEDs are arranged in a bar-graph of 5 to show
simulation RPM. The suggestion was to use the LED subsystem, which this
patch implements.

http://www.spinics.net/lists/linux-input/msg19747.html

Thinking further about how to about how to control this I was wondering
whether a 'threshold' trigger would be useful. This would allow the use of
value (uint?) to be compare against a threshold and the LED turned on/off
automatically.

The main benefit of doing this as a 'trigger' is that we could 'link' (or
'sync') multiple LEDs to use the same value input, thus making the
user-land stuff trivial.

Concept - ledtrig-thres would provide the controls:
   threshold - value to compare against.
   value - incoming value, if >= threshold LED is lit, if < threshold LED
is dark.
   link - 'none' (standalone comparison), or the path to the value of
another LED's value to use (ie '/sys/leds/my_device::2/value')

Comments? Is this all too complex?


Also I have a question about the default permissions on the LED controls;
Is it possible to register LEDs so that users have write permission? At
present the controls are only accessible as root.

Many thanks,
Simon.

Re: Building BarGraph with LED subsystem

[John Stoffel]

simon> I have a couple of questions about the (user-land) use of the
simon> LED subsystem.

simon> I recently offered a patch for controlling the LEDs of the G27 gaming
simon> wheel, on which the LEDs are arranged in a bar-graph of 5 to show
simon> simulation RPM. The suggestion was to use the LED subsystem, which this
simon> patch implements.

simon> http://www.spinics.net/lists/linux-input/msg19747.html

simon> Thinking further about how to about how to control this I was wondering
simon> whether a 'threshold' trigger would be useful. This would allow the use of
simon> value (uint?) to be compare against a threshold and the LED turned on/off
simon> automatically.

simon> The main benefit of doing this as a 'trigger' is that we could 'link' (or
simon> 'sync') multiple LEDs to use the same value input, thus making the
simon> user-land stuff trivial.

While making the kernel more complex... esp for a feature which is of
such limited use.  Do it all in userland, it's easier, you can use
floating point math, etc.  And to test changes, you don't have to
recompile a module and unload/reload it, etc.

Keeping as much of this in userland is better.

simon> Also I have a question about the default permissions on the LED
simon> controls; Is it possible to register LEDs so that users have
simon> write permission? At present the controls are only accessible
simon> as root.

udev is the answer here.  You probably want to make it so that the
LEDs are open to the user logged into the system console or currently
active Xsession.

John

Re: Building BarGraph with LED subsystem

[simon]

> simon> Also I have a question about the default permissions on the LED
> simon> controls; Is it possible to register LEDs so that users have
> simon> write permission? At present the controls are only accessible
> simon> as root.
>
> udev is the answer here.  You probably want to make it so that the
> LEDs are open to the user logged into the system console or currently
> active Xsession.
>
> John
>

So what would be the best way to achieve this (once the code gets into
kernel)? I mean so that 'Jane Doe' get the LEDs working when she plugs in
her wheel...

At present the patch uses the devices ID's to register the LED's. ie.
--
Mar 14 14:57:35 ubuntu kernel: [ 6462.204185] Registered led device:
0003:046D:C294.0009::RPM1
Mar 14 14:57:35 ubuntu kernel: [ 6462.204251] Registered led device:
0003:046D:C294.0009::RPM2
Mar 14 14:57:35 ubuntu kernel: [ 6462.204301] Registered led device:
0003:046D:C294.0009::RPM3
Mar 14 14:57:35 ubuntu kernel: [ 6462.204354] Registered led device:
0003:046D:C294.0009::RPM4
Mar 14 14:57:35 ubuntu kernel: [ 6462.204402] Registered led device:
0003:046D:C294.0009::RPM5
--

Simon.

Re: Building BarGraph with LED subsystem

[John Stoffel]

>>>>> "simon" == simon  <simon@mungewell.org> writes:

simon> Also I have a question about the default permissions on the LED
simon> controls; Is it possible to register LEDs so that users have
simon> write permission? At present the controls are only accessible
simon> as root.
>> 
>> udev is the answer here.  You probably want to make it so that the
>> LEDs are open to the user logged into the system console or currently
>> active Xsession.

simon> So what would be the best way to achieve this (once the code
simon> gets into kernel)? I mean so that 'Jane Doe' get the LEDs
simon> working when she plugs in her wheel...

Well, if you have an application that wants to control the wheel LEDs,
then it needs to plug in an discover whether the wheel exists, whether
it's got LEDs, etc.  All part of the HID subsystem as understand it. 

simon> At present the patch uses the devices ID's to register the LED's. ie.
simon> --

simon> Mar 14 14:57:35 ubuntu kernel: [ 6462.204185] Registered led device:
simon> 0003:046D:C294.0009::RPM1
simon> Mar 14 14:57:35 ubuntu kernel: [ 6462.204251] Registered led device:
simon> 0003:046D:C294.0009::RPM2
simon> Mar 14 14:57:35 ubuntu kernel: [ 6462.204301] Registered led device:
simon> 0003:046D:C294.0009::RPM3
simon> Mar 14 14:57:35 ubuntu kernel: [ 6462.204354] Registered led device:
simon> 0003:046D:C294.0009::RPM4
simon> Mar 14 14:57:35 ubuntu kernel: [ 6462.204402] Registered led device:
simon> 0003:046D:C294.0009::RPM5
simon> --

This part is probably fine, but I'd call it 'LED1..5' instead, since
they're LEDs, not true RPM indicators.  I guess what I'm trying to say
is that putting as much of this into user space, makes for a much more
flexible environment.

You might want to look into the Linux HID sub-system for how it
enumerates the abilities of devices like keyboards, game pads, etc.
They already have alot of that infrastructure in place. 

John

Re: Building BarGraph with LED subsystem

[simon]

> While making the kernel more complex... esp for a feature which is of
> such limited use.

Is the concept of a bargraph of LEDs really a 'limited use'? I can think
of several uses... I mean isn't flashing or a heart beat just as limited
;-)


> Do it all in userland, it's easier, you can use
> floating point math, etc.  And to test changes, you don't have to
> recompile a module and unload/reload it, etc.

For my application a user-land stub would do math to work out threshold
values and push current value (in the right format) into the LED
subsystem.

Once kernel framework is provided it should not need re-compilation on a
case by case basis.

Simon

Re: Building BarGraph with LED subsystem

[John Stoffel]

>>>>> "simon" == simon  <simon@mungewell.org> writes:

>> While making the kernel more complex... esp for a feature which is of
>> such limited use.

simon> Is the concept of a bargraph of LEDs really a 'limited use'? I
simon> can think of several uses... I mean isn't flashing or a heart
simon> beat just as limited ;-)

Yes, it's a limited use.  Are 10% of linux users going to have this
hardware and use it?  

>> Do it all in userland, it's easier, you can use floating point
>> math, etc.  And to test changes, you don't have to recompile a
>> module and unload/reload it, etc.

simon> For my application a user-land stub would do math to work out
simon> threshold values and push current value (in the right format)
simon> into the LED subsystem.

simon> Once kernel framework is provided it should not need
simon> re-compilation on a case by case basis.

If the kernel only provides a way to set the brightness of individual
LEDs, why can't you do the rest in userspace?  What if the user wants
to have the LEDs run right to left, or visa versa?  

Doing it in userspace means that you can do it however you want with
just a simple change.  Putting this stuff into the kernel means you
can't make changes without being much more invasive.

As an analogy, if you put a dimmer on your dining room lights, where
is the switch?  In the living room (user space) or down in the
electrical box (kernel space) hooked up by strings to move the switch
up and down?  It's a crappy example, but it gets the idea across.

John

Re: Building BarGraph with LED subsystem

[simon]

>>> While making the kernel more complex... esp for a feature which is of
>>> such limited use.
>
> simon> Is the concept of a bargraph of LEDs really a 'limited use'? I
> simon> can think of several uses... I mean isn't flashing or a heart
> simon> beat just as limited ;-)
>
> Yes, it's a limited use.  Are 10% of linux users going to have this
> hardware and use it?

OK I'm not making myself clear, apologies for that.

I'd be proposing a 'ledtrig-thres' module which is totally independent of
the G27, which would just provide the ability to light (or dark) a LED
depending on a threshold and value.

With a bit of extra code (in this module) multiple LEDs could be 'linked'
to produce a bargraph, by automatically comparing the same value against
their own thresholds.

As to the hardware; it could be the G27, a single LED or a matrix of LEDs
slung off one of the other LED subsystem devices.

I'd want to show RPMs on my G27, but others could display CPU usage,
emulate a VU meter/FFT display, have the 'low memory panic light' come on,
etc...


> simon> Once kernel framework is provided it should not need
> simon> re-compilation on a case by case basis.
>
> If the kernel only provides a way to set the brightness of individual
> LEDs, why can't you do the rest in userspace?  What if the user wants
> to have the LEDs run right to left, or visa versa?

I'm just wondering whether writing this as a trigger module is of use to
others. If well defined, lots of uses are possible.

Simon

Re: Building BarGraph with LED subsystem

[John Stoffel]

>>>>> "simon" == simon  <simon@mungewell.org> writes:

>>>> While making the kernel more complex... esp for a feature which is of
>>>> such limited use.
>> 
simon> Is the concept of a bargraph of LEDs really a 'limited use'? I
simon> can think of several uses... I mean isn't flashing or a heart
simon> beat just as limited ;-)
>> 
>> Yes, it's a limited use.  Are 10% of linux users going to have this
>> hardware and use it?

simon> OK I'm not making myself clear, apologies for that.

Thanks for taking the time to make yourself clearer.  Now I understand
what you're trying to do...

simon> I'd be proposing a 'ledtrig-thres' module which is totally
simon> independent of the G27, which would just provide the ability to
simon> light (or dark) a LED depending on a threshold and value.

And why does this need to be in the kernel?  That's what I'm asking.
Make it a library where you do:

     led_thresh(*led1,int value);
     led_thresh(*led2,int value + 300);
     led_thresh(*led3,int value + 600);
     led_thresh(*led4,int value + 900);
     led_thresh(*led5,int value + 1200);
     leds = led_array(*led1, *led2, *led3, *led4, *led5);
     led_on(*leds, 500);

and it lights up the first two LEDs in the array?  You'd need to do
something like this *anyway* in your code so that you can make this
flexible enough to handle arrays with varying numbers of LEDs.  So why
does it need to be in the kernel again?

simon> With a bit of extra code (in this module) multiple LEDs could be 'linked'
simon> to produce a bargraph, by automatically comparing the same value against
simon> their own thresholds.

So how much code is needed in my userspace program to setup and add
these multiple LEDs (which don't have to be physically anywhere near
each other, think house lighting...) to an array which manages them?  

simon> As to the hardware; it could be the G27, a single LED or a
simon> matrix of LEDs slung off one of the other LED subsystem
simon> devices.

simon> I'd want to show RPMs on my G27, but others could display CPU
simon> usage, emulate a VU meter/FFT display, have the 'low memory
simon> panic light' come on, etc...


simon> Once kernel framework is provided it should not need
simon> re-compilation on a case by case basis.

>> If the kernel only provides a way to set the brightness of individual
>> LEDs, why can't you do the rest in userspace?  What if the user wants
>> to have the LEDs run right to left, or visa versa?

simon> I'm just wondering whether writing this as a trigger module is of use to
simon> others. If well defined, lots of uses are possible.

Just write a library that does this and give it out to people.  Then
you can add in dimming and all kinds of other LED tricks as well.  

John