>>>>> "simon" == simon <simon@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
