From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Dan Murphy <dmurphy@ti.com>, Pavel Machek <pavel@ucw.cz>
Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, dachaac@gmail.com,
robh+dt@kernel.org
Subject: Re: [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver
Date: Thu, 17 Jan 2019 22:10:51 +0100 [thread overview]
Message-ID: <8dfa2854-2814-6874-ab8e-1858e9a18acf@gmail.com> (raw)
In-Reply-To: <86299268-3202-814a-134b-04bd2170faab@ti.com>
Hi Dan,
On 1/16/19 7:41 PM, Dan Murphy wrote:
> Hello
>
> On 1/16/19 4:55 AM, Pavel Machek wrote:
>> Hi!
>>
>>> On 1/15/19 4:22 PM, Pavel Machek wrote:
>>>> Hi!
>>>>
>>>>>> +The 24-bit RGB value passed in follows the pattern 0xXXRRGGBB
>>>>>> +XX - Do not care ignored by the driver
>>>>>> +RR - is the 8 bit Red LED value
>>>>>> +GG - is the 8 bit Green LED value
>>>>>> +BB - is the 8 bit Blue LED value
>>>>>> +
>>>>>> +Example:
>>>>>> +LED module output 4 of the LP5024 will be a yellow color:
>>>>>> +echo 0xe6de00 > /sys/class/leds/lp5024\:led4_mod/color
>>>>>> +
>>>>>> +LED module output 4 of the LP5024 will be dimmed 50%:
>>>>>> +echo 0x80 > /sys/class/leds/lp5024\:led4_mod/brightness
>>>>>> +
>>>>>> +LED banked RGBs of the LP5036 will be a white color:
>>>>>> +echo 0xffffff > /sys/class/leds/lp5036\:led_banked/color
>>>>>
>>>>> This part with example cans remain in Documentation/leds if you
>>>>>> like.
>>>>
>>>> Does it actually work like that on hardware?
>>>
>>> What?
>>
>> If you do echo 0xffffff > /sys/class/leds/lp5036\:led_banked/color,
>> does it actually produce white? With all the different RGB modules
>> manufacturers can use with lp5024P?
>>
>> If you do echo 0xe6de00 > /sys/class/leds/lp5024\:led4_mod/color, does
>> it actually produce yellow, with all the different RGB modules
>> manufacturers can use with lp5024P?
>>
>
> I believe the answer to the general questions is no for any RGB cluster and driver out there.
> Because if you set the same values on each and every RGB device out there you will get varying shades of the color.
> But for this device yes the color does appear to be yellow to me versus what was displayed on my monitor by the HSL picker.
> But everyone interprets colors differently.
>
> If you write the same value for yellow or white on a droid 4 and the N900 do they produce the same color side by side?
> Most probably not.
>
> As you pointed out the PWM needs to be modified to obtain the correct white color to account for LED and other device constraints.
>
> But we need to take into account the light pipe. Pools nowadays have RGB LED spot lights in them. It can
> be set to white. On my pool right off the lens the color has a purplish hue to it. As the light is diffracted into
> the pool the color becomes white. The pool is clear. When I add chemicals to the pool and make it cloudy
> and turn on the lights the color off the lens is now white. This is an example on a large scale but the issue
> scales down to the hand helds and smart home applications.
>
> If the cluster is piped through a flexible optic 0xffffff may produce the "white" you want on its output.
>
> So an expectation of certain color without proper piping based on a single RGB value may be a little unreasonable.
> There may need to be a way to attenuate the values based on the hardware aspect of the equation ie light pipe (or lack thereof) and LED vendor.
> So if we write 0xffffff to the RGB driver the driver could adjust the intensity of the individual LEDs based on the diffraction
> coefficients.
>
> I also think that is an unreasonable expectation here that writing a single value to any LED RGB driver would produce
> a "rest of the world" absolute color. Maybe it can produce something similar but not identical.
> As you indicated in the requirements there is more involved here then just the LED and the values written.
> The colors should be close but may not be identical.
>
> A 10 year old N900 should not be considered the gold standard for color production due to advancements in LED,
> light pipe and LED driver technology.
> The single package RGB clusters on the board I am testing is about the size of a single RGB LED from 10 years ago.
>
> I agree that the interface developed should work on the device but the algorithm derived to obtain the color needs to have
> a hardware aspect to the calculation.
>
>>>> Is it supposed to support "normal" RGB colors as seen on monitors?
>>>
>>> Monitors are not an application for this part.
>>
>> You did not answer the question. When you talk about yellow, is it
>> same yellow the rest of world talks about?
>>
>
> See above. It is close to what was on my monitor displayed.
>
>>>> Because 100% PWM on all channels does not result in white on hardware
>>>> I have.
>>>
>>> I don't know I am usually blinded by the light and have no diffuser over
>>> the LEDs to disperse the light so when I look I see all 3 colors.
>>
>> How can we have useful discussion about colors when you don't see the
>> colors?
>>
>> Place a piece of paper over the LEDs....
>>
>
> Good suggestion for a rough test.
>
>>>> But...
>>>>
>>>> I believe we should have a reasonable design before we do something
>>>> like this. There's no guarantee someone will not use lp50xx with just
>>>> the white LEDs for example. How will this work? Plus existing hardware
>>>> already uses three separate LEDs for RGB LED. Why not provide same
>>>> interface?
>>>
>>> Which existing hardware? Are they using this part?
>>
>> Nokia N900. They are not using this part, but any interface we invent
>> should work there, too.
>>
>
> Yes a common interface would be nice with some sort of hardware tuning coefficient.
>
>>> <rant>
>>> Why are we delaying getting the RGB framework or HSV in?
>>> I would rather design against something you want instead of having
>>> everyone complain about every implementation I post.
>>> </rant>
>>
>> Because you insist on creating new kernel interfaces, when existing
>> interfaces work, and are doing that badly.
>>
>> Because your patches are of lower quality than is acceptable for linux
>> kernel.
>>
>> Because you don't seem to be reading the emails.
>>
>> I sent list of requirements for RGB led support. This does not meet
>> them.
>>
>
> Sigh. You did not answer my question.
>
> Your requirements seem to be centered around monitors but that is only one application of the current
> RGB LED landscape.
>
> I am willing to work with you on the HSV and adapting the LP50xx part to this framework.
> Or any RGB framework for that matter. I still don't agree with the kernel needing to declare colors
> maybe color capabilities but not specific colors.
Dan, if you have a bandwidth for LED RGB class implementation
then please go ahead. It would be good to compare colors produced
by software HSV->RGB algorithm to what can be achieved with
LEDn_BRIGHTNESS feature.
The requirements for LED RGB class as I would see it:
sysfs interface:
brightness-model: space separated list of available options:
- rgb (default):
- creates color file with "red green blue" decimal values
- creates brightness file
a) for devices with hardware support for adjusting color
intensity it maps to corresponding register
b) for the rest writing any value greater than 0 will result
in setting all color registers to max
- hsv:
- creates color file with "h s v" values - it shall
use software HSV->RGB algorithm for setting color registers
- any other custom color ranges defined in DT, but it can be covered
later
- other options?
Best regards,
Jacek Anaszewski
> It was agreed to continue forward with this particular implementation.
> At least thats what the email (I apparently did not read) stated.
>
> I need to fix the code to use the space separated value as pointed out and shown by Vesa.
> This will map nicely into this device with the color file as what I implemented is in theory
> they same code except for the space separated values.
>
>>> It is not a normal RGB driver. The device collates the individual RGB
>>> clusters into a single brightness register and you can modify the intensity of the individual
>>> LEDs via other registers. If brightness is 0 then the cluster is OFF regardless of the color
>>> set in the individual registers.
>>
>> I understand that. So just set cluster brightness to 255 and you have
>> normal RGB driver you can control with existing interfaces. You don't
>> have to use every feature your hardware has.
>>
>
> The brightness file is available and adjusts the brightness of the RGB cluster.
> I am not attempting to implement every feature the device has. But I am attempting to use
> the basic features that are available and useful.
>
>> You did not answer the "what if someone uses this with all white LEDs"
>> question.
>>
>
> Are you asking what if someone places a white LED instead of a RGB on the hardware?
> Well then they need to go back and have a review of the data sheet and what they are trying to
> achieve. That would be a misapplication of the LED driver itself and something software cannot fix.
>
> But if they do determine they want to control these white LEDs with this device
> then they can ignore the "color" file and control the cluster via the brightness file like we
> do today. The color file will only change the intensity of the single output (assuming LED module mode)
> or the banked output.
>
> If a user wants to place a RGB cluster down on the hardware and have white as the consistent color
> well then that is fine as the RGB outputs are all set to 0xff and the intensity of the cluster is
> controlled by the brightness file. If they cannot achieve the "white" with the default settings then
> on init they can set the color file once to obtain the "white" color and continue to use the brightness
> file to control the overall brightness of the cluster.
>
> It was determined in the email chain not to expose a brightness file per output as this device
> does not lend itself to that convention.
>
>> You know what? First, submit driver with similar functionality to
>> existing RGB drivers, using same interface existing drivers are
>> using. When that is accepted, we can talk about extending
>> kernel<->user interfaces.
>>
>
> I could do that but then there is no way for users to have any other color but "white" with this driver.
> That defeats the purpose of the device itself.
>
> This is why I would rather align the interfaces with what is being proposed so the interfaces won't change only
> the engine underneath will.
>
> I am not sure if you are aware of this or care but I found this recent blog on this effort:
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-RGB-LED-Interface
> See some of the comments.
>
> Dan
>
>> Thanks,
>> Pavel
>>
>
>
next prev parent reply other threads:[~2019-01-17 21:10 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 21:17 [PATCH v2 1/2] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2019-01-14 21:17 ` [PATCH v2 2/2] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2019-01-15 21:47 ` Jacek Anaszewski
2019-01-15 22:22 ` Pavel Machek
2019-01-16 0:20 ` Dan Murphy
2019-01-16 10:55 ` Pavel Machek
2019-01-16 18:41 ` Dan Murphy
2019-01-16 22:04 ` Pavel Machek
2019-01-16 23:33 ` Dan Murphy
2019-01-17 10:06 ` Pavel Machek
2019-01-17 13:27 ` Dan Murphy
2019-01-17 21:10 ` Jacek Anaszewski [this message]
2019-01-18 0:02 ` RGB LED class " Pavel Machek
2019-01-18 15:57 ` Dan Murphy
2019-01-28 23:03 ` Pavel Machek
2019-01-18 22:13 ` Jacek Anaszewski
2019-01-19 21:36 ` Pavel Machek
2019-01-20 15:30 ` Jacek Anaszewski
2019-01-21 19:38 ` Jacek Anaszewski
2019-01-28 23:04 ` Pavel Machek
2019-01-18 13:45 ` Dan Murphy
2019-01-18 13:58 ` Dan Murphy
2019-01-20 6:42 ` Vesa Jääskeläinen
2019-01-22 21:39 ` Jacek Anaszewski
2019-01-22 22:44 ` Dan Murphy
2019-01-23 21:52 ` Jacek Anaszewski
2019-01-24 21:00 ` Dan Murphy
2019-01-24 21:55 ` Jacek Anaszewski
2019-01-29 13:56 ` Dan Murphy
2019-01-29 20:19 ` Jacek Anaszewski
2019-01-29 20:26 ` Dan Murphy
2019-01-29 21:45 ` Pavel Machek
2019-01-29 21:46 ` Dan Murphy
2019-01-29 21:53 ` Jacek Anaszewski
2019-01-20 15:32 ` Jacek Anaszewski
2019-01-17 21:08 ` Jacek Anaszewski
2019-01-19 19:11 ` Vesa Jääskeläinen
2019-01-19 21:46 ` Pavel Machek
2019-01-19 22:44 ` Vesa Jääskeläinen
2019-01-20 6:51 ` Vesa Jääskeläinen
2019-01-21 13:27 ` Dan Murphy
2019-01-21 15:12 ` Vesa Jääskeläinen
2019-01-24 20:32 ` Dan Murphy
2019-01-24 21:14 ` Jacek Anaszewski
2019-01-15 21:42 ` [PATCH v2 1/2] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Jacek Anaszewski
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=8dfa2854-2814-6874-ab8e-1858e9a18acf@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=dachaac@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
/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).