Re: [gpm] Fixing laptop brightness control

[Richard Hughes <hughsient gmail com>]

On Sun, 2008-01-13 at 18:15 +0100, Andy Wingo wrote:
> I'd like to fix GPM's laptop brightness control.

Then you would be a legend; a bit of background: I'm working full time
for a defense contractor in the UK and am having a really busy time with
real life stuff. Consequently gnome-power-manager development has
slowed, and I'll need some help.

> First, a description of my hardware: a powerbook g4, with an nvidia
> card. The brightness is controlled by a kernel module interacting with
> the video card, exporting its interface via sysfs as a standard device
> of class "backlight". My keyboard has two buttons to raise or lower the
> backlight level. When I press them, my backlight does indeed go up and
> down, and the gtk+ backlight thingie pops up. Given that the device is
> controllable via sysfs, I'll assume that it's HAL controlling the
> brightness.

Yup.

> Here is my principle regarding the backlight: "The user knows exactly
> how bright the screen should be." If the sun goes down, I lower the
> brightness with the keys. If I'm in a bar and move somewhere where
> there's less light, I raise the brightness.

Sure.

> This has all worked fine in the past, until the (otherwise excellent and
> nifty) automatic backlight dimming work that Anholt did. It's quite fine
> for G-P-M to lower backlight levels in times of inactivity, but it
> should raise them back to the levels that I had set them at previously.

Sure.

> The current case is that it goes back to whatever level that is set in
> GConf, which is only controlled via the g-p-m preferences page. If GConf
> is where this information has to go, well, let's make the user's choices
> get stored in GConf.

As long as we store it as a percentage, not as a level.

> This should work whether the user is on AC power or on battery. In this
> regard, the current implementation is a bit tricky -- there are only two
> knobs, GPM_CONF_BACKLIGHT_BRIGHTNESS_AC and
> GPM_CONF_BACKLIGHT_BRIGHTNESS_BATT.
> 
> The AC case is easy: pressing a button should cause BRIGHTNESS_AC to be
> set.
> 
> The battery case is different: BRIGHTNESS_BATT is actually not a level,
> it is a percent by which to reduce BRIGHTNESS_AC. One algorithm we could
> use would be the following, where CUR is the new brightness percentage
> that the user has selected via the brightness buttons:
> 
>   if CUR >= BRIGHTNESS_AC:
>     BRIGHTNESS_AC = CUR  # Don't dim when the user plugs in AC power
>     BRIGHTNESS_BATT = 0%  # Set battery brightness = ac brightness
>   else
>     BRIGHTNESS_BATT = (BRIGHTNESS_AC - CUR) / BRIGHTNESS_AC * 100
> 
> Alternately we could choose some other representation for
> BRIGHTNESS_BATT. Not very important though.
> 
> Thoughts?

All this stuff is very subjective - if it "works" for you then others
may still get confused. We also have to deal with the fact that some
laptops do not have brightness buttons, and we may be using the
brightness applet to change brightness. I'll go read your other email
now :-)

Richard.