This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 475408

Summary: T60 brightness control broken in F10
Product: [Fedora] Fedora Reporter: Chris Snook <csnook>
Component: hal-infoAssignee: Richard Hughes <richard>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 10CC: bugzillaredhat-56f0, dchepishev, humufr, ivazqueznet, jbastian, j.golderer, kevin, rhughes, richard
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-18 02:13:17 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Chris Snook 2008-12-08 23:02:26 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):
tpb-0.6.4-10.fc9.x86_64

How reproducible:
Haven't tried

Steps to Reproduce:
1. Install Fedora 9
2. Observe that brightness controls work automagically
3. Install Fedora 10

Actual results:
Light and volume controls still work, but brightness controls do not.

Expected results:
Brightness controls work, at least when other tpb features are working.

Additional info:
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.
Comment 1 Ignacio Vazquez-Abrams 2008-12-08 23:16:43 EST
I thought we were moving towards hal handling the keymapping, and g-p-m doing the actual backlight frobbing.
Comment 2 Kevin Fenzi 2008-12-08 23:39:51 EST
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?
Comment 3 Chris Snook 2008-12-08 23:55:32 EST
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?
Comment 4 Chris Snook 2008-12-09 00:07:14 EST
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.
Comment 5 Kevin Fenzi 2008-12-09 00:32:21 EST
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.
Comment 6 Jeff Bastian 2008-12-18 21:46:31 EST
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
  http://people.freedesktop.org/~hughsient/quirk/quirk-backlight-index.html
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):
  $ acpi_listen
  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.)
Comment 7 Deian 2009-01-08 08:27:56 EST
Hello,

I have the same problem on Thinkpad R61.
While on Fedora 8 brightness buttons were working.
Comment 8 Roberto Ragusa 2009-01-11 09:52:11 EST
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).*
action=/etc/acpi/actions/ROB_brightness.sh "%e"
[root@thinkpad /]# cat /etc/acpi/actions/ROB_brightness.sh
#!/bin/bash

if [ x"$1" = x"video LCD0 00000086 00000000" ]; then
  cd /sys/devices/virtual/backlight/acpi_video1/ || exit 1
  b=`cat actual_brightness`
  if [ $b -ge 0 -a $b -lt 15 ]; then
    echo "$[b+1]" >brightness
  fi
elif [ x"$1" = x"video LCD0 00000087 00000000" ]; then
  cd /sys/devices/virtual/backlight/acpi_video1/ || exit 1
  b=`cat actual_brightness`
  if [ $b -gt 0 -a $b -le 15 ]; then
    echo "$[b-1]" >brightness
  fi
fi


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....
action=/etc/acpi/actions/ROB_keys.sh "%e"
[root@thinkpad /]# cat /etc/acpi/actions/ROB_keys.sh
#!/bin/bash

if [ x"$1" = x"ibm/hotkey HKEY 00000080 00001018" ]; then #thinkvantage
  sync
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001014" ]; then #zoom
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001001" ]; then #Fn F1
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001002" ]; then #Fn F2
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001003" ]; then #Fn F3
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001004" ]; then #Fn F4
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001005" ]; then #Fn F5
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001006" ]; then #Fn F6
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001007" ]; then #Fn F7
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001008" ]; then #Fn F8
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 00001009" ]; then #Fn F9
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 0000100a" ]; then #Fn F10 (unsupported?)
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 0000100b" ]; then #Fn F11
  true
elif [ x"$1" = x"ibm/hotkey HKEY 00000080 0000100c" ]; then #Fn F12
  true
fi


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.
Comment 9 Richard Hughes 2009-01-13 10:10:48 EST
(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.

It should.

> 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.
Comment 10 Jeff Bastian 2009-01-13 11:55:18 EST
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.
Comment 11 Jeff Bastian 2009-01-13 12:07:00 EST
I added my workaround from comment #10 to this Guidance Power Manager bug
  https://bugs.kde.org/show_bug.cgi?id=176485
Comment 12 Roberto Ragusa 2009-01-13 17:13:25 EST
(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
> kpowersave.

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
while true{get_event();sleep(0.5s);}
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
running.

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.
Additional examples:
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.
Comment 13 Deian 2009-02-24 17:19:55 EST
Hi again,

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 ?
Comment 14 humufr 2009-07-11 04:47:34 EDT
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.
Comment 15 Bug Zapper 2009-11-18 07:40:58 EST
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2009-12-18 02:13:17 EST
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.