On Sun, 16 Jul 2023 11:19:30 +0200 Pavel Machek <pavel@xxxxxx> wrote: > Hi! > > > Using binary brightness makes more sense for this controller, because > > internally in the MCU it works that way: the LED has a color, and a > > state whether it is ON or OFF. > > So, controller can do (1, 3, 5) but not (3, 3, 3)? > > > The resulting brightness computation with led_mc_calc_color_components() > > will now always result in either (0, 0, 0) or the multi_intensity value. > > Won't that limit you to 8 colors total? > > I guess I`m confused how this hw works... Hi Pavel. No no no. That's not how it is. The HW exposes color control for three channels (RGB), each channel with range 0-255 (so 16M colors). The driver exposes this via the multi_intensity sysfs file. This is communicated to the HW via LED_SET_COLOR I2C command. HW also exposes setting the LED ON and OFF, via the LED_SET_STATE I2C command. We currently have the following sysfs files via which we set LED state and color: brightness multi_intensity Because currently the driver sets max_brightness to 255, the actual color that is sent to HW is recalculated via led_mc_calc_color_components(). For example with $ echo 255 255 100 >multi_intensity $ echo 150 >brightness the led_mc_calc_color_components() function recalculates the channel intensities with formula brightness * channel_intensity / max_brightness and so the (255, 255, 100) tuple is converted to (150, 150, 58) before sending to HW. What I think would make more sense is to make the two sysfs files brightness multi_intensity correspond 1-to-1 with I2C commands LED_SET_STATE and LED_SET_COLOR. This can be simply done by setting max_brightness to 1. The brightness sysfs file then can simply control whether the LED is ON or OFF. The multi_intensity file control the color. I realize now that in the patch I should also make away with the call to led_mc_calc_color_components()... Marek
