Hi! > I believe major difference between the models is how one changes individual > color elements. > > In Dan's model you have own sysfs node for each indivudal color element > (red/brightness, green/brightness, ...) and in Vesa's you have one sysfs > node (color) that is used to update all color elements in one go. > > In addition Dan's model have configurable synchronization/atomic change > configuration sysfs node and mechanism. I like your version more. > *** > > Pavel's point of needing to have ability to change color to "white" could be > done with either model. > > With Dan's model we would have user space writing the values to the kernel > sysfs nodes but it requires to have some device specific translation table > (could be ICC type of profile) from "white" to individual values. > > With Vesa's model same ICC profile model could still be used. Model for > color could be extended to also support color mapping table in devicetree > then symbolic name could be written to "color" node (eg. echo white > color) > but that would require preregistration for colors in devicetree. No. If we decide to do color conversions in kernel, we should do it for all colors, not just for selected list. Color conversion in kernel is doable, but will likely mean that full set of possible colors/brightnesses will not be available, as I explained elsewhere. > Vesa proposed approach for linearity mapping problem to use ramp tables > defined in devicetree similar to what is used with LCD backlight driver. I > believe this could work with both Dan's and Vesa's model. Lets not do that. Replacing computation with table is not really improvement, as it a) costs us memory, b) will be less precise, c) people will not get the tables right, as they will be hard to measure. > I would like to keep user thinking about LED's color elements in linear mode > in user space interface point of view. So that there would be read values > ranging from 0 .. 255. This would make it easier for user to understand what > is happening. I don't like to see that user needs to think in model that > they are not common with (RGB and HSV/HSL I could categorize as known > models). Eg. I do not want to see that they need to think in raw PWM values > (->ramp table could solve this). We should really make it simple to implement in kernel.. and user space can adapt. Yes, it probably means we should do shared library to make it easy for "user". 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
