Red Hat Bugzilla – Bug 475408
T60 brightness control broken in F10
Last modified: 2009-12-18 02:13:17 EST
Description of problem:
Brightness controls don't work in Fedora 10 on my Thinkpad T60. They work fine in Fedora 9.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Fedora 9
2. Observe that brightness controls work automagically
3. Install Fedora 10
Light and volume controls still work, but brightness controls do not.
Brightness controls work, at least when other tpb features are working.
I vaguely recall some discussion on fedora-devel or fedora-kernel-list of handling this in the kernel, but clearly the kernel isn't handling it, so we need to handle it in userspace.
My system dual-boots F9 and F10, so I can switch back and forth for diagnostics if necessary.
I thought we were moving towards hal handling the keymapping, and g-p-m doing the actual backlight frobbing.
Indeed we are...
I am probibly going to orphan tpb soon. I don't use a thinkpad anymore, and it should not be used anymore.
Chris: are you really using tpb? Or are you just having an issue with hal is not handling your keys right?
I'm using tpb for volume control and thinklight control. In Fedora 9, it controlled the backlight too. Now it does not.
I have no idea what's going on with hal, but absolutely nothing is happening when I hit the brightness keys.
Is g-p-m supposed to be gnome-power-manager? I'm using KDE, with the guidance power manager. Do I have to use Gnome now to get brightness control?
I just went to System Settings -> Keyboard Shortcuts, and selected Guidance Power Manager. When I try to set the key combo to fn+Home or fn+End, nothing happens, so I think something is intercepting and ignoring the key combo. The defaults are "Launch (5)" and "Launch (6)" respectively, and I can't figure out anything that triggers them.
I set them to Win+Home and Win+End, and when I press them, the tpb HUD pops up and shows the brightness level, so tpb clearly knows that something is going on.
I have a workaround, but it's annoying that it used to work out of the box, and now it doesn't.
Feel free to reassign to HAL if this is supposed to be handled there now.
Yeah, my understanding is that hal catches these at a lower level.
tpb shouldn't ever enter the picture anymore.
See also: bug 475247 which also is a thinkpad under kde... perhaps they are related?
reassigning to hal-info.
Hopefully it can get tracked down.
I also have this problem with a Lenovo T60. I'm not using tpb.
I do have two laptop_panel devices according to lshal which is a problem according to
However, if I 'rmmod video', then it leaves me with 0 laptap_panel devices. Under Fedora 8, it left me with 1 and the buttons worked.
I have the thinkpad_acpi kernel module loaded, and acpi_listen shows events when I hit Fn+Home (brightness up) and Fn+End (brightness down):
video LCD0 00000086 00000000
video LCD0 00000087 00000000
Nothing happens, though; that is, the brightness doesn't change.
Fortunately, I can still manually adjust the brightness with
$ sudo sh -c 'echo 4 > /sys/devices/virtual/backlight/acpi_video1/brightness'
(Change 4 to any number 0-7 for darkest to brightest.)
I have the same problem on Thinkpad R61.
While on Fedora 8 brightness buttons were working.
Same problem for me on a T61p when going from F9 to F10:
2 panels reported, tpb running.
Running xev shows XF86MonBrightnessUp and XF86MonBrightnessDown,
which apparently nothing takes care of.
One workaround is to launch gnome-power-manager, but it is slow and
I dont' want to run GNOME daemons inside KDE (my F10 runs KDE3 from F8).
Another workaround is to use acpid.
acpi_listen shows that events are generated:
video LCD0 00000086 00000000
video LCD0 00000087 00000000
so we can route them to a proper script, for example:
[root@thinkpad /]# cat /etc/acpi/events/ROB_brightness.conf
# React to brightness keys
event=video LCD0 0000008(6|7).*
[root@thinkpad /]# cat /etc/acpi/actions/ROB_brightness.sh
if [ x"$1" = x"video LCD0 00000086 00000000" ]; then
cd /sys/devices/virtual/backlight/acpi_video1/ || exit 1
if [ $b -ge 0 -a $b -lt 15 ]; then
echo "$[b+1]" >brightness
elif [ x"$1" = x"video LCD0 00000087 00000000" ]; then
cd /sys/devices/virtual/backlight/acpi_video1/ || exit 1
if [ $b -gt 0 -a $b -le 15 ]; then
echo "$[b-1]" >brightness
It is also interesting to detect other keys which do not always
generate events in xev.
Best of all, as acpid runs as root everything is possible.
(I have to think about a good use for them)
[root@thinkpad /]# cat /etc/acpi/events/ROB_keys.conf
# React to some keys.
event=ibm/hotkey HKEY 00000080 0000....
[root@thinkpad /]# cat /etc/acpi/actions/ROB_keys.sh
if [ x"$1" = x"ibm/hotkey HKEY 00000080 00001018" ]; then #thinkvantage
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001014" ]; then #zoom
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001001" ]; then #Fn F1
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001002" ]; then #Fn F2
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001003" ]; then #Fn F3
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001004" ]; then #Fn F4
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001005" ]; then #Fn F5
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001006" ]; then #Fn F6
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001007" ]; then #Fn F7
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001008" ]; then #Fn F8
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001009" ]; then #Fn F9
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 0000100a" ]; then #Fn F10 (unsupported?)
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 0000100b" ]; then #Fn F11
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 0000100c" ]; then #Fn F12
I know the scripts are a bit hackish, but it was a two minutes job.
Tpb gives me the OSD, but it is just reacting to the brightness
changes, not causing them.
Another related change from F9 to F10 is that the volume keys
now work perfectly as the XF86AudioRaiseVolume and XF86AudioLowerVolume
keys are handled by some KDE thing which runs kmix.
On F9 I had to use
xmodmap -e 'keycode 174 = F21'
xmodmap -e 'keycode 176 = F22'
and configure kmix to react to F21 and F22.
No idea about what happens with KDE 4.
(In reply to comment #8)
> Same problem for me on a T61p when going from F9 to F10:
> 2 panels reported, tpb running.
tpb is obsolete.
> Running xev shows XF86MonBrightnessUp and XF86MonBrightnessDown,
> which apparently nothing takes care of.
> One workaround is to launch gnome-power-manager, but it is slow and
> I dont' want to run GNOME daemons inside KDE (my F10 runs KDE3 from F8).
Sure, you probably want to file a bug with guidance-power-manager or kpowersave.
> Another workaround is to use acpid.
which is soon to be obsolete.
Using the idea from comment #8, I have a workaround until Guidance Power Manager is fixed.
I found using xev on my T60 that
Fn+Home = keycode 233 = XF86MonBrightnessUp
FN+End = keycode 232 = XF86MonBrightnessDown
I then mapped these to F21 and F22
xmodmap -e 'keycode 233 = F21'
xmodmap -e 'keycode 232 = F22'
And in KDE4's System Settings -> Keyboard & Mouse -> Keyboard Shortcuts, under the "KDE Component: Guidance Power Manager", I changed Brightness Down to F22 and Brightness Up to F21.
Now I can change brightness on my T60 using Fn+Home and Fn+End.
I added my workaround from comment #10 to this Guidance Power Manager bug
(In reply to comment #9)
> (In reply to comment #8)
> > Same problem for me on a T61p when going from F9 to F10:
> > 2 panels reported, tpb running.
> tpb is obsolete.
OK, I was just reporting my environment.
> > Running xev shows XF86MonBrightnessUp and XF86MonBrightnessDown,
> > which apparently nothing takes care of.
> It should.
OK, never said it shouldn't. Having events is good.
> > One workaround is to launch gnome-power-manager, but it is slow and
> > I dont' want to run GNOME daemons inside KDE (my F10 runs KDE3 from F8).
> Sure, you probably want to file a bug with guidance-power-manager or
I just discovered I was not running kpowersave, but klaptop, which has
a similar "monitor" (little icon).
I switched to kpowersave and there is no bug, it actually works.
FWIW, when I said g-p-m is slow, I meant it looks like
it takes too much time to go from level 0 to level 15 or back.
> > Another workaround is to use acpid.
> which is soon to be obsolete.
But it is the only way to have brightness control when X is not
I hate the "desktop everything" or worse "GNOME everything"
approach often assumed in recent times.
Some things should be system wide and not bound to
a graphical session.
NetworkManager - should network be usable without X? yes!
pulseaudio - should sound be usable without X? yes!
So I will not disable the acpi script, just steal the
smart idea implemented in power.sh: refuse
to do anything when g-p-m or kpowersave are running.
Guys I really dont understand why would anyone break this functionality.
Under Fedora 8, brightness control was working in non graphical mode too.
Why should it not work in FC10. This does not look like improvement as one would expect. Is it that hard to fix it ?
Bug still present in F11 and the workaround doesn't work because there are no guidance-power-manager in the panel anymore. you can change the brightness with the mouse using the plasmoid but not very cool. The really funny thing is that I was trying to install F11 because I was tired of the very poor quality of KDE in Kubuntu and now I can see that is the same with Fedora. This bug doesn't exist on kubuntu. I don't know why they probably miss it and they will add it at the next release... I know I am mean but all the different bug I followed in this distribution none have been corrected in 2 years or they have been because upstream did it but not because of launchpad/kubuntu people because I used bugzilla upstream to explain the bug and 2 or 3 days later it was done.
I will keep F11 a little bit on my hard drive but I do not think it will stay a long time. I will probably test Mandriva or Arch after. I really want to find a good distribution wich provide a nice KDE experience and the two most important are not giving it to me.
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. 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 '10'.
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 10'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 10 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:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.