Bug 693205 - Backlight auto-dim behaviour is random
Summary: Backlight auto-dim behaviour is random
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-power-manager
Version: 15
Hardware: i386
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 694538 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-03 14:26 UTC by Chris Bagwell
Modified: 2011-11-15 13:40 UTC (History)
9 users (show)

Fixed In Version: gnome-power-manager-3.0.0-3.fc15
Clone Of:
Environment:
Last Closed: 2011-11-15 13:40:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
script capture of g-p-m -v, tested as described in my comment (178.58 KB, text/plain)
2011-04-18 19:11 UTC, James
no flags Details
snippit from dbus-monitor from time period of dimming and reverting back to A/C (23.81 KB, text/plain)
2011-04-20 01:50 UTC, Chris Bagwell
no flags Details

Description Chris Bagwell 2011-04-03 14:26:50 UTC
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.

Comment 1 James 2011-04-18 19:10:46 UTC
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.

Comment 2 James 2011-04-18 19:11:34 UTC
Created attachment 492986 [details]
script capture of g-p-m -v, tested as described in my comment

Comment 3 Chris Bagwell 2011-04-18 23:56:08 UTC
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.

Comment 4 Chris Bagwell 2011-04-20 01:50:04 UTC
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.

Comment 5 Chris Bagwell 2011-04-20 01:50:58 UTC
Created attachment 493338 [details]
snippit from dbus-monitor from time period of dimming and reverting back to A/C

Comment 6 Charles R. Anderson 2011-04-22 02:18:50 UTC
*** Bug 694538 has been marked as a duplicate of this bug. ***

Comment 7 Chris Bagwell 2011-04-24 16:50:47 UTC
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%.

Comment 8 Chris Bagwell 2011-04-24 17:16:21 UTC
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.

Comment 9 mlaverdiere 2011-04-28 10:32:27 UTC
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.

Comment 10 mlaverdiere 2011-04-28 10:42:42 UTC
Could this be related to this gnome-power-manager bug report (in Gnome):  https://bugzilla.gnome.org/show_bug.cgi?id=647519

Comment 11 Chris Bagwell 2011-04-28 13:02:24 UTC
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.

Comment 12 Chris Bagwell 2011-05-31 01:43:45 UTC
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.

Comment 13 Richard Hughes 2011-11-15 13:40:02 UTC
Great, thanks.


Note You need to log in before you can comment on or make changes to this bug.