Hi! > >First, I think we want to decide if RGB LED should be presented as > >3 LEDs or as 1 LED... and what to do with existing RGB leds being > >presented as 3 LEDs. > > > >I don't think we want to support both RGB and HSV in the kernel. It is > >math, and not a nice one. > > > >Yes, both have advantages and disadvantages, but having _both_ in > >kernel has disadvantages of both. > > > >One way I could imagine the interface: > > > > RGB LED presented as one LED. > > > > brightness -- controls brightness of whole RGB module. > > What algorithm would be used for mapping brightness levels to RGB values > in case of devices without hardware support for that? Output power = brightness / max_brightness * pwm_channel[x]. > > pwm_channels -- "1000 240 300" -- "red part should be full on, green > > should be pwm controlled to 240/1000, blue should be 300/1000" > > > > pwm_white -- "1000 500 400" -- tells userspace what to write to PWM > > channels to get approximately white color. > > > > This would assume that RGB LEDs are always pwm controlled. That > > seems to be true for hardware I seen. > > Why pwm in the file names? I don't see any gain and only possible > problems. Many LED controllers use current level and not PWM > for driving LEDs. I want to make sure userspace understands this has linear relation to output power. I'd like to avoid mentioning color because there power output is not linear with "RGB" > s/pwm/color/ s/pwm/power/ would work for me. > Besides white also other color presets could be defined in DT. They should not be neccessary. When userspace knows what is white and that power is linear with values in power_channels, it should be able to do colorspace conversion itself. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
