[UPSTREAM] Move backlight handling out of pcf50633 driver
werner at openmoko.org
Mon Oct 20 00:13:34 CEST 2008
Sean McNeil wrote:
> Can you make the max brightness a #define where it can be an arbitrary
> value such as 100 or 255?
Hmm, it does seem a little gratuituous, though.
Let's see what happens to code if you make that change:
- code that already reads max and scales accordingly:
keeps on working
- code that "knows" the max value and scales accordingly:
keeps on working
- code that assumes an incorrect max value and scales accordingly:
it never worked correctly, but it can now be fixed via the kernel
The kernel already exposes all the information you need to use the
With Andy's suggestion to also change the default max value, things
get worse, because this also breaks code that thinks it knows the max
value and scales accordingly. This code currently works, even though
it takes an unsafe shortcut.
So this means that, while fixing code that never worked, this change
would break code that currently does. Also, it adds a bit of
complexity to the kernel to solve what should be entirely a user
By the way, introducing scaling to the kernel also loses information,
since you no longer know how many steps are there in the ramp. An
application may very well respond to "one step brighter" by doing a
linear interpolation, followed by a check if the result is actually
different, and using current+1 if it isn't, so that users always get
a visible response when trying to make a change.
So I would see this more like the kind of change you may make to
test your set of user spaces to find improper use of the ABI (set max
to 2 and WARN_ON any attempts to set a higher brightness :), but not
something that you'd want to deploy as a general feature.
More information about the openmoko-kernel