-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
|> 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. Yeah that broken code needs to use the already provided max value. What do you mean "worse"? The proposed bad code you're talking about won't survive us changing PMU or working on a different phone with another PMU that has different scaling. When fixed, it is independent of what it's running on, that's "worse"? | This is the best reasoning I've seen to leave the value as-is. Thanks, No the best reasoning was "it ain't broken so don't break it" from Mickey, but there are reasons for this. | Werner, for your insight. I still wouldn't mind a #define so it can be | adjusted in the kernel in 1 place if necessary, but I'd have to say | unilaterally changing to 0-255 is probably not a good idea as stated above. First getting our stock kernel to do what you need here is very important for us for reasons that will become clear later. Second, I know you changed this to 0 - 255 in a patch you held locally for a long while... Did any of these scare stories actually occur? I seem to recall there is an actual_brightness in there as well, if it does what I think it does I don't see why any code using all the information provided by the standard Linux backlight implementation correctly would break. Balaji, if you have some interest and time, please implement this 0-255 in a patch and give it some small tries down /sys and see what the facts are. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkj8B2QACgkQOjLpvpq7dMrL5QCfSAX3J5cfOkvxRRuQQy0xgeGn MgEAniboqj6vyGC6py7qWpoJt2rg8lJO =RLA3 -----END PGP SIGNATURE-----
