After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 530346 - Laptop LCD brightness on battery/power should be remembered
Laptop LCD brightness on battery/power should be remembered
Status: RESOLVED FIXED
Product: gnome-power-manager
Classification: Deprecated
Component: gnome-power-manager
2.22.x
Other All
: Normal minor
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-04-28 12:30 UTC by Magnus Boman
Modified: 2012-03-16 11:07 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Magnus Boman 2008-04-28 12:30:21 UTC
1. When booting the machine and I have setup default login, when X comes up
screen display power increases
2. I reduced it immediately, after the GNOME splash screen closes, again the
power goes up
3. Now plugin the power socket (previous 2 steps you can try without power, by
running in battery), again display power goes high.

Actual result:
Its annoying :) as the display power suddenly increases.

How often:
Always

Expected:
Should be same as per user settings

g-p-m should remember the setting for battery/power and store it per user.


Other information:
Downstream bug;
https://bugzilla.novell.com/show_bug.cgi?id=377060
Comment 1 Eddy Petrişor 2008-06-30 00:56:49 UTC
Hello,

1) I hate all these brightness related bugs, especially since they represent a regression.
2) There are several bugs that overlap(#478128, #483134, #483143, #509211)  ; IMHO, there should be ONLY ONE

I have reported this in Debian bug #467264 and I explained why the current (and former) behaviour is(was) wrong and how they should actually behave.


http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467264


To summarize:
- AC and battery settings MUST not interact with each other
- the battery *brightness*slider* should be *brought*back* (one should be able to set the default battery brightness level, no matter what automatic dimming effect is added)
- dimming on idle should *really*dim*or*do*nothing*, if dimming is not possible; is should NEVER bright up the display
- using the *brightness* *keys* should be a clear adjustment of the default brightness level and it should *always* have precedence over anything automatically computed or commanded
- DO NOT DIM WHILE ACTIVE


If anyone cares, here is the summary I made in the debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467264#33
Comment 2 Eddy Petrişor 2008-06-30 01:09:49 UTC
Sorry, the entire list of bug was:
bug #478128,
bug #483134,
bug #483143,
bug #509211,
bug #530346,
bug #335673 and
bug #483144
Comment 3 Richard Hughes 2008-06-30 10:11:07 UTC
Magnus, can you have a look at the UI in svn hwad and tell me what you think please. Thanks.
Comment 4 Eddy Petrişor 2008-10-24 14:37:47 UTC
Is there a way to test g-p-m without installing in the system (i.e. install in ~)?

I tried to do this, but I still need some files in /usr/local/...

I made some changes that were meant to store the battery brightness level (no wonder g-p-m forgets them, there is no such setting stored in the registry).

Also, I am unclear how I should re-add a variable that was once present? The schema file has some versioning; do I need to bump that?


Eddy (trying to fix the bug for Debian Lenny and everyone else).
Comment 5 Eddy Petrişor 2008-10-24 15:51:34 UTC
I forgot to say that I have looked over the code (about 2 months ago) and seen that much of the changes made on the code actually broke the code wrt to saving battery bright level while trying to simplify the interface.

I think the changes that should have been done:
1) provide a default 50% brightness dim initially for battery (new user, this is default), but don't link it to the AC level
2) the default AC level is 100%, by default
3) every time the user changes the brightness level, be it on AC or on battery, the new level is stored in a corresponding registry value (AC has one, bat has a different one) - the stored value is absolute, so the values have analogous meanings



This is really simple enough to be implemented easily and provides a sane default for any scenario, no matter if is close to what someone uses or not.




I really understand what was attempted with the changes, but the implementation I see in 2.22.1 is seriously broken, primarily because it provides no way to manually set and store the battery brightness level.

Also note that some broken acpi-s report wrongly that the laptop is on battery when on AC, so for such a scenario, I would set the brightness to the maximum, but since such a setting isn't stored, it won't work.
Comment 6 Tobias Mueller 2009-06-26 20:34:20 UTC
Richard, I think your requested information has been delivered. I am thus reopening. You are, of course, free to set to NEEDINFO again if I am mistaken or you have further questions.
Comment 7 Richard Hughes 2012-03-16 11:07:20 UTC
I think all the brightness bugs are good now we've moved to gnome-settings-daemon. Please open a new bug if there continues to be problems. Thanks.