linux-kernel - Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 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: <4b5a89ed-0c0b-3103-ca57-a0f97aa5ace9@gmail.com>
Date:   Sun, 30 Dec 2018 18:09:35 +0100
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Dan Murphy <dmurphy@...com>, robh+dt@...nel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-leds@...r.kernel.org
Subject: Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

On 12/29/18 8:07 PM, Pavel Machek wrote:
> Hi!
> 
>>>> With the "color" sysfs file it will make more sense to allow for user
>>>> defined color palettes.
>>>>
>>>
>>> I think defining these values in the device tree or acpi severely limits the devices
>>> capabilities.  Especially in development phases.  If the knobs were exposed then the user space
>>> can create new experiences.  The color definition should be an absolute color defined in the dt and
>>> either the framework or user space needs to mix these appropriately.  IMO user space should set the policy
>>> of the user experience and the dt/acpi needs to set the capabilities.
>>>
>>> I do like Pavels idea on defining the more standard binding pattern to "group" leds into a single group.
>>>
>>> Maybe the framework could take these groups and combine/group them into a single node with the groups colors.
>>
>> There is still HSV approach [0] in store. One problem with proposed
>> implementation is fixed algorithm of RGB <-> HSV color space conversion.
>> Maybe allowing for some board specific adjustments in DT would add
>> more flexibility.
>>
>> [0] https://lkml.org/lkml/2017/8/31/255
> 
> Yes we could do HSV. Problem is that that we do not really have RGB
> available. We do have integers for red, green and blue, but they do
> not correspond to RGB colorspace.

OK, so conversion from HSV to RGB would only increase the aberration.
So, let's stick to RGB - we've got to have some stable ground and this
is something that the hardware at least pretends to be compliant with.

Our problem is how to set the color atomically. With HSV approach we
were to obviate the problem by mapping brightness file to the "V"
component of that color space, and write all H,S and V values to the
hardware only on write to brightness file.

We could apply similar approach in case of RGB LED class device.
We would have four files instead of a single brightness file:
red, green, blue and main_color. First three would accept values
within 0-255 range, and main_color would accept one of
"red", "green" or "blue". LED RGB class driver would write all
color components to the hardware only on write to the file corresponding
to the main_color. Also LED Trigger core would be taught to map
brightness value to the main_color for RGB LEDs.

Of course a new internal kernel API for setting color would
have to be provided for use by dedicated RGB triggers.

-- 
Best regards,
Jacek Anaszewski