Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Thinkpad screen brightness changes on resume from blank|
|Product:||[Fedora] Fedora||Reporter:||Matthew Saltzman <mjs>|
|Component:||gnome-power-manager||Assignee:||David Zeuthen <davidz>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||8||CC:||jonstanley, mclasen, rhughes, wtogami|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-01-08 23:35:32 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Matthew Saltzman 2007-01-20 17:06:28 EST
Description of problem: With screensaver st to "blank screen" the screen goes dark after the timeout. On typing or moving mouse, the screen wakes up, always at the brightest setting--even if it was at dimmest setting before. This is a regression from kernel-2.6.18-1.2869.fc6 and earlier. Version-Release number of selected component (if applicable): kernel-2.6.19-1.2895.fc6 How reproducible: Always Steps to Reproduce: 1. Install radeonfb in initrd and reboot. Using GNOME, set screensaver to "blank screen". 2. Wait for screen to go dark. 3. Move mouse or type. Actual results: Screen comes back on at full brightness. Expected results: Screen should come back at the same brightness it was set at before blanking. Additional info: Thinkpad T41 with Radeon Mobility M7 LW [Radeon Mobility 7500. I use the radeonfb driver to control a power issue when suspending to RAM. I tried switching to a VC. The screen blanks dim and restores dim, but switching back to X, the screen brightens. Blanking seems necessary to cause the change. Just switching back and forth between X and VC does not cause brightness to change. It does, however, cause the tpb (thinkpad-buttons) on-screen display to show briefly. That also shows when waking up the screen in X. I have attached xorg.conf, in case it is useful. Below are some relevant-looking log messages. None of the gnome-power-manager messages appeared before starting this kernel. As far as I can tell, the agpgart messages only appeared before on boot or resume from suspend to RAM before this kernel: Jan 20 15:48:22 vincent52 gnome-power-manager: (mjs) Screen dim because idle mode started Jan 20 15:52:16 vincent52 gnome-power-manager: (mjs) Screen resume because idle mode ended Jan 20 16:36:14 vincent52 kernel: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. Jan 20 16:36:14 vincent52 kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode Jan 20 16:36:14 vincent52 kernel: agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode Jan 20 16:36:15 vincent52 gnome-power-manager: (mjs) Screen dim because idle mode started Jan 20 16:36:15 vincent52 gnome-power-manager: (mjs) Screen resume because idle mode ended Jan 20 16:36:44 vincent52 kernel: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. Jan 20 16:36:44 vincent52 kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode Jan 20 16:36:44 vincent52 kernel: agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode Jan 20 16:41:32 vincent52 kernel: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. Jan 20 16:41:32 vincent52 kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode Jan 20 16:41:32 vincent52 kernel: agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode Jan 20 16:42:35 vincent52 kernel: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. Jan 20 16:42:35 vincent52 kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode Jan 20 16:42:35 vincent52 kernel: agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode Jan 20 16:42:50 vincent52 kernel: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. Jan 20 16:42:50 vincent52 kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode Jan 20 16:42:50 vincent52 kernel: agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
Comment 2 Matthew Saltzman 2007-01-20 22:55:49 EST
Looks like the agpgart messages have to do with switching from VC to X and back. The gnome-power-manager messages are the new ones that appear when the screen blanks and resumes. They did not appear before upgrading the kernel. BTW, gnome-power-manager is 2.16.0-4.fc6, installed in November.
Comment 3 Jon Stanley 2008-01-07 20:54:56 EST
(This is a mass-update to all current FC6 kernel bugs in NEW state) Hello, I'm reviewing this bug list as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug, however this version of Fedora is no longer maintained. Please attempt to reproduce this bug with a current version of Fedora (presently Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a few days if there is no further information lodged. Thanks for using Fedora!
Comment 4 Matthew Saltzman 2008-01-07 21:32:26 EST
This issue persists with F8 kernel-188.8.131.52-85.fc8. In addition, the brightness seems to change randomly back to the default value set in gnome-power-manager preferences. So I can change it manually with function keys, but it will change back after some short interval of idleness.
Comment 5 Jon Stanley 2008-01-07 21:46:44 EST
Changing version to F8. I'm thinking that this may be a gnome-power-manager issue rather than a kernel issue. Reassigning there in order to get their input.
Comment 6 Jon Stanley 2008-01-07 21:47:28 EST
forgot to click the reassignment button
Comment 7 Matthew Saltzman 2008-01-07 22:17:28 EST
Seems like a reasonable conjecture, except for the fact that the behavior originally appeared with a kernel update that did not affect g-p-m or pm-utils. We'll see...
Comment 8 Matthew Saltzman 2008-03-27 09:28:43 EDT
kernel-184.108.40.206-50.fc8.x86_64 gnome-power-manager-2.20.0-6.fc8.x86_64 OK I think this is what's going on. g-p-m is behaving as intended, but its intentions are warped. Actual behavior: - Screen is set to default brightness. - Screen dims after idle (I have that option set), but not to the lowest setting. - I change the brightness manually (brightness applet or function keys). - Next time the screen dims, when it resumes, it resumes to the default setting, not the last manual setting. - Same if the screen blanks or the backlight goes off in screensaver mode or suspend or hibernate. If I'm working in dim conditions, I may set the screen brightness lower than the "dim" setting. In that case, the screen gets brighter at idle, and brightens to the default setting when I resume. Behavior I would consider correct: - On login, screen assumes default setting - Screen dims on idle to lowest setting (if the option is enabled) - If I reset the brightness manually, the screen always resume to the last manually set level (until logout), whether from dim-on-idle, blank screen, or backlight off. I don't have an opinion on whether a manual setting should be preserved across suspend or hibernate.
Comment 9 Matthew Saltzman 2008-05-17 04:10:54 EDT
Some more data on actual behavior. If I deselct the auto-dim option, I get the following behavior: - I dim the screen. - After some idle time, the screen reverts to its default level. - After some more time, the screen blanks. - On wake-up, the screen is at default level. Expected behavior: - I dim the screen. - After sime idle time, the screen stays where I set it. - After some more time, the screen blanks. - On wake-up, the screen is at the last level I set. Current packages: gnome-power-manager-2.20.0-6.fc8.x86_64 pm-utils-0.99.4-6.fc8.x86_64 kernel-220.127.116.11-92.fc8.x86_64
Comment 10 Richard Hughes 2008-09-17 06:12:55 EDT
Do the packages in rawhide make things work better? I've tried to make g-p-m always respect the users brightness setting rather then preferring the policy.
Comment 11 Bug Zapper 2008-11-26 02:09:06 EST
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Bug Zapper 2009-01-08 23:35:32 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.