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] https://lkml.org/lkml/2017/8/31/255 > > > >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 >with. 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 ( https://en.wikipedia.org/wiki/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. Anyway, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
