Messages in this thread | | | Subject | Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver | From | Jacek Anaszewski <> | Date | Fri, 4 Jan 2019 22:37:58 +0100 |
| |
On 1/4/19 9:12 PM, Pavel Machek wrote: > Hi! > >>> I suppose if one would just make it an array of values (separated by >>> space) and then one file with string array of color element names and on >>> file with maximum value array it could be within those words. >>> >>> The it would be something like: >>> >>> $ echo "23 54 32" > color >> >> Go ahead, but first convince Pavel, and then Greg :-) >> >> I'd personally would not have much against, especially that the >> list of values will not grow for that one like in case of old patch set >> [0] where Pavel and Greg thwarted my similar attempt. > > Oh, you can get this past Pavel (and probably Greg) -- if you have a > good reason. Performance is _not_ a good reason. You don't need to > change LED color 50000 times a second.
We would need to do some profiling here to check if the problem exists.
But, aside from that hypothetic issue, we need a solution for LEDn_BRIGHTNESS feature of lp5024, i.e. setting color intensity via a single register write. How would you propose to address that?
> If you can demonstrate a reasonable design, where user selects color > from well-known RGB pallete and either kernel or library+kernel acts > to set that color on the LED, we can talk. > > When user asks for white, it has to be white. Exact color temperature > does not matter. When user asks for pink, it has to be pink. Again, > exact color does not matter; different monitors display slightly > different colors, too -- Best regards, Jacek Anaszewski
| |