Bug 638944 - display backlight brightness decreases after every mains detach/attach (or screensaver activation)
display backlight brightness decreases after every mains detach/attach (or sc...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-power-manager (Show other bugs)
14
All Linux
low Severity low
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-30 08:58 EDT by David Timms
Modified: 2011-12-04 03:54 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-04 03:54:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gnome-power-bugreport (3.58 KB, text/plain)
2010-09-30 18:17 EDT, David Timms
no flags Details

  None (edit)
Description David Timms 2010-09-30 08:58:09 EDT
Description of problem:
At each power save event, theat triggers dulling the brightness of the laptop screen, the screen goes to low brightness. After power or mouse/keyboard movement the event is noticed, but the brightness does not return to the original level, sometimes changing to lower than is was set after power was removed.

Version-Release number of selected component (if applicable):
guessing that gnome-power-manager is controlling this:
2.3

How reproducible:
On a HP compaq nx6320 running F14 beta, also same running F13 release.

Steps to Reproduce:
1. turn brightness to full.
2. Unplug mains
3. plugin mains
4. Unplug mains
5. plugin mains
6. turn brightness up (fn-f10) to 9
7. Unplug mains
8. plugin mains
9. Unplug mains
10. plugin mains
  
Actual results:
1. screen is bright=11
2. bright=6
3. screen brights for 0.1s then bright=0
4. bright=0
5. bright=0
6. bright=9
7. bright=0
8. bright=4
9. bright=5 (within 0.1sec), then bright=1
10. bright=0

Expected results:
If bright=7 when power is lost (or screensaver), power restore/mouse/key should restore power to bright=7.

Additional info:
An additional bug is that sometimes Fn-F10 (brightness up) has no effect, even though the backlight is fully dimmed. If you then press backlight down once(Fn-F9), the OSD brightness graph shows bright=10 and the screen brightens. At this point turning up the backlight=11 further brightens the screen.

It appears that the software thinks it has already set maximum level, but either it didn't succeed or the value tracking the level is wrappping around or something. It then rejects the attempt to set that value. It should accept that the user wants maximum level and set maximum level (again).

ps. while typing the bug, the laptop began responding slowly to key presses, then not at all, the mouse would only move for 0.2sec each 2-3secs, then eventually stopped updating altogether. The desktop clock also stopped. Not sure if this is the same or a different bug ! Will try to reproduce.
Comment 1 David Timms 2010-09-30 18:17:34 EDT
Created attachment 450899 [details]
gnome-power-bugreport

It seems (from some earlier bugs) the above the output of bugreport might be useful, so attached it.

I also went through each of the 11 settings (via fn bright up/down), and ran xbacklight after each setting:
[davidt@f14beta ~]$ xbacklight
100.000000
[davidt@f14beta ~]$ xbacklight
90.000000
[davidt@f14beta ~]$ xbacklight
80.000000
[davidt@f14beta ~]$ xbacklight
70.000000
[davidt@f14beta ~]$ xbacklight
60.000000
[davidt@f14beta ~]$ xbacklight
50.000000
[davidt@f14beta ~]$ xbacklight
40.000000
[davidt@f14beta ~]$ xbacklight
30.000000
[davidt@f14beta ~]$ xbacklight
20.000000
[davidt@f14beta ~]$ xbacklight
10.000000
[davidt@f14beta ~]$ xbacklight
0.000000

I'll use only xbacklight (to determine levels) while doing the power detach/reattach process described in the reproducer.
Comment 2 Richard Hughes 2011-11-15 08:05:46 EST
Does this still happen in F16? Thanks.
Comment 3 David Timms 2011-12-04 03:54:52 EST
(In reply to comment #2)
> Does this still happen in F16? Thanks.
I now have a different notebook PC, so am unable to test.

However, with my newer HP ProBook 6550b, I can't fault the power off -> dimm, power on + key/mouse action back to original brightness operation. Versions:
gnome-power-manager-3.2.1-1.fc16.x86_64
kernel-3.1.0-7.fc16.x86_64
xbacklight-1.1.2-2.fc15.x86_64
xorg-x11-server-Xorg-1.11.1-1.fc16.x86_64

Closing. If someone else finds fault with the original notebook type and running >= F16: on eg HP compaq nx6320, then please re-open and update the distro version and other versions.

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