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.
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.
Does this still happen in F16? Thanks.
(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.