From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Dan Murphy <dmurphy@ti.com>, pavel@ucw.cz
Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 05/15] leds: multicolor: Introduce a multicolor class definition
Date: Sat, 28 Sep 2019 20:31:32 +0200 [thread overview]
Message-ID: <5e6c2122-1953-c853-fc37-96d26dc59ea9@gmail.com> (raw)
In-Reply-To: <03deb117-4bd4-b636-cbc9-4634afc73e78@gmail.com>
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
next prev parent reply other threads:[~2019-09-28 18:31 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 17:46 [PATCH v9 00/15] Multicolor Framework Dan Murphy
2019-09-25 17:46 ` [PATCH v9 01/15] leds: multicolor: Add sysfs interface definition Dan Murphy
2019-09-25 20:58 ` Jacek Anaszewski
2019-09-26 11:10 ` Pavel Machek
2019-09-26 12:08 ` Dan Murphy
2019-09-25 17:46 ` [PATCH v9 02/15] dt: bindings: Add multicolor class dt bindings documention Dan Murphy
2019-09-25 17:46 ` [PATCH v9 03/15] dt-bindings: leds: Add multicolor ID to the color ID list Dan Murphy
2019-09-25 17:46 ` [PATCH v9 04/15] " Dan Murphy
2019-09-25 17:46 ` [PATCH v9 05/15] leds: multicolor: Introduce a multicolor class definition Dan Murphy
2019-09-25 21:12 ` Jacek Anaszewski
2019-09-26 11:52 ` Dan Murphy
2019-09-28 10:09 ` Jacek Anaszewski
2019-09-28 18:31 ` Jacek Anaszewski [this message]
2019-09-25 17:46 ` [PATCH v9 06/15] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2019-09-25 17:46 ` [PATCH v9 07/15] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2019-09-25 21:27 ` Jacek Anaszewski
2019-09-26 11:59 ` Dan Murphy
2019-09-28 10:29 ` Jacek Anaszewski
2019-09-25 17:46 ` [PATCH v9 08/15] dt: bindings: lp55xx: Be consistent in the document with LED Dan Murphy
2019-09-25 21:31 ` Jacek Anaszewski
2019-09-26 12:00 ` Dan Murphy
2019-09-25 17:46 ` [PATCH v9 09/15] dt: bindings: lp55xx: Update binding for Multicolor Framework Dan Murphy
2019-09-25 21:34 ` Jacek Anaszewski
2019-09-26 12:00 ` Dan Murphy
2019-09-25 17:46 ` [PATCH v9 10/15] ARM: dts: n900: Add reg property to the LP5523 channel node Dan Murphy
2019-09-25 17:46 ` [PATCH v9 11/15] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 " Dan Murphy
2019-09-25 18:00 ` Fabio Estevam
2019-09-25 18:16 ` Dan Murphy
2019-09-25 17:46 ` [PATCH v9 12/15] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes Dan Murphy
2019-10-04 21:30 ` Linus Walleij
2019-09-25 17:46 ` [PATCH v9 13/15] leds: lp55xx: Update the lp55xx to use the multi color framework Dan Murphy
2019-09-25 22:00 ` Jacek Anaszewski
2019-09-26 12:02 ` Dan Murphy
2019-09-29 13:01 ` Jacek Anaszewski
2019-09-30 16:31 ` Dan Murphy
2019-09-30 20:34 ` Dan Murphy
2019-09-25 17:46 ` [PATCH v9 14/15] leds: lp55xx: Fix checkpatch file permissions issues Dan Murphy
2019-09-25 17:46 ` [PATCH v9 15/15] leds: lp5523: Fix checkpatch issues in the code Dan Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e6c2122-1953-c853-fc37-96d26dc59ea9@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=dmurphy@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).