Thread (8 messages) flat view 8 messages, 2 authors, 2012-03-16

Re: Building BarGraph with LED subsystem

From: <hidden>
Date: 2012-03-16 17:35:37
Also in: lkml

quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help