EeePC Volume and Wireless Hotkeys Do Not Function Out-Of-The-Box with Ubuntu (8.04 Hardy LTS, Intrepid Alpha 1)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | CentOS |
Fix Released
|
Unknown
|
||
| | Fedora |
Fix Released
|
Unknown
|
||
| | Mandriva |
Fix Released
|
High
|
||
| | acpi-support (Debian) |
Fix Released
|
Unknown
|
||
| | acpi-support (Ubuntu) |
Undecided
|
Unassigned | ||
| | linux (Ubuntu) |
Medium
|
Andy Whitcroft | ||
Bug Description
The Asus EeePC is a popular subnotebook computer.
With a fresh install of Ubuntu 8.04 LTS (Hardy Heron) the wireless (fn+f2) and volume hotkeys (fn+f7/f8/f9) do not function.
Expected function:
fn+f2: Toggle wireless
fn+f7: Mute/Unmute
fn+f8: Volume up
fn+f9: Volume down
Workarounds are documented here:
Wireless Hotkey: http://
Volume Hotkeys: http://
Although I have not had much success at getting these working myself.
It would be great if these would work out-of-the-box with 8.04.1 or Intrepid.
| merc (escalated) wrote : | #1 |
| Michael Craft (holographicpizza) wrote : | #2 |
I can also confirm this.
| elmurato (elmurato87) wrote : | #3 |
Installing this package fixes it also: http://
Works with Xubuntu and Ubuntu. Kubuntu not tested...
| Jeff Sereno (jsereno) wrote : | #4 |
I note that for some reason, even with the eee-osd fix to get the hotkeys going, Ubuntu Hardy on my EeePC 701 does not save the volume level upon a reboot, and starts up again with the volume at 100%. This is probably unrelated to the hotkeys themselves, however.
| Matt Austin (mattaustin) wrote : | #5 |
Confirming that this is still an issue in Intrepid Ibex Alpha 1.
| Changed in acpi-support: | |
| status: | Unknown → Fix Released |
| Matt Austin (mattaustin) wrote : | #6 |
All hotkeys (sleep, wireless, brightness, volume) are not working in Intrepid Ibex Alpha 4 (with latest updates, 2.6.27-1-generic).
| Leann Ogasawara (leannogasawara) wrote : | #7 |
The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:
1) If you are comfortable installing packages on your own, the linux-image-
--or--
2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://
Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.
Tested my EeePC 701 (4G) with Intrepid Alpha 5. The function keys are still not working as expected:
Fn+F1 Standby Works
Fn+F2 WiFi-enable Does not work
Fn+F3/F4 Brightness control Works but with a lot of lag, not as responsive as usual
Fn+F5 VGA-toggle Does Volume up?!
Fn+F6 Task-Manager Does not work
Fn+F7 Mute/Unmute Does not work
Fn+F8 Volume down Does not work
Fn+F9 Volume up Does not work
| Lapppi (k-jenkins) wrote : | #9 |
Tested on EeePC 701 4G using the latest daily build of Intrepid.
Confirm findings as indicated by Paulo Albuquerque in his report.
| bedfojo (commercial-johnbedford) wrote : | #10 |
I can confirm that this bug still exists on Intrepid fully updated to 15 September 2008 on an EEE PC 701 4G.
| Adam McDaniel (adamrmcd) wrote : | #11 |
Confirming what bedfojo results on my EeePC 900.
Also, another oddity experienced in Hardy still exists in Intrepid related to ACPI hotkeys: Plugging in the AC adapter still triggers an ACPI event similar to an 'E-Mail' hotkey; Evolution launches.
| bedfojo (commercial-johnbedford) wrote : | #12 |
Indeed, in addition to Adam Mc Daniel's comment, I note a regression in Intrepid from Hardy/Gutsy in that none of the scripts on the internet (see http://
| rayhaque (rayhaque) wrote : | #13 |
I have a 701 4G Surf. I'm running the latest "daily" of Intrepid - updated this morning. Confirming that hot-keys do not work.
F1 (Suspend) disables networking momentarily, and then restores it. Here is what I catch in /var/log/messages ...
Sep 17 10:12:24 ray-laptop gnome-power-
Sep 17 10:12:29 ray-laptop kernel: [ 208.652012] ADDRCONF(
Sep 17 10:12:29 ray-laptop kernel: [ 208.826229] ADDRCONF(
Sep 17 10:12:29 ray-laptop kernel: [ 208.826448] ADDRCONF(
Sep 17 10:12:29 ray-laptop gnome-power-
F2 (Wireless Toggle) - Pressing has no effect, no logged output.
F3/F4 (Brightness) - Work fine!
F5 (External display toggle), F6 (application button) - No desired effect, no fault found.
F7 (mute), F8 (Volume up), F9 (Volume down) - No effect, no logged output.
Should these hotkeys be controlled with the eeepc_laptop driver? I cannot find an answer on this anywhere. It seems that eeepc-acpi has been deprecated in favor of this new module. If that is the case, is there a better place to report eeepc_laptop bugs? I will do whatever I can to help this effort. :-)
rayhaque(at) Gmail(dot) com.
| rayhaque (rayhaque) wrote : | #14 |
I meant to include that running the latest Intrepid, I am also running the newest Kernel release ....
ray@ray-laptop:~$ uname -a
Linux ray-laptop 2.6.27-3-generic #1 SMP Wed Sep 10 16:02:00 UTC 2008 i686 GNU/Linux
| Changed in linux: | |
| assignee: | nobody → ubuntu-kernel-team |
| importance: | Undecided → Medium |
| status: | Confirmed → Triaged |
| Sitsofe Wheeler (sitsofe) wrote : | #15 |
Fedora have a fix for the volume keys that works for my upstream kernel too - https:/
| Adam McDaniel (adamrmcd) wrote : | #16 |
Any idea when/if Matthew Garrett's patch (re: Redhat bug 451182) will make it in Intrepid's base kernel?
I'm in the midst of compiling it for my 900 now. I'll post a summary with the results.
| Sitsofe Wheeler (sitsofe) wrote : | #17 |
Adam:
I don't know what the Ubuntu policy is to kernel patches is at the moment - it apparently isn't frozen yet... - https:/
| Olivier Samyn (olivier-oleastre) wrote : | #18 |
Following Sitsofe suggestion, I tried Matthew's patch on my eeepc 701.
At least, I get the volume keys working.
I still have issues with the wireless and display one; that needs some investigations.
I also noticed that this patch activates the wifi card when loaded.
| Sitsofe Wheeler (sitsofe) wrote : | #19 |
Oliver:
The display one is going to be problematic. These days you are expected to switch displays when X is running by using xrandr rather than poking the BIOS behind X's back (so really the key should be passed to a running program that then does the switch). You could argue that not having a means to do that is a separate bug from this though.
Re wifi always activated on boot, yes I noticed that too. You're absolutely right. It's not hard to toggle off again though.
What other issues were you having with the Wireless hotkey though? You are using pciehp_force too?
| Olivier Samyn (olivier-oleastre) wrote : | #20 |
Current problems (still need further investigations):
- Display button make the volume to go up. Maybe a bad key configuration somewhere.
- Wireless button does not do anything; wireless is turned on when the module is loaded but nothing happens when I press the toggle off button. And yes, I'm using pciehp_force=1.
| Adam McDaniel (adamrmcd) wrote : | #21 |
BTW, I've added bluetooth control (a very minor change) to eeepc-laptop.ko, based upon more recent (and deprecated) eeepc-acpi.ko code to my local clone of ubuntu-
commit e3c8316f0a41fde
Author: Adam McDaniel <>
Date: Mon Sep 22 16:53:06 2008 -0600
EEEPC: Added bluetooth attribute to /sys/devices/
accessible through eeepc-laptop module, just like deprecated eeepc-acpi module.
Eventually this can be used to switch the built-in bluetooth radio on/off in this eeepc-laptop module, too, without the need of user-space ACPI scripts. Unfortunately, I cannot test this patch directly as I don't have an EeePC 901/1000/1000h.
If someone with one could apply it and verify if "/sys/devices/
| Sitsofe Wheeler (sitsofe) wrote : | #22 |
Oliver:
Hmm. Does using
echo 0 > /sys/class/
with the patch applied also fail to turn the wifi off?
| Olivier Samyn (olivier-oleastre) wrote : | #23 |
Echoing 0/1 to /sys/class/
Any advice if I should look in the eeepc-laptop module or in some keyboard configuration stuff ?
That said it's fun to see that without the eeepc-laptop module loaded, the FN+F2 key works out of the box. Other keys do not work, but that's another problem.
| Sitsofe Wheeler (sitsofe) wrote : | #24 |
Olivier:
Do you have another module loaded which is also trying to do hotkeys (e.g. a hacked up asus-apci)?
| Olivier Samyn (olivier-oleastre) wrote : | #25 |
I found the problem; but from latest xorg developments, it does not seem to be easily solved: http://
In fact the wireless hotkey is working well when used in console mode, but when xorg with evdev is launched, it prevents rfkill_input to grab KEW_WLAN events and everything stops working.
It seems there are may be some ways to get hal doing the job: https:/
| Olivier Samyn (olivier-oleastre) wrote : | #26 |
After some more tests, the display button works well, and emits XF86Display event which is OK (except that if you do not bind this key to some desktop events, it is used a volume up).
So, Mattew's patch is working well on a eeepc 701, given that you tweak a little bit you modules:
- load pciehp with pciehp_force=1
- load rfkill_input (although that one only works if you switch to the console)
Seems this patch has been submitted upstream: http://
| Bryce Harrington (bryce) wrote : | #27 |
This has a task open against acpi-support, however are there actually any changes needed to this package for this? Sounds like this problem may be entirely a kernel issue?
| Sitsofe Wheeler (sitsofe) wrote : | #28 |
Bryce:
The unpatched eeepc module sends volume keys ass acpi events (which are currently mismapped in Ubuntu). You can work around this by changing acpi scripts. Matthew's patch send keys through the input layer doing away with ACPI altogether. Two approaches to solving the problem but I'd say Matthew's is cleaner and likely to go upstream at some point.
| bedfojo (commercial-johnbedford) wrote : | #29 |
As regards the Fedora patch, the "the caveat that wifi will always be enabled on boot" would be a major regression for me.
I use my eeepc a lot on aircraft and in order to comply with the law, it should not use wifi at all in the air. I should be able to ensure that the machine will boot with wireless switched off.
| Olivier Samyn (olivier-oleastre) wrote : | #30 |
Adding:
options rfkill default_state=0
in:
/etc/modprobe.
Should disable the wifi transmitter at boot time (in fact when the rfkill module loads).
| Sitsofe Wheeler (sitsofe) wrote : | #31 |
A quick note, in testing against linux-tip the Red Hat bugzilla patch breaks the resume part of suspend to RAM on my EeePC 900...
| Sitsofe Wheeler (sitsofe) wrote : | #32 |
Oliver:
Turns out there is a kernel bug that stops rfkill hotkeys working for the first five minutes after boot (!) so that may explain why the wifi hotkey was failing for you. See http://
| Olivier Samyn (olivier-oleastre) wrote : | #33 |
I also noticed some strange behavior just after boot; and the patch for rfkill_input may solve it.
But there is another problem coming from the way key events are processed: xorg evdev driver catch all input events and rfkill_input do not see them anymore when under X.
If I switch in console mode, everything works fine.
| Christopher (chriruud) wrote : | #34 |
Adam: on the 1000, doing "echo 0 |sudo tee /sys/devices/
Doing a cat eeepc/bt returns -19 every time, so it seems like it either is a permissions problem or something else.
So far, with all the patches I've yet to see, wlan, bluetooth and volume up/down/mute won't work, neither with acpi - scripts or via modules. No evidence in any log to sugest they were ever pressed either.
| elmurato (elmurato87) wrote : | #35 |
I can confirm the BT bug with my 901. A "cat /sys/devices/
And I have anpther problem: Everytime I use the command with rfkill to toggle my wifi card the whole machine just freezes. That is very annoying...
Camera toggle works...
| Robin Sheat (eythian) wrote : | #36 |
On an install of Intrepid, the volume keys are still invisible to X. There is a package 'eeepc-
| Robin Sheat (eythian) wrote : | #37 |
I plan to do some experimenting with this, but in /etc/acpi/
action=
however:
robin@gulik:~$ /etc/acpi/
bash: /etc/acpi/
| Robin Sheat (eythian) wrote : | #38 |
So, my experimentation bears fruit. I created a file (for test purposes, it's clearly not a global solution):
robin@gulik:
#!/bin/bash
`dirname $0`/$1
which doesn't really test to see if it is an eeepc, it just runs the command anyway. Now my volume (mute, vol up, vol dn) work just fine. Wireless doesn't (sleep and brightness always have.)
| Robin Sheat (eythian) wrote : | #39 |
Clarification: the wireless button doesn't work, wireless itself appears to.
Is there a way to see what signals hotkeys raise? It might just be that it needs its own event file with a particular event= definition. I just have no idea how to find out what that should be.
| Sitsofe Wheeler (sitsofe) wrote : | #40 |
Eythian:
You aren't going to be able to get the wireless hotkey working without support within the kernel itself (support that is not in the released Intrepid kernel) or some pretty nasty hacks (assuming it emits an ACPI event). You can try monitoring the acpi log file to see whether this is the case.
| Olivier Samyn (olivier-oleastre) wrote : | #41 |
Matthew Garrett posted some news about the eeepc wifi on his blog
=>http://
And he propose a new patch I did not already tested:
=> http://
| Olivier Samyn (olivier-oleastre) wrote : | #42 |
I merged last Matthew's patch with previous one (making hot key and rfkill working toegether).
It works well for me (except this nasty xorg bug that prevents rfkill input capture but it's another problem...)
This new version allows me to start with rfkill default_state=0 (wireless disabled) and enable it manually after boot.
| Sitsofe Wheeler (sitsofe) wrote : | #43 |
Olivier:
I believe later versions of evdev will no longer grab the device by default - http://
| Olivier Samyn (olivier-oleastre) wrote : | #44 |
Yes it solves the problem...
I think I now have a fully functional intrepid on my eeepc 701...
Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https:/
| Panagiotis Astithas (pastith) wrote : | #46 |
Since I don't see it answered before, I'd like to confirm that Adam's change in eeepc-config for controlling the Bluetooth device works for me with a EEE PC 901. Now if I could just map the relevant hotkey to toggle wifi & bluetooth I'd be a happy camper.
| Christopher (chriruud) wrote : | #47 |
pana: upgrade to evdev 2.1 to stop the trapping of the hotkeys.
| Panagiotis Astithas (pastith) wrote : | #48 |
I have version 2.0.99+
| Luis Silva (lacsilva) wrote : | #49 |
Ok! With the last jaunty I had to add pciehp.
options rfkill default_state=0
to /etc/modprobe.
All this for the Asus eeepc 701 4G.
| Luis Silva (lacsilva) wrote : | #50 |
| Sitsofe Wheeler (sitsofe) wrote : | #51 |
Forcing pciehp will no longer be required for current eeepcs when mjg59's patch goes into the mainline kernel (this also speeds up resuming from suspend) - http://
| Olivier Samyn (olivier-oleastre) wrote : | #52 |
This last patch from mjg59 is the only missing part to get a working out of the box eee 701.
Adding it to the kernel package should be really a nice.
| Steve Langasek (vorlon) wrote : | #53 |
The right place to fix this is in the kernel; marking the acpi-support task as 'invalid'.
| Sitsofe Wheeler (sitsofe) wrote : | #54 |
mjg59's "no pciehp required" patch appears to have gone into 2.6.29 ( http://
| Olivier Samyn (olivier-oleastre) wrote : | #55 |
Any chance a backport of the last Matthew Garrett's patch (mentioned here above by Sitsofe) get in the Jaunty release ?
Or will we have to patch it our self and wait for Karmic ?
If there is something missing for this patch to get in, let me know what it is...
| Andy Whitcroft (apw) wrote : Re: [Bug 232170] Re: EeePC Volume and Wireless Hotkeys Do Not Function Out-Of-The-Box with Ubuntu (8.04 Hardy LTS, Intrepid Alpha 1) | #56 |
On Wed, Mar 04, 2009 at 09:07:01AM -0000, Olivier Samyn wrote:
> Any chance a backport of the last Matthew Garrett's patch (mentioned here above by Sitsofe) get in the Jaunty release ?
> Or will we have to patch it our self and wait for Karmic ?
Is this patch the only thing required to make eepc volume and wireless
work correctly on Jaunty?
| Changed in linux: | |
| assignee: | nobody → apw |
| status: | Triaged → In Progress |
| Andy Whitcroft (apw) wrote : | #57 |
I have pulled that patch and applied it to the latest Jaunty kernel. Could those with this hardware test the kernels at the URL below and report back here, specifically whether the hotkeys etc work as expected. The kernels are here:
| Sitsofe Wheeler (sitsofe) wrote : | #58 |
Andy:
The last patch I referred to is for wifi only and has nothing to do with volume keys. It is solely so that wifi works out of the box (hotplugging and all) without having to add special options to the kernel command line.
Be careful though - the patch in its current state will break those who are using the workaround (see http://
| Olivier Samyn (olivier-oleastre) wrote : | #59 |
Andy:
With your kernel build, wireless , sound, brightness and sleep keys work OK ( just as fine as the custom build I used) on my eeepc 701.
The only change I need to get everything working out of the box is to add rfkill_input to /etc/modules (maybe some hal magic should do it for me somewhere).
So I suppose with this patch applied and delivered with Ubuntu's kernel, this patch may be closed.
To answer to Sitsofe remark: I see two possibilities to address the pciehp_force=1 problem:
- Either, Matthew proposed patch to work around this problem should also be applied ( http://
- Or, as this option is not installed by any package on Ubuntu, only people upgrading from intrepid (or another version) and who modified their grub configuration should be impacted (I suppose such guys should also be able to remove the option).
It's problematic on debian installation because it's added by the eeepc-acpi-scripts package. But this one is not installable in Ubuntu (see bugs #262679 and #328989).
| Leann Ogasawara (leannogasawara) wrote : | #60 |
Just adding a note that bug 182490 is also resolved with the patched noted in https:/
| Troy Ready (troyready) wrote : | #61 |
Just did a fresh install (with all updates) of Jaunty beta to test this on my Eee 901. Wifi toggle does not work out of the box, but modprobing rfkill-input causes it to work (indicator light goes on and off appropriately).
Unfortunately, when toggling the wifi back on, networkmanager always states that the "device not ready". I can't figure out how to re-enable it without rebooting.
| Jack Deslippe (jdeslip) wrote : | #62 |
I have the same problem as your Troy on my 901 when using eee-control to toggle wifi. The light goes on and off, but when it comes back on NM reports "device not ready" - You ever figure anything out?
| Troy Ready (troyready) wrote : | #63 |
jdeslip: I'm still stuck in the same situation as well.
| Sitsofe Wheeler (sitsofe) wrote : | #64 |
Troy:
Two things that it might be worth mentioning:
After you've done the toggling does
/usr/bin/sudo iwlist scan
report results?
The next thing is if so does restarting Network Manager
/etc/dbus/
help?
If the first thing doesn't even work it sounds like the wifi driver is wedged. Unloading and reloading it via modprobe might be a workaround but the issue should be reported in a separate bug if so.
| Olivier Samyn (olivier-oleastre) wrote : | #65 |
Troy, you said you did a fresh jaunty instal, did you patched your kernel, or installed the one proposed by andy (see here above) ?
| Troy Ready (troyready) wrote : | #66 |
I've tried it with a fresh install (now updated to Jaunty RC), and now just tried it with the Andy's kernel packages -- all have the same effect:
No response to the wireless toggle normally,
Inserting the rfkill-input module, the pushing the wireless toggle causes the wireless to toggle off properly (blue light goes off).
Pushing the wireless toggle again causes the light to come back on, but the wireless module fails to load. Unloading and then reloading the module has no effect (the module fails to load again).
I have attached the relevant sections of my syslog.
| Troy Ready (troyready) wrote : | #67 |
Whoa -- just tried it with a custom build of upstream 2.6.29.1 kernel. After inserting the rfkill-input module, the wireless toggle works 100% correctly (toggles off and on properly)!
| Olivier Samyn (olivier-oleastre) wrote : | #68 |
Inserting rfkill-input is necessary (I suppose some hal magic should insert it automatically); but for now, inserting it manually is required.
For the rest, I suppose your posted log is from a stock jaunty kernel.
The kernel from Andy should contain backport of the patches included in kernel 2.6.29. So either we forgot a patch somewhere, or another module changed in the kernel. (Also, on my 701 I blacklisted the atheros driver, ath_pci)
| Jack Deslippe (jdeslip) wrote : | #69 |
Will the patches from 2.6.29 in Andy's kernel make it into the regular jaunty kernel? What happens when there is an update?
| Troy Ready (troyready) wrote : | #70 |
Andy: I think I must have made a mistake before. I just did a fresh install of Jaunty RC (and applied all system updates). After installing your kernel packages, rebooting into the kernel (2.6.28-8 instead of the current 2.6.28-11), and inserting the "rfkill-input" module, wifi toggle works properly! Great work, and please include it in Jaunty if possible!
Is there any way to get the "rfkill-input" module added to /etc/modules automatically during setup?
| Sitsofe Wheeler (sitsofe) wrote : | #71 |
Rumour has it that rfkill-input will eventually be folded inside of rfkill at some point. One recommendation has been to build rfkill and rfkill directly into the kernel until that happens (otherwise you'll have to remember to edit /etc/modules one day to remove rfkill-input)...
| Troy Ready (troyready) wrote : | #72 |
Sitsofe: Good to know.
Unforunately, without it being addressed (either loaded at boot or statically compiled in), this bug won't be resolved. Can this be fixed for Jaunty? Karmic?
| Jack Deslippe (jdeslip) wrote : | #73 |
So it seems that wireless toggle works on stock jaunty install with the todays new eee-control. I am not sure what the dev to fix it - perhaps he replaced the driver or something?
| ben (joshua615) wrote : | #74 |
i'm sorry if it's a dumb question-- i'm running Andy's kernel with rfkill_input loaded on my asus eee 900, and my wireless is turned on at every system bootup: is there any way to prevent this, and make the wireless driver obey the bios setting?
| Fabian A. Scherschel (fabsh) wrote : | #75 |
With the latest Netbook Remix based on Jaunty (all updates, latest kernel) and rfkill_input loaded, I still have the broken Network Manager behaviour...
| Sitsofe Wheeler (sitsofe) wrote : | #76 |
Ben:
A bug report isn't really the best place to be asking general questions. Try one of the other support options: http://
| Andy Whitcroft (apw) wrote : | #77 |
This was fixed by two upstream commits which came through the stable process. Marking Fix Released. If you have any further issues it is probabally best to file a new bug. Thanks for your support.
| Usama Akkad (damascene) wrote : | #78 |
did this problem hit again with Lucid 10.04?
https:/
| Changed in mandriva: | |
| importance: | Unknown → High |
I can confirm that the wireless and volume hotkeys do not work(although I upgraded from 7.10 to 8.04, I made no configuration changes before upgrading)