[hardy] Brightness level on battery is not consistent with user adjustments

Bug #203108 reported by Alexey Balmashnov on 2008-03-17
Affects Status Importance Assigned to Milestone
gnome-power-manager (Ubuntu)

Bug Description

Hardy, pre-beta, up to date.
Dell Inspiron 640m https://wiki.ubuntu.com/LaptopTestingTeam/DellInspiron640m

Steps to reproduce behavior:
1. Switch to battery power (brightness of the display reduces to the level of approx 1/3)
2. Adjust brightness as desired (lets say 1/2)
3. Switch to AC (brightness -> 100)
4. Switch to battery. It looks like the brightness drops to the same value as in 1.

Another sequence:
1. 2. as above.
3. Wait till monitor dims out.
4. Do something to wake up the system. Brightness again adjusted to some strange level (As in 1.).

Expected behavior: Once set for particular mode (AC power or Battery) brightness level should remain consistently on the same level upon mode switch.

Could you please retest with gpm 2.22, this behavior has been changed in
newer packages.


I do not see any improvements with gnome-power-manager 2.22.0 (2.22.0-0ubuntu1).

-- Alexey

On Wed, Mar 19, 2008 at 10:46 PM, Ted Gould <email address hidden> wrote:
> Could you please retest with gpm 2.22, this behavior has been changed in
> newer packages.
> --Ted
> --
> [hardy] Brightness level on battery is not consistent with user adjustments
> https://bugs.launchpad.net/bugs/203108
> You received this bug notification because you are a direct subscriber
> of the bug.

Andy Walker (walkeraj) wrote :

This seems to be a problem with the way battery brightness and AC brightness are calculated relative to each other. See my duplicate bug #206228. If you cycle between AC and Battery power by pulling the plug in and out, the brightness level of both will steadily decrease until battery brightness is at minimum and AC brightness is two clicks above this. My guess is that there is a calculation error where AC brightness is calculated relative to battery brightness when, in fact it should only go one way (if at all). Both levels should just be stored and not calculated relative to each other.

There are other bugs in the power manager related to this one that I discovered, but that's for another bug report.

Ben Bailes (eurobob) wrote :


I have a similar problem with Hardy Beta and the latest packages installed (gnome-power-manager 2.22.0-0ubuntu2)

One issue:
I unplug laptop from AC power - the brightness will remain the same despite it being set to dim on battery. I can adjust the brightness with the function keys and then when plug the AC power back in again the level will remain the same.

Another issue:
When the laptop is running on battery, set to dim display on idle, it will dim correctly. I then set it back from idle by moving the mouse and the screen dims to the lowest level possible!

I think these problems are related and the computer is getting confused ie it looks like...
1. When AC power is removed, display does not dim.
2. When computer then goes idle, display will then dim to what looks like a standard level when running on battery.
3. When I set back from idle, display will dim to the lowest level possible.

Just to confirm reduce backlight brightness and dim display on idle are set only on battery mode.
Laptop: ASUS Z53S, nvidea chipset.

Jeremy Wilkins (jeb-jdwilkins) wrote :

I'm getting the same symtoms

Display is set to not dim when on battery but does anyway, once dimmed any movement of the mouse then causes it to dim further.

Dell XPS 1330m - installed with Hardy Alpha 6, updated to current as of 27.03.08. Using gnome-power-manager 2.22.0-0ubuntu2

Giorgos Logiotatidis (seadog) wrote :

Same problem here.
Ubuntu Hardy Beta up to date as of March 28th

Dell Latitude D820

The dimming problem doesn't occur if 'Dim display when idle' option is deselected (along with the 'Reduce backlight brightness' setting). Would suggest power manager is watching for activity but not seeing any for some reason ??

Ludovico Cavedon (cavedon) wrote :

Same problem with HP pavilion dv2570

yassin (yassin) wrote :

Same with ASUS U3S.

When I configure my brightness by hand it still shows up with almost no brightness (0 value) after a reboot.

same problem on samsung x22

Ben Bailes (eurobob) wrote :

Seems to have been fixed for me.

Amit Mendapara (cristatus) wrote :

Same problem with my Acer 4520.

$ cat /proc/acpi/acer/brightness

is reduced to 0 from 9.

Milton (miltonlaufer) wrote :

Same problem with my MSI Notebook PR310x

Han Chung (han+c) wrote :

Brightness setting not consistent here too.

Dell XPS M1210

Sympy (sympathy4no1) wrote :

Not consistent for my Vostro 1400 either.

Furthermore, my current settings is 100% on ac and 50% on battery. However, if I unplug the cable and plug it again, it goes to 50% like it should on battery but then it goes back to 94% instead of 100%. Which means that, even in terms of relative calculations, something is wrong.

Pedro Villavicencio (pedro) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Intrepid Ibex. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

Changed in gnome-power-manager:
status: New → Incomplete
Pedro Villavicencio (pedro) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to New. Thanks again!.

Changed in gnome-power-manager:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers