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
Attachment:
signature.asc
Description: Digital signature
