Jacek On 1/7/19 1:13 PM, Jacek Anaszewski wrote: > 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 >> > I just wanted to point out that there are 4 total devices right now that use the same mapping LP5018, LP5024, LP5030 and the LP5036. I can implement what ever we would like to I just need to know what to design against. But keep in mind I still need to invest my time in the other TI-lmu patches on my list to complete. Dan -- ------------------ Dan Murphy
