[lkml]   [2019]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
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>
> 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.
> 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]
> [1]

Best regards,
Jacek Anaszewski

 \ /
  Last update: 2019-01-07 20:14    [W:0.090 / U:7.796 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site