linux-kernel - Re: [PATCH v9 05/15] leds: multicolor: Introduce a multicolor class definition

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: <5e6c2122-1953-c853-fc37-96d26dc59ea9@gmail.com>
Date:   Sat, 28 Sep 2019 20:31:32 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Dan Murphy <dmurphy@...com>, pavel@....cz
Cc:     linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 05/15] leds: multicolor: Introduce a multicolor class
 definition

On 9/28/19 12:09 PM, Jacek Anaszewski wrote:
> Dan,
[...]
>>>
>>>
>>>> +        brightness_val[i] = brightness *
>>>> +                    priv->intensity / priv->max_intensity;
> 
> Now, looking closer at this equation it becomes obvious to me
> why Pavel opted for common max_brightness: in case of
> <color>_intensity == <color>_max_intensity we will get the result
> equal to max_brightness. And this is problematic: think of a case when
> calculated value will be greater than given <color>_max_intensity.
> It will have to be limited the that constraint and will fail to

s/the that/to that/

> produce proper color combination.
> 
> As a solution I see limiting max_brightness to the lowest supported
> brightness from the LEDs in the cluster.

A re-thinking that I withdraw this idea since it will not allow to lit
all LEDs to their max brightness values. Probably we will need just
document that only when all LEDs have the same brightness range the
combined brightness will preserve the hue on the whole its span.

-- 
Best regards,
Jacek Anaszewski