RE: multicolor virtual color LED driver.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>I don't believe adding virtual LEDs for this is a good idea.
>
>What about:
>
>1) introduce infrastructure for triggers to work with color, too.
>
>2) introduce "colorful" trigger that accepts three monochromatic triggers and combines them in a way you desire?
>
So you mean say 8 independent triggers for a single multiclor LED? 
E.g: R,G,B,Yel,CY,MA under the same RGB element?.

I guess that would work but we still have the priority/ logic issue it would get confusing to implement that way.

I was planning to add a priority via the device tree but thinking about more exporting it via sysfs might be more appropriate, one could implement debug level to hide trivial led triggers this way too.
E.g:

"echo 1 sys/class/leds/system_led:yellow/priority".
"echo 2 sys/class/leds/system_led:cyan/priority".
"echo 2 sys/class/leds/system_led:cyan/debug_level".

>> Also, of note On color wheels of the RGB (additive) and CMY (subtractive) color model's magenta is a standard reference color but is not an >>available color ID in leds/common.h not so much an issue just a note and I don't know if such an addition of this color would be a good idea?

>That would be "violet". Feel free to add a comment that it is magenta or something.

Violet and Magenta are different colors, Magenta would be a new color to add it is one of the primary and secondary colours depending on the color model one uses, in this context it does not really matter so much but adding it in would comply with standards of definitions of color.





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux