[UPSTREAM] Move backlight handling out of pcf50633 driver

Andy Green andy at openmoko.com
Tue Oct 21 22:46:59 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| On Tue, Oct 21, 2008 at 10:04:15AM +0100, Mark Brown wrote:
|> On Tue, Oct 21, 2008 at 08:41:55AM +0530, Balaji Rao wrote:
|>
|>> The voltage change effected by changing the brigtness value in /sys is
|>> exponential, not linear.. So, the code that assumes that it's going to
|>> reduce the brightness level by half by making it 30 or so, is actually
|>> reducing it by 1/6 th.
|> The human eye doesn't detect brightness linearly so hardware intended
|> for use in controlling brightness often implements controls with
|> non-linear values like this - check what the actual effect is for the
|> user.
|>
|
| I changed to code to scale brigtness linearly between 0-255 and the
| result was not good. Now I've come to understand that brigtness does not
| vary linearly with the voltage. :)

Thanks for looking at it Balaji.

What actually happened?  Smoke :?)  If it's simply that the range
favours darkness or brightness at one end, it doesn't seem to make
trouble.... the meaning of these brightness numbers to Linux is nowhere
defined except presumably that there should generally be a monotonic
increase in brightness with an increase with these numbers.

Whatever the nonlinear mapping is, it should be unchanged when we map
0-255 -> 0-63 by shifting it two places to the right?  That includes the
halfway point or whatever?

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkj+P2MACgkQOjLpvpq7dMrpMACeNhEilHfSgiXXe22SzU/L1uuB
WucAn2oF5BfelFuYBMXsDy3Dp6GxLuoO
=F3k0
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list