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