[lkml]   [2012]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Building BarGraph with LED subsystem

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

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


 \ /
  Last update: 2012-03-16 18:37    [W:0.047 / U:0.496 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site