linux-kernel - Re: RGB LED class Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9d2e0220-69f0-faaa-adb9-13d905f9c51d@gmail.com>
Date:   Sun, 20 Jan 2019 16:30:36 +0100
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Dan Murphy <dmurphy@...com>, linux-leds@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        dachaac@...il.com, robh+dt@...nel.org
Subject: Re: RGB LED class Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX
 family of the RGB LED driver

On 1/19/19 10:36 PM, Pavel Machek wrote:
> Hi!
> 
>>> First, I think we want to decide if RGB LED should be presented as
>>> 3 LEDs or as 1 LED... and what to do with existing RGB leds being
>>> presented as 3 LEDs.
>>>
>>> I don't think we want to support both RGB and HSV in the kernel. It is
>>> math, and not a nice one.
>>>
>>> Yes, both have advantages and disadvantages, but having _both_ in
>>> kernel has disadvantages of both.
>>>
>>> One way I could imagine the interface:
>>>
>>>      RGB LED presented as one LED.
>>>
>>>      brightness -- controls brightness of whole RGB module.
>>
>> What algorithm would be used for mapping brightness levels to RGB values
>> in case of devices without hardware support for that?
> 
> Output power = brightness / max_brightness * pwm_channel[x].

IIUC you mean it as a formula for calculating r,g,b, values?
I.e., on brightness setting we would have to do this calculation for
each of three channels?

Then, it will result in changing hue as well. That's why we're
discussing HSV.

>>>      pwm_channels -- "1000 240 300" -- "red part should be full on, green
>>>      should be pwm controlled to 240/1000, blue should be 300/1000"
>>>
>>>      pwm_white -- "1000 500 400" -- tells userspace what to write to PWM
>>>      channels to get approximately white color.
>>>
>>>      This would assume that RGB LEDs are always pwm controlled. That
>>>      seems to be true for hardware I seen.
>>
>> Why pwm in the file names? I don't see any gain and only possible
>> problems. Many LED controllers use current level and not PWM
>> for driving LEDs.
> 
> I want to make sure userspace understands this has linear relation to
> output power. I'd like to avoid mentioning color because there power
> output is not linear with "RGB"
> 
>> s/pwm/color/
> 
> s/pwm/power/ would work for me.

Power implies physical units. I'd prefer "intensity".

>> Besides white also other color presets could be defined in DT.
> 
> They should not be neccessary. When userspace knows what is white and
> that power is linear with values in power_channels, it should be able
> to do colorspace conversion itself.

Have you verified it in practice? Would it allow to convert RGB values
of the color displayed on the monitor to LED RGB class intensities,
allowing to achieve similar color on the LED?

-- 
Best regards,
Jacek Anaszewski