Bug 475408
Summary: | T60 brightness control broken in F10 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Snook <csnook> |
Component: | hal-info | Assignee: | Richard Hughes <richard> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | 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 07:13:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Chris Snook
2008-12-09 04:02:26 UTC
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 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.) Hello, 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).* 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. (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. 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 https://bugs.kde.org/show_bug.cgi?id=176485 (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. 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 ? 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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. |