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

Re: Building BarGraph with LED subsystem

From: John Stoffel <hidden>
Date: 2012-03-16 16:54:25
Also in: lkml

quoted
quoted
quoted
quoted
"simon" == simon  [off-list ref] writes:
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?  
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help