Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 3669 bytes --]

Hi!

> >>>Grab yourself an RGB LED and play with it; you'll see what the
> >>>problems are. It is hard to explain colors over email...
> >>
> >>Video [0] gives some overview of lp5024 capabilities.
> >>
> >>I don't see any problems in exposing separate red,green,blue
> >>files and brightness for the devices with hardware support for
> >>that.
> >
> >Well, that's what we do today, as three separate LEDs, right?
> 
> No. It doesn't allow for setting color intensity by having
> the color fixed beforehand. Below is relevant excerpt from
> the lp5024 documentation. This is not something that can be
> mapped to RGB color space, but rather to HSV/HSL, with the
> reservation that the hardware implementation uses PWM
> for setting color intensity.

So they have feature where they have independent controls for each
channel, then one common control per three channels. Other chips have
common control for all the LEDs, for example. We don't support that
currently; lets focus on the RGB thing first.

> >I don't have problem with that, either; other drivers already do
> >that. He's free to use existing same interface.
> >
> >But that is insufficient, as it does not allow simple stuff, such as
> >turning led "white".
> >
> >So... perhaps we should agree on requirements, first, and then we can
> >discuss solutions?
> >
> >Requirements for RGB LED interface:
> >
> >1) Userspace should be able to set the white color
> >
> >2) Userspace should be able to arbitrary color from well known list
> >and it should approximately match what would CRT, LCD or OLED monitor display
> 
> The difference is that monitor display driver is pre-calibrated
> for given display by the manufacturer. With the LED controllers the
> manufacturer has no control over what LEDs will be connected to the
> iouts. Therefore it should be not surprising that colors produced
> by custom LEDs are not as user would expect when comparing to
> the RGB color displayed on the monitor display.

It is true that _chip_ manufacturer can not know what LEDs will be
connected. But _system_ manufacturer can and should know that, and
should tell be able to tell us in the dts.

> This renders your requirement 2) infeasible with use of custom LEDs
> any fixed algorithm, since the final effect will always heavily depend
> on the LED circuit design.

Depending on LED circuit design and actual LEDs connected is okay.. we
just need to get information from _system_ designer (not chip
designer), and pass it to a place where color is computed.

> >a) RGB LEDs are usually not balanced. Setting 100% PWM on
> >red/green/blue channels will result in nothing close to white
> >light. In fact, to get white light on N900, blue and green channel's
> >PWM needs to be set pretty low, as in 5%.
> >
> >b) LED class does not define any relation between "brightness" in
> >sysfs and ammount of light in lumens. Some drivers use close to linear
> >relation, some use exponential relation. Human eyes percieve logarithm
> >of lumens. RGB color model uses even more complex function.
> 
> One general question: do you have any solutions in store?

I played with LEDs on N900 over the weekend, yes.

And getting reasonable colors seems to be possible, when a) and b) are
solved... a) seems to be more important than b).

Now... this does not tell us how we should design kernel<->user
interface, but it should tell us that main goals - 1) and 2) are
possible.

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]