Remaining brightness issue on Thinkpad T61

Bug #211687 reported by Jonathan Blackhall
8
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

First, I'd like to mention that this is not a duplicate of this bug:
https://bugs.launchpad.net/bugs/198476
That issue was fixed with yesterday's kernel update and my keyboard buttons do work to adjust my screen brightness. This is a related issue, however.

When on battery power, the screen tends to progressively dim itself. In Power Management I have checked the boxes for 'Reduce backlight brightness' and 'Dim display on idle'. When I unplug, the display dims (good) and when I leave it sit there for a minute or two, the screen dims a little more (I'm assuming this is 'dim display when idle'). Unfortunately when I move my mouse (where I'd expect the screen to brighten a little again by coming out of idle), the screen dims even more. It seems like someone put a call for brightness down where it should've been brightness up. But then again, I don't really know what I'm talking about in that area...

I have an Intel X3100 gpu on a Thinkpad T61 running Hardy 8.04 beta with todays upgrades. Please let me know if you need more information.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Jonathan,

I'd like to try and narrow down if this is actually a bug in the kernel or rather an issue with say gnome-power-manager or HAL. The reason I say this is because you mentioned that the keyboard buttons do properly control the brightness.

1) Could you capture your dmesg output after you witness the issue and then attach the output to this report?
2) Can you also please attach the resulting log file of: gnome-power-bugreport.sh &> gpm.log to the report?
3) Also, please take a look at the debugging instructions located at https://wiki.ubuntu.com/DebuggingGNOMEPowerManager and submit any other logs related to your problem.

Thanks in advance.

Changed in linux:
status: New → Incomplete
Revision history for this message
Raja (rajajs) wrote :

I can confirm the same issue with my Thinkpad x61s, remaining even after the update to kernel 2.6.24.15. As described above, a short idle period results in lcd dimming and resumption of activity with a click or mouse movement results in further dimming. Not more than a small annoyance at the moment, though. I did not notice anything in dmesg, but I am attaching the output of dmesg and gnome-power-bugreport.sh immediately after this happened.

Revision history for this message
Jonathan Blackhall (johnny-one-eye) wrote :

Thanks for your response and sorry for taking so long to get back to you. I was out of town for the weekend. I have never submitted a bug report before, so bear with me if I don't do something correctly :)

I would also like to add a few more things I have noticed about this problem. There actually is no need for the computer to be idle in order for the screen to randomly dim (it just happens quicker when it's idle). It has happened to me while I was actively moving the mouse and typing and surfing the internet. Also, using Fn+Home (brightness up) to restore the screen brightness will work, but then at a random amount of time later, it will dim again (sometimes even being idle). I am attaching 2 gdm logs. One after I restored brightness to a middle level (gdm-before.log). The other is after the screen dimmed again (gdm-after.log). Also a dmesg.txt (after the dimming) and gpm.gconf.values.txt. Please let me know what else I can do to help you.

Revision history for this message
Jonathan Blackhall (johnny-one-eye) wrote :
Revision history for this message
Jonathan Blackhall (johnny-one-eye) wrote :
Revision history for this message
Jonathan Blackhall (johnny-one-eye) wrote :
Revision history for this message
Jonathan Blackhall (johnny-one-eye) wrote :

Sorry for all the logs. I ran a gnome-power-bugreport right after boot. I then typed 'gnome-power-bugreport.sh &> gpm-bugrp-dim1.log' but didn't run it, just waited. As soon as the screen dimmed the first time (~25 seconds of idle time), I hit enter (causing it to dim all the way). I then ran the gpm bug report again and called it dim2.log. I restarted and did the same for dmesg. Dunno if that'll help, but they're all attached in a tar.gz.

Revision history for this message
Raja (rajajs) wrote :

For me, the issue is resolved with the latest updates in Hardy (kernel 2.6.24.16).

Revision history for this message
Jonathan Blackhall (johnny-one-eye) wrote :

I agree. This was fixed with 2.6.24.16.

Revision history for this message
Jonathan Blackhall (johnny-one-eye) wrote :

This bug was fixed with kernel 2.6.24.16

Changed in linux:
status: Incomplete → Fix Released
Revision history for this message
Davi Garcia (davivcgarcia-deactivatedaccount) wrote :

I'm still with this bug on my Thinkpad R61.

Revision history for this message
Roland Orre (roland-orre) wrote :

I'm running 2.6.24-21 (hardy heron and gnome) and I have a lot of trouble with the brightness on my Lenovo X61 T.

The most annoying is that each time the screen saver is activated I have to manually increase the brightness.
If I do e.g.
xset dpms force off
and after that the screen light is half.

I often turn the screensaver off to avoid this (the dim option is disabled in gnome power settings).

It is also very annoying with many video players.
As soon as I'm playing a video with e.g. vlc the backlight goes down to half. I have had the same problem with mplayer, but that seem to be resolved. xine is OK but gxine changes to half bright when going to full screen.

Further on I have no idea how to change the brightness with software, like having a cron script forcing the brightness up every 10 seconds...
Those /sys/class/backlight/
and /sys/devices/virtual/backlight/
have no effect whatsoever. If I change the backlight, those doesn't change. If I try to
write to them, the backlight doesn't change.
This is annoying.
I wish there an option somewhere, to set the backlight level to THIS level, and don't let any software touch it.

Revision history for this message
Roland Orre (roland-orre) wrote :

Maybe I should add that
/etc/acpi/video_brightnessup.sh
/etc/acpi/video_brightnessdown.sh
/etc/acpi/thinkpad-brightness-up.sh
/etc/acpi/thinkpad-brightness-down.sh

which do either
acpi_fakekey 224
acpi_fakekey 225
doesn't work either.
If I do acpi_listen
the fn-Home (brightness up key) gives
video LCD0 00000086 00000000

and the fn-End (brightness down key) gives
ibm/hotkey HKEY 00000080 00001011
video LCD0 00000087 00000000

which looks somewhat strange, I would expect one key/command for each.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.