GNOME Bugzilla – Bug 478128
Desyncronisation with current brightness settings and g-p-m
Last modified: 2009-07-07 21:38:04 UTC
When my laptop is on battery power g-p-m changes brightness to the the value it's configured in 'Dim display brightness by:' (i.e.: 50%) But if I change the brightness with the laptop Fn-Keys/Hotkeys, let's say 25%, it's not synchronized with g-p-m. The following 'bugs' occur: - When the laptop is idle it dims the display. But when I move the mouse the brightness level is changed to the value configured in g-p-m (50%) and not the custom (25%), and the last, that I did with the laptop Fn-Keys/Hotkeys; - When I open the preferences dialog from the g-p-m applet the brightness level is also changed like I mentioned above;
This bug has been filed in Ubuntu as well: https://bugs.launchpad.net/gnome-power/+bug/140018
Guys, This bug really annoys me. I can look into the code and make a patch if you give me a clue where to look. I'm not familiar with gnome internals and your suggestions will save a lot of my time. Sincerely, Roman
Same bug here. Very annoying.
Confirming on Ubuntu Hardy with Gnome 2.21.90. Changing brightness with Fn keys don't affect value showed by brightness-applet and therefore when g-p-m check backlight status, g-p-m returns brightness do value that it remembers - usually a default one from gconf as most users do not even know about brigtness applet existence and use only Fn keys. This is a serious usability bug. Please mark it as confirmed and set appropriate priority to this.
Actual bug in Ubuntu (the one before is marked as dupe): https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/131885
Created attachment 107266 [details] [review] Patch to keep track of what direction the brightness is supposed to be changing, and never do anything surprising. This is one way to prevent counterintuitive things from happening. The alternative would be to have the hardware brightness adjustment controls actually change some GConf key in order to permanently change the default setting. The big problem with that approach is that if you're calculating the brightness with things like brightness *= scale; where scale < 1, then increasing the default maximum brightness to 1 will fail to increase the current brightness to the maximum (for example when using battery), which would be frustrating for the user. If they keep pressing the brighten key, it should keep getting brighter until it physically can't.
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
Sorry, the entire list of bug was: bug #478128, bug #483134, bug #483143, bug #509211, bug #530346, bug #335673 and bug #483144
Keenan, can you please g-p-m from SVN and tell me what you think of the new logic? Thanks.
Thanks for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.
This bug does indeed still exist, alive and well with an up-to-date version of Intrepid. Please re-open.
I am not using Ubuntu, but to make it clear: Ubuntu Intrepid holds gnome-power-manager 2.24.0-0ubuntu8 If intrepid-updates are installed, gnome-power-manager is 2.24.0-0ubuntu8.2 Jacob, it might be useful if you'd tell if you use intrepid-updates or not.
Oh, and I'm definetly seeing this problem with 2.22.1-4 in Debian.
(In reply to comment #13) > Oh, and I'm definetly seeing this problem with 2.22.1-4 in Debian. 2.22.x is obsolete, sorry. (In reply to comment #12) > Ubuntu Intrepid holds gnome-power-manager 2.24.0-0ubuntu8 > If intrepid-updates are installed, gnome-power-manager is 2.24.0-0ubuntu8.2 The ubuntu version is sufficiently different from upstream that I would ask you to file bugs in launchpad if you encounter problem with 2.24.0-0ubuntu8. As an aside, power management stuff moves so quickly, with new technologies being introduced all the time (KMS and xrandr for instance) -- I can't backport massive new functionality into these old releases, sorry.
I have just installed gnome-power-manager-2.24.2-2 from Debian and it is still plain wrong when it comes to handling brightness on battery. My test laptop has some trouble when it is really on battery or not in Linux, and the following where done while applets showed it thought it was on AC. There are several problems (which I observed in a few seconds after the install): - no more battery tab in the settings --- please, please, please understand that people don't always agree with you when you say there is no need for some battery settings - after adjusting some brightness level via keyboard, selecting the Preferences->Power Management the brightness jumps to an automatically computed value which seems to be unrelated to (or is 50% of) the slider value (was max and manual level was maxed, too) Please fix these brightness level bugs, is really embarrassing, they have been introduced in the 2.20 days and there is no sign of improvement since then. Hugh, please stop trying to impose your view on power management of light on battery and AC, when users are explicitly telling you that you haven't fitted their legitimate use cases in the software, and fix the brightness issues in gpm.
Two more things: 1) please don't close bugs when you're not sure that the bug still applies, people like myself will be forced to open another bug instead; please reopen the bugs you closed on account of "obsolete versions", or at least the ones I reported as still beig present 2) another bug manifested: after dimming on non-activity, and reactivation the brightness level was set to the damned calculated value instead of the level I manually chose previously.
Wow, and another bug, just after pressing Save Changes, *I* feel embarrassed. Opened the g-p-m settings and dragged the brightness slider around. NO EFFECT! Brightness level didn't change at all. Taking into consideration the problems I still see, I am offering to help you in fixing these issues by testing the changes you might have on the condition you don't force me to install stuff under /usr/local. I am willing to use my home directory for the git/svn versions and replace schema files in /usr/share (dpkg-diversions would bring back the proper versions). This is not a fake offer, is really a desperate call for a fix.
OK, this brightness stuff needs fixing right away. I am unsure how it is possible that such bugs aren't seen since they're so obvious. I found yet another bug in the 2.24.2 version. After reboot, the brightness tab settings for battery reappeared (don't ask me how) and in that tab if you check/uncheck the Reduce backlight brightness checkbox it has an effect, even if g-p-m thinks the laptop is powered via AC.
Please open bug again until fixed....
(In reply to comment #19) > Please open bug again until fixed.... I suggest you open another bug, Richard closed this bug already, although the bug isn't fixed.