Bug 223621 - Thinkpad screen brightness changes on resume from blank
Summary: Thinkpad screen brightness changes on resume from blank
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-power-manager
Version: 8
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Zeuthen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 427887
TreeView+ depends on / blocked
 
Reported: 2007-01-20 22:06 UTC by Matthew Saltzman
Modified: 2013-03-06 03:48 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-09 04:35:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
xorg.conf (1.56 KB, text/plain)
2007-01-20 22:06 UTC, Matthew Saltzman
no flags Details

Description Matthew Saltzman 2007-01-20 22:06:28 UTC
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 1 Matthew Saltzman 2007-01-20 22:06:29 UTC
Created attachment 146063 [details]
xorg.conf

Comment 2 Matthew Saltzman 2007-01-21 03:55:49 UTC
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-08 01:54:56 UTC
(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-08 02:32:26 UTC
This issue persists with F8 kernel-2.6.23.9-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-08 02:46:44 UTC
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-08 02:47:28 UTC
forgot to click the reassignment button

Comment 7 Matthew Saltzman 2008-01-08 03:17:28 UTC
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 13:28:43 UTC
kernel-2.6.24.3-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 08:10:54 UTC
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-2.6.24.7-92.fc8.x86_64


Comment 10 Richard Hughes 2008-09-17 10:12:55 UTC
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 07:09:06 UTC
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-09 04:35:32 UTC
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.


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