On Tue, 08 Jan 2008, Matthew Garrett wrote: > On Tue, Jan 08, 2008 at 10:06:53AM -0200, Henrique de Moraes Holschuh wrote: > > Is there a *real* technical reason why we can't just round to the nearest? > > That will work well with any firmware, and it will not remove functionality > > from any box, while at the same time plugging the current issues nicely. > > Yes. Software makes the assumption that writing a value larger than the > current value will result in the value increasing, which isn't > necessarily true if you round it. I dare say that such an assumption is broken for the backlight class, there is a reason why we have actual_brightness and brightness separate, and it is just that one AFAIK. I am cc'ing the backlight class maintainer to get his opinion on the matter. That doesn't mean we shouldn't improve the backlight class to give it something like _BCL does as an *optional* attribute (but with extra explicit guarantees, such as the one that it will list values sorted from lowest to highest, etc), but it does mean that anything assuming that adding one to a brightness level in the backlight class will INCREASE brightness is just plain *broken*. If actual_brightness did not change, then the backlight brightness level did not change either. Heck, back to the video.c driver, you shouldn't even assume _BCL gives you a sorted list after the second element. I admit it takes an special kind of weird firmware to screw with _BCL like that, but the ACPI spec doesn't mandate it, it just says that the OSPM will cycle through the values returned by _BCL, but nowhere does it define HOW one cycles through those... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
