[lkml]   [2018]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
On Sun 2018-12-30 18:09:35, Jacek Anaszewski wrote:
> On 12/29/18 8:07 PM, Pavel Machek wrote:
> >Hi!
> >
> >>>>With the "color" sysfs file it will make more sense to allow for user
> >>>>defined color palettes.
> >>>>
> >>>
> >>>I think defining these values in the device tree or acpi severely limits the devices
> >>>capabilities. Especially in development phases. If the knobs were exposed then the user space
> >>>can create new experiences. The color definition should be an absolute color defined in the dt and
> >>>either the framework or user space needs to mix these appropriately. IMO user space should set the policy
> >>>of the user experience and the dt/acpi needs to set the capabilities.
> >>>
> >>>I do like Pavels idea on defining the more standard binding pattern to "group" leds into a single group.
> >>>
> >>>Maybe the framework could take these groups and combine/group them into a single node with the groups colors.
> >>
> >>There is still HSV approach [0] in store. One problem with proposed
> >>implementation is fixed algorithm of RGB <-> HSV color space conversion.
> >>Maybe allowing for some board specific adjustments in DT would add
> >>more flexibility.
> >>
> >>[0]
> >
> >Yes we could do HSV. Problem is that that we do not really have RGB
> >available. We do have integers for red, green and blue, but they do
> >not correspond to RGB colorspace.
> OK, so conversion from HSV to RGB would only increase the aberration.
> So, let's stick to RGB - we've got to have some stable ground and this
> is something that the hardware at least pretends to be compliant

I'm not saying that we should stick to RGB. I'm just saying that
problem is complex.

And no, hardware does not even pretend to be compliant with RGB color
model ( ). In
particular, in RGB there is non-linear brightness curve.

> Our problem is how to set the color atomically. With HSV approach we
> were to obviate the problem by mapping brightness file to the "V"
> component of that color space, and write all H,S and V values to the
> hardware only on write to brightness file.

I'm not sure how realistic the "atomic color" problem is. Computers
are way faster than human vision.

I believe problem to start with is the "white" problem. Setting
R=G=B=255 will _not_ result in anything close to white light on
hardware I have.


(cesky, pictures)
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2018-12-30 18:36    [W:0.093 / U:1.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site