Re: Building BarGraph with LED subsystem

[simon@mungewell.org]

>>> 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