Red Hat Bugzilla – Bug 693205
Backlight auto-dim behaviour is random
Last modified: 2011-11-15 08:40:02 EST
I'm using Fedora 15 (beta) upgraded from 14 using preupgrade and I'm using gnome 3. In Fedora 14, switching to battery would cause an auto-dimming of backlight and switching back to A/C would auto increase brightness back to brightness specified in configuration screens. Also, while on battery the screen would auto-dim when system is idle. I believe in Gnome 3 its a "feature" that dimming behavior on battery option was removed but there is still a check mark in Screen settings screen for auto-dim on idle. At least I assume its for idle. When I am on A/C, the screen never auto-dims (stays at brightness level from Screen config screen). When I switch to battery, the backlight will sometimes but not always switch to 50% brightness. When on batter and idle, the screen will sometimes but not always set brightness to 0%. I suppose this could be some strangeness of my ACPI since they sometimes have logic to auto-dim backlights on battery. I have an Eee PC 1015PE. Since behaviour is not consistent then I suspect its not this. Or it could be related to some upgrade issue based on dimming config settings in Gnome 2. I'm not positive on component but I picked gnome-power-settings because I think thats were this logic lived in Gnome 2. Also, current behaviour seems to be driven mostly by power indication.
I'm also seeing erratic backlight behaviour on my Atom tablet (Intel 945 graphics). I'm using a fresh Fedora 15 Beta install, up-to-date as of 2011-04-18. What I know is the following: - It worked fine on Fedora 14, dimming when idle as specified. - When gnome-power-manager is NOT running, the tablet's backlight automatically goes to full brightness when AC is plugged in, and dims slightly when un- plugged. There are no "hardware" switches on this tablet to control the brightness. When gnome-power-manager is started, the fun begins. I'll attach the output of gnome-power-manager -v below. For that log, - I adjusted the screen brightness via GNOME's Display settings to full and then killed gnome-power-manager. - g-p-m was started with AC power attached. - I then pulled the AC. The screen dimmed a bit, then dimmed some more. It did not brighten at all as I started typing this comment. - I plugged the AC back in. The screen remained at this lower brightness. - I then went into screen settings and unchecked "Dim to save power". Nothing changed. - Finally, I dragged the brightness slider back up. The screen brightened accordingly. For some reason, the slider seemed to flit about a bit on its own between full brightness and the next setting down. At this point, I killed g-p-m and attached the log.
Created attachment 492986 [details] script capture of g-p-m -v, tested as described in my comment
I am using a netbook with an Intel Atom process and 3150 integrated video (I believe thats right number). Also, I've since found that if I disable the auto-dim on idle feature in settings menu that the backlight behaviors as expected. There is no change between A/C and battery and no random adjustments. So it does seem the bug is in g-p-m area... or at least a combo of g-p-m and upower notifications.
I've tried to isolate a little further as well by using dbus-monitor. I'll attach the output. Here is some discussion on sequence. - Enable auto-dim feature in Screen menu while on A/C. - Unplug power to switch to battery. - After 30 or 60 seconds the screen auto-dims and get related event in DBUS: signal sender=:1.47 -> dest=(null destination) serial=519 path=/org/gnome/PowerManager/Backlight; interface=org.gnome.PowerManager.Backlight; member=BrightnessChanged - Plug power cable back in. Backlight never changes. A lot of "NamedOwnerChange" messages for UPower and "Failed" responses start showing up. Not sure why thats occuring. Maybe g-p-m or upowerd is crashing? There is a notification in there. I have a script that monitors dbus for A/C changes and adjusts eeepc's cpufs interface (bus frequency) to save extra power and use notify-send when it does. That worked fine in Gnome 2 but maybe some bug with notify-send exists that tickles this.
Created attachment 493338 [details] snippit from dbus-monitor from time period of dimming and reverting back to A/C
*** Bug 694538 has been marked as a duplicate of this bug. ***
I've been browsing the gnome-power-manager code to see if I can find anything. It looks to me that that it will auto-dim the screen when switching from AC to battery but does nothing special going from battery to AC direction. The comments say it is informed of idle state from org.gnome.ScreenSaver. Based on that, I find the following output from running "gnome-power-manager -v" interesting: 11:03:09 PowerManager Throttle failed: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "Throttle" with signature "ss" on interface "org.gnome.ScreenSaver" doesn't exist But besides that, I can't really see how it every worked. I clearly see logic that scales down brightness when on battery or idle but I do not see how it scales back up. Here is output from gnome-power-manager around time it should scale back up because I switched to AC and not idle: 11:03:43 PowerManager idletime reset 11:03:43 PowerManager Doing a state transition: normal 11:03:43 PowerManager we have just been idle for 28.908458s 11:03:43 PowerManager changing powersave idle status to 0 11:03:43 PowerManager 1. main brightness 0.300000 11:03:43 PowerManager 2. battery scale 1.000000, brightness 0.300000 11:03:43 PowerManager 3. idle scale 1.000000, brightness 0.300000 11:03:43 PowerManager using resource 0x8f21a30 11:03:43 PowerManager resource 1 of 2 11:03:43 PowerManager hard value=5, min=0, max=15 11:03:43 PowerManager percentage 33 11:03:43 PowerManager resource 2 of 2 #1 is saying that current brightness is 70% max (inversed value) It adjustment occured because I was on battery and went idle right before this. #2 is saying because I'm on AC to scale value #1 to 100%. #3 is saying because I'm not idlel, scale #1 brightness to 100%. 70% * 100% * 100% is still 70% so this code path can only dim and not brighten. No were do I see it allow greater than 100% scaling or for master_percentage variable back to value from "screen" configuration setting. But the above logic does explain why it can dim all the way to OFF. Each time I unplug the AC and go to idle, it will continue to dim by 30% from *previous* dimmed brightness value... eventually it will go to 0%.
I probably got the 70% value wrong. The brightness level probably is closer to 33% than it is to %66. But the overall concept I described should be right.
Here's a "me too" statement, i.e. I'm experiencing the same problem win Fedora 15 on a Dell Studio 1458 with an Intel Ironlake Mobile graphic card. I'm dual booting with Ubuntu 11.04 (based on Gnome 2) and, indeed, brightness adjustment works fine there.
Could this be related to this gnome-power-manager bug report (in Gnome): https://bugzilla.gnome.org/show_bug.cgi?id=647519
I was monitoring the output of g-p-m while switching between battery/AC and it wasn't crashing so its probably not same bug.
This issue has been fixed with update gnome-power-manager-3.0.0-3.fc15. At least it reports fixing this specific issue and my 2 minutes of testing seems to indicate this as well. Looks like bug#689896 was doing some parallel debugging on this. This bug report can be closed as fixed now.
Great, thanks.