Hi! > >Ok, so: > > > >a) Do we want RGB leds to be handled by existing subsystem, or do we > >need separate layer on top of that? > > > >b) Does RGB make sense, or HSV? RGB is quite widely used in graphics, > >and it is what hardware implements. (But we'd need to do gamma > >correction). > > > >c) My hardware has "acceleration engine", LED is independend from > >CPU. That's rather big deal. Does yours? It seems to be quite common, > >at least in cellphones. > > > >Ideally, I'd like to have "triggers", but different ones. As in: if > >charging, do yellow " .xX" pattern. If fully charged, do green steady > >light. If message is waiting, do blue " x x" pattern. If none of > >above, do slow white blinking. (Plus priorities of events). But that's > >quite different from existing support...) > > Please note that HSV colour scheme allows to neatly project monochrome > brightness semantics on the RGB realm. I.e. you can have fixed > hue and saturation, and by changing the brightness component a perceived > colour intensity can be altered. I see HSV has some advantages. But we already have LEDs with multiple colors, and kernel already handles them: pavel@duo:~$ ls -1 /sys/class/leds/ tpacpi:green:batt tpacpi:orange:batt This is physically 2 leds but hidden under one indicator, so you got "off", "green", "orange" and "green+orange". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
