Messages in this thread | | | Subject | Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver | From | Jacek Anaszewski <> | Date | Mon, 7 Jan 2019 20:13:43 +0100 |
| |
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
| |