lkml.org 
[lkml]   [2019]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2019-01-04 00:34    [W:0.120 / U:2.224 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site