Description of problem: When "Reduce backlight brightness" is enabled on battery and "Dim display when idle" is disabled, if I unplug my power cord, the backlight is reduced (as expected). When I then manually adjust the brightness to a higher level and leave the computer idle for a while (for example when showing a customer a slide from a presentation), the power manager reduces the backlight again. Version-Release number of selected component (if applicable): Fedora 14 (have noticed it on RHEL 6 CSB as well by the way). How reproducible: By following the steps below. Steps to Reproduce: 1. Enable "Reduce backlight brightness" in Gnome Power Manager. Disable the "Dim display when idle" option. 2. Set backlight brightness to maximum. 3. Unplug power cord. Backlight brightness is reduced. 4. Manually increase the brightness again. 5. Leave the computer idle for a minute or two, backlight will be reduced again. Actual results: Backlight keeps getting reduced, even after manual adjustment. Expected results: Backlight is only reduced when unplugging the power cord, not again when leaving the system idle for a minute or two. That's what the "Dim display when idle" option should control. Additional info:
clarifying the description a bit: it's not simply that it dims the display on idle, it's that *it doesn't un-dim it when you stop being idle*.
Not entirely sure about the initial report, but I'm certainly seeing what's mentioned in comment #1, in F15. In F14, the behaviour was this: * When laptop plugged in, display would always be at 100% brightness * When laptop unplugged, display would be dimmed to about 50% brightness * When laptop unplugged and left idle for a while, display would be dimmed to about 20% brightness * When laptop unplugged and stopped being idle - key press, mouse movement - display would go back to 50% brightness It's this last bit which seems to be broken in F15: once g-p-m dims the screen to 'idle' brightness, it won't go back to 50% again even if you move the mouse or press a key. However, I think the original report is for a *different* bug, and Dan's 'clarification' is not in fact one. I believe the bug in the original report is simply that g-p-m overrides manual settings of the backlight strength and it really shouldn't; if you unplug and then manually increase the brightness, g-p-m should leave it at that level (perhaps until you plug back in, or manually decrease the brightness back to, or below, the 'automatic' setting) rather than overriding back to the 50% level a few minutes later. So we probably need another report for the comment #1 issue. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
another report from the forums: http://forums.fedoraforum.org/showthread.php?t=263072 adding CommonBugs keyword, we should probably make a note of this. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I got some g-p-m verbose logs, attached. This looks like the interesting part, to me. This is when it's doing the idle dim: 08:21:24 PowerManager normal to dim 08:21:24 PowerManager Doing a state transition: dim 08:21:24 PowerManager we were active for 66.548975s 08:21:24 PowerManager changing powersave idle status to 1 08:21:24 PowerManager 1. main brightness 0.500000 08:21:24 PowerManager 2. battery scale 1.000000, brightness 0.500000 08:21:24 PowerManager 3. idle scale 0.300000, brightness 0.150000 This is when it tries to un-dim: 08:22:07 PowerManager Doing a state transition: normal 08:22:07 PowerManager we have just been idle for 43.068824s 08:22:07 PowerManager changing powersave idle status to 0 08:22:07 PowerManager 1. main brightness 0.150000 08:22:07 PowerManager 2. battery scale 1.000000, brightness 0.150000 08:22:07 PowerManager 3. idle scale 1.000000, brightness 0.150000 So yeah - the relevant code is gpm_backlight_brightness_evaluate_and_set in gpm-backlight.c . As far as I can see this code just isn't ever logically capable of *raising* the brightness, as the first thing it does is use the current brightness as a base - /* get the last set brightness */ - and then there are a couple of functions which can potentially *lower* it, if scale gets set to less than 1.0 in either case, but can never possibly *raise* it, as there's no way scale can ever be higher than 1.0. A quick fix would be to have this function always operate on the maximum possible brightness value, not the current brightness value. I'm going to test a patch that does that, and attach it if it works. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Adam, The issue you're describing, and the one that's described in the forum is indeed different from the one I described in the original report. You're analysis in comment #2 is correct, PowerManager shouldn't reduce backlight brightness again after I have manually set it to a higher brightness. Could you open a second bug-report for the problem you're having with the PowerManager not undimming? I think we currently have 2 issues in one bug-report which makes it harder to actually solve the issue described in the original report.
Nope, even trickier - thanks git blame! - the issue is this change: http://git.gnome.org/browse/gnome-power-manager/commit/src/gpm-backlight.c?id=48fa50a682afc1c6f2492f9c1c73b7de0fa8906b That makes evaluate_and_set call gpm_brightness_changed after setting the brightness. But gpm_brightness_changed *stores the new value as the master percentage*, which is why we wind up with this feedback loop where evaluate_and_set is always operating on the last automatically-set value, not on the max value from gsettings. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Hey Duncan - yes, sorry for carrying my debugging here. I'll move this one upstream, as it's an upstream issue anyway.
So I think I traced out the issue Dan and I were seeing, and filed it upstream with a patch: https://bugzilla.gnome.org/show_bug.cgi?id=650405 let's leave this for Duncan's issue. (However, Duncan, your issue is more or less a feature request, and it may be best to file it upstream; there's nothing Fedora-specific about it.) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
so there is an upstream bug for the original issue here (Duncan's): https://bugzilla.gnome.org/show_bug.cgi?id=603108 Richard says he's going to be working on this upstream, targeting GNOME 3.2 (so Fedora 16), next week. Given that, changing version to Rawhide. We could close this as UPSTREAM, or leave it open, either way. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This should be fixed in F16, please reopen if that's not the case. Thanks.