EeePC Volume and Wireless Hotkeys Do Not Function Out-Of-The-Box with Ubuntu (8.04 Hardy LTS, Intrepid Alpha 1)

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)

I can also confirm this.

Installing this package fixes it also: http://code.google.com/p/eee-osd/
Works with Xubuntu and Ubuntu. Kubuntu not tested...

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.

Confirming that this is still an issue in Intrepid Ibex Alpha 1.

All hotkeys (sleep, wireless, brightness, volume) are not working in Intrepid Ibex Alpha 4 (with latest updates, 2.6.27-1-generic).

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-2.6.27-* package is currently available for you to install and test.

--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://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

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

Tested on EeePC 701 4G using the latest daily build of Intrepid.

Confirm findings as indicated by Paulo Albuquerque in his report.

I can confirm that this bug still exists on Intrepid fully updated to 15 September 2008 on an EEE PC 701 4G.

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.

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://wiki.eeeuser.com/getting_ubuntu_8.04_to_work_perfectly) now function to make the hotkeys work.

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-manager: (ray) Hibernating computer. Reason: The suspend button has been pressed.
Sep 17 10:12:29 ray-laptop kernel: [ 208.652012] ADDRCONF(NETDEV_UP): eth0: link is not ready
Sep 17 10:12:29 ray-laptop kernel: [ 208.826229] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sep 17 10:12:29 ray-laptop kernel: [ 208.826448] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Sep 17 10:12:29 ray-laptop gnome-power-manager: (ray) Resuming computer

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.

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

Fedora have a fix for the volume keys that works for my upstream kernel too - https://bugzilla.redhat.com/show_bug.cgi?id=451182 . It also enables support for the wifi hotkey too (with the caveat that wifi will always been enabled on boot and that you have to use the pciehp.pciehp_force=1 boot parameter). Very elegant too.

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.

Adam:
I don't know what the Ubuntu policy is to kernel patches is at the moment - it apparently isn't frozen yet... - https://wiki.ubuntu.com/IntrepidReleaseSchedule . Matthew's patch works well for me except every now and then the wifi hotkey will not work (but the sound ones will).

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.

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?

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.

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-intrepid.git:

commit e3c8316f0a41fdea91ee1e087578119000f24a9f
Author: Adam McDaniel <>
Date: Mon Sep 22 16:53:06 2008 -0600

    EEEPC: Added bluetooth attribute to /sys/devices/platform/eeepc/bt
    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/platform/eeepc/bt" is created, and writing 0 or 1 will disable/enable it. (Devices that lack on-board bluetooth should not see this file.)

Oliver:
Hmm. Does using
echo 0 > /sys/class/rfkill/rfkill0/state
with the patch applied also fail to turn the wifi off?

Echoing 0/1 to /sys/class/rfkill/rfkill0/state works. Not the key itself.
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.

Olivier:
Do you have another module loaded which is also trying to do hotkeys (e.g. a hacked up asus-apci)?

I found the problem; but from latest xorg developments, it does not seem to be easily solved: http://lists.freedesktop.org/archives/xorg/2008-August/037728.html

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://bugs.freedesktop.org/show_bug.cgi?id=10979

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://lkml.org/lkml/2008/8/4/316

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?

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.

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.

Adding:
options rfkill default_state=0
in:
/etc/modprobe.d/options

Should disable the wifi transmitter at boot time (in fact when the rfkill module loads).

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...

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://lkml.org/lkml/2008/10/4/151 for details.

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.

Adam: on the 1000, doing "echo 0 |sudo tee /sys/devices/platform/eeepc/bt" doesn't seem to do anything.
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.

I can confirm the BT bug with my 901. A "cat /sys/devices/platform/eeepc/bt" gives me "-19" and I can`t change it to 0 or 1.

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...

On an install of Intrepid, the volume keys are still invisible to X. There is a package 'eeepc-acpi-scripts' that looks like it has potential, but it conflicts with acpi-support, which is required by ubuntu-desktop, and so it's uninstallable. This is with an eee 701. The keys worked in Hardy with the addition of eeepc-acpi-source or whatever it was.

I plan to do some experimenting with this, but in /etc/acpi/events/asus-eee-volume-up there is the line:
action=/etc/acpi/if-asus-eee.sh volupbtn.sh
however:
robin@gulik:~$ /etc/acpi/if-asus-eee.sh
bash: /etc/acpi/if-asus-eee.sh: No such file or directory

So, my experimentation bears fruit. I created a file (for test purposes, it's clearly not a global solution):
robin@gulik:/etc/acpi$ cat if-asus-eee.sh
#!/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.)

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.

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.

Matthew Garrett posted some news about the eeepc wifi on his blog
=>http://mjg59.livejournal.com/100587.html

And he propose a new patch I did not already tested:
=> http://www.codon.org.uk/~mjg59/tmp/eeepc-laptop-hotplug.diff

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.

Olivier:
I believe later versions of evdev will no longer grab the device by default - http://who-t.blogspot.com/2008/11/evdev-21-is-out.html (so this may allow the hotkeys to continue working when you use it).

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://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

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.

pana: upgrade to evdev 2.1 to stop the trapping of the hotkeys.

I have version 2.0.99+git20080912-0ubuntu6. Is the relevant change not in this version?

Ok! With the last jaunty I had to add pciehp.pciehp_force=1 to the kernel options for the wireless to work with the ath5k driver. I also added the file eee-wireless-toggle to /etc/acpi/events/ and eeepc-wireless-toggle.sh to /etc/acpi/. Both files are attached. Also added
options rfkill default_state=0
to /etc/modprobe.d/options.
All this for the Asus eeepc 701 4G.

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://mjg59.livejournal.com/100587.html .

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.

The right place to fix this is in the kernel; marking the acpi-support task as 'invalid'.

mjg59's "no pciehp required" patch appears to have gone into 2.6.29 ( http://git.eu.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5740294ca3a9b113fe146f2826effb69ca50008d ).

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...

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?

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:

    http://people.ubuntu.com/~apw/lp232170-jaunty/

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://marc.info/?l=linux-acpi&m=123540718932584&w=4 . I can't say I like it but still).

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://marc.info/?l=linux-kernel&m=123549146723314&w=4 ).
- 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).

Just adding a note that bug 182490 is also resolved with the patched noted in https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/232170/comments/54 (commit 5740294ca3a9b113fe146f2826effb69ca50008d)

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.

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?

jdeslip: I'm still stuck in the same situation as well.

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/event.d/25NetworkManager restart
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.

Troy, you said you did a fresh jaunty instal, did you patched your kernel, or installed the one proposed by andy (see here above) ?

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.

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)!

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)

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?

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?

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)...

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?

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?

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?

With the latest Netbook Remix based on Jaunty (all updates, latest kernel) and rfkill_input loaded, I still have the broken Network Manager behaviour...

Ben:
A bug report isn't really the best place to be asking general questions. Try one of the other support options: http://www.ubuntu.com/support/communitysupport . Good luck!

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.

did this problem hit again with Lucid 10.04?
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/518007