Description of problem: After resume from suspend, the display on my Samsung NC10 frequently dims, even while I am typing. Continued typing does not raise the brightness. Sometimes I see an additional icon in the system tray that points to http://blogs.gnome.org/hughsie/2009/08/17/gnome-power-manager-and-blanking-removal-of-bodges/ and says to report a bug to the distribution. Version-Release number of selected component (if applicable): gnome-power-manager-2.28.1-5.fc12.i686 xorg-x11-server-Xorg-1.7.1-7.fc12.i686 xorg-x11-drv-intel-2.9.1-1.fc12.i686 How reproducible: When the dimming happens is not predictable, but it happens frequently after resume. Steps to Reproduce: 1. suspend 2. resume 3. use computer Actual results: Screen won't dim until idle. Expected results: Screen dims at random times.
This is a little more bizarre than expected. The screen continues to dim, even when I turn off the "Dim display when idle" checkbox in the "On Battery Power" section of the gnome-power-manager preferences.
Watching the output of 'devkit-power --monitor-detail' shows messages like this every time the display dims: daemon changed: daemon-version: 012 can-suspend: yes can-hibernate yes on-battery: yes on-low-battery: yes lid-is-closed: no lid-is-present: yes daemon changed: daemon-version: 012 can-suspend: yes can-hibernate yes on-battery: yes on-low-battery: no lid-is-closed: no lid-is-present: yes It appears that the on-low-battery state is changing even though the battery is approximately 80% full.
Changed title to reflect what the real problem is. gnome-power-manager attempts to change the brightness whenever it gets a message from DeviceKit-power showing a change when on-battery is set to yes. At least on my system these messages happen when the power supply hasn't changed. I guess the fix would be to get gnome-power-manager to check the last power supply state before attempting to dim or get DeviceKit-power to not send the spurious messages.
I have a Samsung NC10 and saw the same problem. There was an auto-dimming setting in the BIOS that I flipped to get rid of the confusing behavior. It's not really a solution, but it's a pretty good workaround.
The BIOS setting Andrew mentions is "Brightness Mode Control". Setting that to "User Control" instead of "Auto" greatly reduces the frequency at which the screen dims, but it still dims whenever one of those extra change messages comes through.
Created attachment 373821 [details] Extract percentage using the correct type. The problem was DeviceKit-power using a guint to extract the percentage in the on-low-battery calculation. The resulting value would be either 0 or -1 depending on the charge percentage. The attached patch fixes the problem in DeviceKit-power.
Patch applied, thanks.