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

[Jacek Anaszewski <jacek.anaszewski@gmail.com>]

On 1/6/19 4:52 PM, Jacek Anaszewski wrote:
> Hi Pavel,
> 
> On 1/5/19 11:12 PM, Pavel Machek wrote:
>> 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.
> 
> <quote>
> 8.3.1.2 Independent Intensity Control Per RGB LED Module
> 
> When color is fixed, the independent intensity-control is used to
> achieve accurate and flexible dimming control for every RGB LED module.
> 
> 8.3.1.2.1 Intensity-Control Register Configuration
> 
> Every three consecutive output channels are assigned to their respective
> intensity-control register (LEDx_BRIGHTNESS). For example, OUT0, OUT1,
> and OUT2 are assigned to LED0_BRIGHTNESS, so it is recommended to
> connect the RGB LEDs in the sequence as shown in Table 1. The LP50xx
> device allows 256-step intensity control for each RGB LED module, which
> helps achieve a smooth dimming effect.
> </quote>
> 
>> 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.
> 
> TI provides "Various LED Ring Lighting Patterns Reference Design" [0]
> that show how to produce various patterns with use of the reference
> board with LED ring built using sixteen 19-337/R6GHBHC-A01/2T LEDs [1].
> 
> Document [0] mentions also specific "Design considerations" in the
> chapter 2.2:
> 
> <quote>
> Several considerations are taken into account for this particular design:
> • LED map (ring) for meeting the requirement of popular human-machine 
> interaction style.
> • LED size, numbers and the diffuse design for meeting lighting pattern 
> uniformity.
> • Analog dimming in the difference ambient light lux without losing 
> dimming resolution in lighting pattern.
> 
> These considerations apply to most human-machine interaction end 
> equipment with day and night vision
> designs in some way, but the designer must decide the particular 
> considerations to take into account for a
> specific design.
> </quote>
> 
> This renders your requirement 2) infeasible with use of custom LEDs
> any fixed algorithm, since the final effect will always heavily depend

Typo here: s/any fixed/and fixed/

> on the LED circuit design.
> 
>>
>>      2a) LEDs probably slightly change color as they age. That's out of
>>      scope, unless the variation is much greater than on monitors.
>>
>>      2b) Manufacturing differences cause small color variation. Again,
>>      that's out of scope, unless the variation is much greater than on
>>      monitors.
>>
>> Nice to have features:
>>
>> 3) Full range of available colors/intensities should be available to
>> userspace
>>
>> 4) Interface should work well with existing triggers
>>
>> 5) It would be nice if userland knew how many lumens are produced at
>> each wavelength for each setting (again, minus aging and manufacturing
>> variations).
>>
>> 6) Complexity of math in kernel should be low, and preferably it
>> should be integer or fixed point
>>
>> Problems:
>>
>> 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.
>>
>> c) Except for white LEDs, LEDs are basically sources of single
>> wavelength of light, while CRTs and LCDs produce broader
>> spectrums.
>>
>> d) RG, RGBW and probably other LED combinations exist.
>>
>> e) Not all "red" LEDs will produce same wavelength. Similar
>> differences will exist for other colors.
>>
>> f) We have existing RGB LEDs represented as three separate
>> monochromatic LEDs in sysfs.
> 
> One general question: do you have any solutions in store?
> 
> [0] http://www.ti.com/lit/ug/tiduee6/tiduee6.pdf
> [1] http://www.everlight.com/file/ProductFile/19-337-R6GHBHC-A01-2T.pdf
> 

-- 
Best regards,
Jacek Anaszewski