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: <20190103233425.GA10071@amd>
Date:   Fri, 4 Jan 2019 00:34:25 +0100
From:   Pavel Machek <pavel@....cz>
To:     Vesa Jääskeläinen <dachaac@...il.com>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        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

Hi!

> >Regarding led_scale_color_elements() - I checked it in GIMP and
> >the results are not satisfactory when increasing brightness.
> >Even if we managed to fix it, the result would not be guaranteed
> >to be the same across all devices.
> 
> No and they will never be the same. I was told by our hardware expert that
> it is rather impossible to get linearly behaving LED control without special
> curve fitting trimmed for particular hardware and LED component in use. And
> if you go and change LED component/vendor it would need to be "calibrated"
> again if such accuracy would be required. Also LEDs age and that has also
> effect on this.

Well, it is not possible to "perfectly" calibrate LCD monitors,
either. Yet, color tables make sense for them.

And we should aim for the same thing.

And yes, it may mean re-doing calibration when vendor changes. And it
will mean some math and some understanding of colors.

And... LEDs are linear-enough as it is. That is not a problem. But RGB
does _not_ expect linear response. That's why colors are _way_ off currently.

> >I have another proposal, being a mix of what has been discussed so far:
> >
> >    RGB LED class will expose following files:
> >    a) available by default:
> >      - red, green, blue
> >        Writing any of these file will result in writing corresponding
> >        device register.
> 
> Problem with this is that we are basically back at square one and one cannot
> do "atomic" color change with this.
> 
> In order to set or activate new values one would need "load values" file or
> such that when writing to it would activate new values. However it becomes
> quite clumsy interface at that point as you need to handle multiple writes
> to multiple files and makes those operations rather slow.

If you don't like the interface, create an shared library. It may be
neccessary, anyway, for the color operations.

You say it is "rather slow" to change all 3 colors. How long does it
take, and how long do you need it to take?

> Then we have color presets left that could kinda solve the issue on setting
> the color to fixed values atomically.

Lets not design crazy interface "because sysfs writing is too
slow". Hint: it is not. 
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)