Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Hi Vesa, On 1/9/19 8:11 AM, Vesa Jääskeläinen wrote: Hi Pavel, On 09/01/2019 0.59, 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. 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. I was thinking about this calibration and color correctness thing and I am thinking a bit that it should be partly in kernel and partly in user space. For displays and printers there are defined icc-profiles that define how colors are mapped to particular device in cases when you want to have accurate color representation. In theory to get accurate LED output one could model LEDs with icc profile and then pick your color and convert it with icc profile to actual raw hardware values. Then this raw hardware value could be written from user space to kernel. icc-profiles idea sounds interesting. We would have to adjust hsv->rgb algorithm to take the profiles into account. I wonder how that would work in practice. In kernel we could provide raw hardware value support and in case of PWM IC controlled LEDs we could provide curve mapping to linearize the behavior of values entered to enable use in cases where close enough is good enough. Eg. if you want to have "white" then you have your color space picker like sRGB(255,255,255). Then you would define icc profile it might translate to hardware raw values 253%, 230%, 225%. Then you would write this to kernel with: # set red, green and blue color elements echo "253 230 225" > color In this case however behavior of brightness node is challening in accuracy domain. Britghtness value 255 would of course provide 1:1 mapping in this case. To go right to correct color and brightness at one go we could have optional brightness at the end of color value array: # set red, green and blue color element and brightness
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
On 1/10/19 3:02 PM, Jacek Anaszewski wrote: > On 1/10/19 8:58 PM, Dan Murphy wrote: >> On 1/10/19 1:23 PM, Jacek Anaszewski wrote: >>> Dan, >>> >>> On 1/10/19 1:46 PM, Dan Murphy wrote: Jacek On 1/8/19 3:25 PM, Dan Murphy wrote: > Jacek > > On 1/8/19 3:18 PM, Jacek Anaszewski wrote: >> Hi Dan, >> >> On 1/7/19 10:14 PM, Dan Murphy wrote: >>> Jacek >>> >>> On 1/7/19 2:59 PM, Jacek Anaszewski wrote: Dan, On 1/7/19 8:36 PM, Dan Murphy wrote: > 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. >>> >>> >>> 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. >>> >>> 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: >>> >>> >>> 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. >>> >>>
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
On 1/10/19 8:58 PM, Dan Murphy wrote: On 1/10/19 1:23 PM, Jacek Anaszewski wrote: Dan, On 1/10/19 1:46 PM, Dan Murphy wrote: Jacek On 1/8/19 3:25 PM, Dan Murphy wrote: Jacek On 1/8/19 3:18 PM, Jacek Anaszewski wrote: Hi Dan, On 1/7/19 10:14 PM, Dan Murphy wrote: Jacek On 1/7/19 2:59 PM, Jacek Anaszewski wrote: Dan, On 1/7/19 8:36 PM, Dan Murphy wrote: 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. 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. 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: 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. 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
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
On 1/10/19 1:23 PM, Jacek Anaszewski wrote: > Dan, > > On 1/10/19 1:46 PM, Dan Murphy wrote: >> Jacek >> >> On 1/8/19 3:25 PM, Dan Murphy wrote: >>> Jacek >>> >>> On 1/8/19 3:18 PM, Jacek Anaszewski wrote: Hi Dan, On 1/7/19 10:14 PM, Dan Murphy wrote: > Jacek > > On 1/7/19 2:59 PM, Jacek Anaszewski wrote: >> Dan, >> >> On 1/7/19 8:36 PM, Dan Murphy wrote: >>> 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. > > > 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. > > >> 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: > > > 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. > > > 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
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Dan, On 1/10/19 1:46 PM, Dan Murphy wrote: Jacek On 1/8/19 3:25 PM, Dan Murphy wrote: Jacek On 1/8/19 3:18 PM, Jacek Anaszewski wrote: Hi Dan, On 1/7/19 10:14 PM, Dan Murphy wrote: Jacek On 1/7/19 2:59 PM, Jacek Anaszewski wrote: Dan, On 1/7/19 8:36 PM, Dan Murphy wrote: 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. 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. 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: 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. 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
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Jacek On 1/8/19 3:25 PM, Dan Murphy wrote: > Jacek > > On 1/8/19 3:18 PM, Jacek Anaszewski wrote: >> Hi Dan, >> >> On 1/7/19 10:14 PM, Dan Murphy wrote: >>> Jacek >>> >>> On 1/7/19 2:59 PM, Jacek Anaszewski wrote: Dan, On 1/7/19 8:36 PM, Dan Murphy wrote: > 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. >>> >>> >>> 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. >>> >>> 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: >>> >>> >>> 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. >>> >>> >>> 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)
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Hi Pavel, On 09/01/2019 0.59, 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. 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. I was thinking about this calibration and color correctness thing and I am thinking a bit that it should be partly in kernel and partly in user space. For displays and printers there are defined icc-profiles that define how colors are mapped to particular device in cases when you want to have accurate color representation. In theory to get accurate LED output one could model LEDs with icc profile and then pick your color and convert it with icc profile to actual raw hardware values. Then this raw hardware value could be written from user space to kernel. In kernel we could provide raw hardware value support and in case of PWM IC controlled LEDs we could provide curve mapping to linearize the behavior of values entered to enable use in cases where close enough is good enough. Eg. if you want to have "white" then you have your color space picker like sRGB(255,255,255). Then you would define icc profile it might translate to hardware raw values 253%, 230%, 225%. Then you would write this to kernel with: # set red, green and blue color elements echo "253 230 225" > color In this case however behavior of brightness node is challening in accuracy domain. Britghtness value 255 would of course provide 1:1 mapping in this case. To go right to correct color and brightness at one go we could have optional brightness at the end of color value array: # set red, green and blue color element and brightness setting: echo "253 230 225 255" > color If you want to have fancier behavior for brightness in your system then we probably need to have configurable brightness model. - hardware, like in lp5024 case would map to
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
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 signature.asc Description: Digital signature
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Jacek On 1/8/19 3:18 PM, Jacek Anaszewski wrote: > Hi Dan, > > On 1/7/19 10:14 PM, Dan Murphy wrote: >> Jacek >> >> On 1/7/19 2:59 PM, Jacek Anaszewski wrote: >>> Dan, >>> >>> On 1/7/19 8:36 PM, Dan Murphy wrote: 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. >> >> >> 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. >> >> >>> 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: >> >> >> 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. >> >> >> 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
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Hi Dan, On 1/7/19 10:14 PM, Dan Murphy wrote: Jacek On 1/7/19 2:59 PM, Jacek Anaszewski wrote: Dan, On 1/7/19 8:36 PM, Dan Murphy wrote: 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. 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. 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: 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. 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)
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Jacek On 1/7/19 2:59 PM, Jacek Anaszewski wrote: > Dan, > > On 1/7/19 8:36 PM, Dan Murphy wrote: >> 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. 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. > 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: 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. 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 >
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Dan, On 1/7/19 8:36 PM, Dan Murphy wrote: 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. 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. 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: 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. 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.
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
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. >> >> >> 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. >> >> >>> 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: >> >> >> 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. >> >> >> 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
Re: 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. 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. 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: 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. 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
Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
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. 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. 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: 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. 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. 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
Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
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? 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 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. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
