On Tue, 2008-01-08 at 10:48 -0200, Henrique de Moraes Holschuh wrote: > 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. The reason actual_brightness and brightness are two separate things are because some hardware exists that will let you request one brightness but choose one that is different itself. There are also some devices that have backlight limiting in software for use in emergency low battery situations (the battery can get low enough that the device reboots on high backlight but is otherwise usable). I did't get enough context above but I went through the archives and it seems this is about linearising backlight values. You can't just export an interface of 0-100 and hope things will work since you lose the information about which values do something and which don't. I agree something which tells us what those brightness values mean could be useful though, a kind of brightness value <-> relative brightness table. The framebuffer layer has something like this already from before the backlight core was abstracted/standardised. I'd look at that as a first port of call and try to see if it could be integrated into the backlight class somehow. Cheers, Richard - 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
