Re: brightness control on thinkpad t61p

[Richard Purdie <rpurdie@rpsys.net>]

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