-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote:
Add generic support for RGB LED's.
Basic idea is to use enum led_brightness also for the hue and
saturation color components.This allows to implement the color
extension w/o changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB
extension.
Flag LED_SET_HUE_SAT allows to specify that hue / saturation
should be overridden even if the provided values are zero.
Some examples for writing values to
/sys/class/leds/<xx>/brightness: (now also hex notation can be
used)
255 -> set full brightness and keep existing color if set 0 ->
switch LED off but keep existing color so that it can be
restored
if the LED is switched on again later
0x1000000 -> switch LED off and set also hue and saturation to
0 0x00ffff -> set full brightness, full saturation and set hue
to 0 (red)
I admit I hadn't seen this earlier, and I didn't spend all day
looking at previous attempts, but what's the motivation for
putting all this overloaded syntax into the "brightness" file? I
thought the point was to have a single value in each file, one of
the references I did find was
http://www.spinics.net/lists/linux-leds/msg02995.html Is there
some thread where this was decided as advantageous? Surely 0-255
for _brightness_ is what the brightness entry should do?
I'd like to set the rgb colour of a led (or hsv, that can be it's
own file too) and separately ramp the brightness up and down. I
also think it's substantially simpler and easier to use from the
user's point of view, which is surely the place you want easy
right?