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

[Matt Austin]

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://wiki.eeeuser.com/getting_ubuntu_8.04_to_work_perfectly#wifi_hotkeys
Volume Hotkeys: http://wiki.eeeuser.com/getting_ubuntu_8.04_to_work_perfectly#hotkeys
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)]

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)

[Michael Craft (holographicpizza)]

I can also confirm this.

[Bastien (bastien-redhat-bugs)]

This should be done in the kernel, with the module handling the Eeepc using the
input layer to push the events to user-space.

[Chuck (chuck-redhat-bugs)]

(In reply to comment #1)
> This should be done in the kernel, with the module handling the Eeepc using the
> input layer to push the events to user-space.

I've replaced the preliminary eeepc driver in F9 with the final eeepc-laptop
driver from rawhide/2.6.26. If that one doesn't work by using the input layer
to push the events then you are asking for a rewrite of the driver.

[Chuck (chuck-redhat-bugs)]

(In reply to comment #0)
> Description of problem: FN keys in eeePC don't work out of the box, there is the
> need to write down some scripts to handle these events
>
>
> Actual results:
> we got working wireless on/off, display to external monitor, volume controls,
> with these scripts (just workarounds):
> http://fedoraproject.org/wiki/EeePc#ACPI_support_in_Fedora_9

Is there any way you can test rawhide to see if it works any better out of the box?

[Carlo (carlo-redhat-bugs)]

1-rawnhide kernel
2-F9 upgraded to rawhide
3-Rawhide fresh install

which one?

[Carlo (carlo-redhat-bugs)]

Tried kernel-2.6.26-0.67.rc6.git1 (rawihide)
reverted tweaks, acpid, etc. So stock fedora setup.

Fn+F1 (suspend) WORKS...also backlight resume (yeah!! very nice)

Fn+F2 (WIFI TOGGLE) NOT WORK... :-( (this is very useful...)

Fn+F3 and Fn+F4 (BACK LIGHT ADJUST) WORK

Fn+F5 (LCD/EXTERNAL MONITOR SWITCH) I don't know if works..because I can't test
it out... My ext monitor is broken

Fn+F6 (originally was for opening terminal in xandros) OBVIOUSLY doesn't
work..This fn is unuseful with stock linux distributions.... I used it in
scripts, to toggle webcam (as mandriva and other distributions do)...so it
should be an idea to let this key toggle webcam....

Fn+F7 (Toggle MUTE) NOT WORK
Fn+F8 (VOLUME DOWN) NOT WORK
Fn+F9 (VOLUME UP ) NOT WORK

Thanks for attention :)

[Bastien (bastien-redhat-bugs)]

(In reply to comment #5)
> Tried kernel-2.6.26-0.67.rc6.git1 (rawihide)
> reverted tweaks, acpid, etc. So stock fedora setup.
>
> Fn+F1 (suspend) WORKS...also backlight resume (yeah!! very nice)
<Snip>
> Fn+F3 and Fn+F4 (BACK LIGHT ADJUST) WORK
<nip>
> Fn+F7 (Toggle MUTE) NOT WORK
> Fn+F8 (VOLUME DOWN) NOT WORK
> Fn+F9 (VOLUME UP ) NOT WORK

The backlight and suspend keys working is good (I guess this gets through ACPI,
and is captured by hal and passed onto gnome-power-manager). Do the backlight
keys show a popup when in GNOME?

The other keys not working is a bit of a problem, but they're not expected to
work out-of-the-box for the most part.

I checked out the eeepc-laptop driver in the linux-next git tree, and it doesn't
pass those extra keys through the input layer (so the keys aren't visible in
user-space).

Could you check whether you see any error messages in dmesg when using the keys,
or whether the keys work using "xev" while running X?

[Carlo (carlo-redhat-bugs)]

No...I think backlight keys are bios handled...they work also in grub, kernel
booting, etc....
No popup.....

no xev output for Fn keys and no dmesg ....

because of this, we used acpid and some scripts to handle these events....I
don't remember what we used to read the keyevents.

So... the "lamer" scripts + acpid must continue to exist.... I don't think
someone will handle this events in kernel or with an official rpm.....

[Bastien (bastien-redhat-bugs)]

(In reply to comment #7)
> No...I think backlight keys are bios handled...they work also in grub, kernel
> booting, etc....
> No popup.....
>
> no xev output for Fn keys and no dmesg ....
>
> because of this, we used acpid and some scripts to handle these events....I
> don't remember what we used to read the keyevents.
>
> So... the "lamer" scripts + acpid must continue to exist.... I don't think
> someone will handle this events in kernel or with an official rpm.....

The kernel module will need some work then. I copied Matthew and Richard that
could help. It would certainly be easier if they had access to an EeePC ;)

[Matthew (matthew-redhat-bugs)]

Created attachment 309396
Add input support to eeepc hotkey driver

Would be helpful if someone could give this a go - I don't have an eee. The
radio handling is going to be suboptimal until either madwifi gains rfkill
support or ath5k works on this hardware.

[Matthew (matthew-redhat-bugs)]

Though, looking at it, it should be possible to implement rfkill in the eee
driver itself. That would almost certainly be preferable.

[Matthew (matthew-redhat-bugs)]

The wifi handling code is, it turns out, insane. I'll do a new patch now.

[Matthew (matthew-redhat-bugs)]

Created attachment 309502
Updated patch

This cleans up the rfkill handling. An rfkill device is registered (and so the
wlan entry is removed from sysfs) and the wireless button generates KEY_WLAN.
If rfkill-input is loaded (which really ought to be the default, but doesn't
seem to be yet?) then the default behaviour will be for the state to be toggled
on button presses. Again, entirely untested beyond building. Could someone try
this on real hardware?

[Carlo (carlo-redhat-bugs)]

Can you build this patch in a kernel build on koji? madwifi isn't compiling in
2.6.26....I'm searching a solution for this...so you have all the time you want :)

[Chuck (chuck-redhat-bugs)]

(In reply to comment #12)
> Created an attachment (id=309502) [edit]
> Updated patch
>

Are you submitting this upstream too?

[Matthew (matthew-redhat-bugs)]

Once I've got some confirmation that it works, sure :) I don't have an eee.

[Carlo (carlo-redhat-bugs)]

I managed to install madwifi in 2.6.26, and now I'm using only the 2.6.26 git2
kernel..... I can't patch and compile the kernel myself, because my home pc is
broken (sigh) and the celeron cpu in my eeepc will burn in compiling it....

Can anyone build a testing kernel rpm for me? so I can test out your changes...

thankyou all for the great work you are doing in eeepc support...I'm sure this
will be helpful for us!

[elmurato (elmurato87)]

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

[Jeff Sereno (jsereno)]

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

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

[Matthew (matthew-redhat-bugs)]

Added to Rawhide kernel, should hit the archive later today. Verified to work on a 900, but should be fine on the 700 series as well. Wifi now handled by rfkill (make sure that the rfkill-input module is loaded). Keys are sent via the input layer.

[Chuck (chuck-redhat-bugs)]

Should this patch be backported to F9 as well?

[Matt Austin (mattaustin)]

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

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.

[Paulo Albuquerque (paulo.albuquerque)]

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

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

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

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

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.

[rayhaque (rayhaque)]

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.

[rayhaque (rayhaque)]

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

[Sitsofe (sitsofe-redhat-bugs)]

Chuck: possibly although the wifi patch changes the nature of how things worked a bit so that my be an unwanted surprise (it is no longer possible to disable wifi before shutdown and expect it to be off when you next boot the machine as it will be toggled back on during boot).

On a related note, if you do decide to use this patch make sure you boot the kernel with the pciehp.pciehp_force=1 kernel parameter (at least on an Eee 900). Failure to do so will result in the inability to start the wifi after it has been stopped once (e.g. by hitting the wifi toggle hotkey while the wifi is on).

[Sitsofe (sitsofe-redhat-bugs)]

(I forgot to mention that the pciehp information was found over on http://www.nathancoulson.com/proj_eee.shtml )

[Sitsofe Wheeler (sitsofe)]

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.

[Adam McDaniel (adamrmcd)]

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

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

[Olivier Samyn (olivier-oleastre)]

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

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

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

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

[Sitsofe Wheeler (sitsofe)]

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

[Olivier Samyn (olivier-oleastre)]

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.

[Sitsofe Wheeler (sitsofe)]

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

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

[Olivier Samyn (olivier-oleastre)]

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

[Bryce Harrington (bryce)]

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

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

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

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

[Sitsofe (sitsofe-redhat-bugs)]

In testing against linux-tip this patch breaks the resume part of suspend to RAM on my EeePC 900...

[Sitsofe Wheeler (sitsofe)]

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

[Matthew (matthew-redhat-bugs)]

If you remove the rfkill registration, does it work?

[Sitsofe (sitsofe-redhat-bugs)]

mjg:
Yes, if I remove rfkill registration then it works.

[Matthew (matthew-redhat-bugs)]

Ok. Can you readd the rfkill registration and then edit net/rfkill/rfkill.c and remove the

        .suspend = rfkill_suspend,
        .resume = rfkill_resume,

lines and see if that works?

[Sitsofe (sitsofe-redhat-bugs)]

Readding the registration and commenting out the above lines allows suspend and resume to work but trying to toggle the wifi power via the hotkey no longer works (even before suspending).

[Adam (adam-redhat-bugs)]

Created attachment 319477
Add bluetooth support to eeepc-laptop

The following patch adds bluetooth toggle support to eeepc-laptop.ko, through /sys/devices/platform/eeepc/bt (the same way that the deprecated eeepc-acpi module did.)

This patch is based upon the original import of the eeepc-laptop driver, committed e59f87966adef2cb03d419530e3ade5159487d6d by Eric Cooper at 2008-03-13 for v2.6.26-rc1.

It straddles code modified by the latest patch attached to this bug (add rfkill wlan support), but there's only one chunk which adds just two lines. Very easy to apply by hand :)

[Matthew (matthew-redhat-bugs)]

No, this needs to be done via rfkill. Hang on, let me try to generate a patch.

[Matthew (matthew-redhat-bugs)]

Wait, I already added code to control bluetooth via rfkill. Can you check whether it works? It should be in /sys/class/rfkill, with the type set to bluetooth.

[Sitsofe Wheeler (sitsofe)]

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.

[Adam (adam-redhat-bugs)]

Can do. However shouldn't there be an equivalent line like: "rfkill_allocate( &device->dev, RFKILL_TYPE_BLUETOOTH )" somewhere in eeepc-laptop.c, too?

For example, the 1000 has 4 special hotkeys (acpi codes 0x1a..0x1d) which some users have customized to provide bluetooth enable/disable.

Shouldn't applying something like that be handled by eeepc-laptop?

[Adam (adam-redhat-bugs)]

Regardless if the answer is yes or no, I'll retract my patch ;)

[Adam (adam-redhat-bugs)]

Comment on attachment 319477
Add bluetooth support to eeepc-laptop

Obsollete, already handled by rfkill

[Matthew (matthew-redhat-bugs)]

        if (get_acpi(CM_ASL_BLUETOOTH) != -1) {
                ehotk->eeepc_bluetooth_rfkill =
                        rfkill_allocate(&device->dev, RFKILL_TYPE_BLUETOOTH);

is already in there in the Rawhide kernel?

[Adam (adam-redhat-bugs)]

You'd know better than I. I'm coming from the ubuntu side, I'm just checking in because I'm interested in the rfkill/wlan patch you developed.

Incidentally, I had the same problem described in comment #21 last night, and the fix from #24 did appear to solve it. However, Sitsofe's comment #25 is still a problem (Fn-F2 wifi key doesn't toggle wifi). BUT, wifi does correctly respond if I manually inject 0 or 1 to "/sys/class/rfkill/.../state" type wlan.

There appears to be a disconnect, possibly with nothing actually using NOTIFY_WLAN_ON, or KEY_WLAN in 'static struct key_entry eeepc_keymap[]'

> is already in there in the Rawhide kernel?

That's a very good question. Google and I couldn't find a git repo for rawhide's kernel. If you can direct me where to grab it, I can probably find the answers to my problem myself ;)

[Matthew (matthew-redhat-bugs)]

Fedora kernel is kept in CVS - patches are at http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel . The key will do nothing unless you have the rfkill-input module loaded. We've tracked down the issue with it failing to work on boot - I'm getting a fix into rfkill upstream now.

[Sitsofe (sitsofe-redhat-bugs)]

The "broken" wifi toggling hotkey turned out to be due to rfkill hotkeys not working until five minutes after the system has booted. Matthew has already posted a patch to fix this on http://lkml.org/lkml/2008/10/4/151 .

[Adam (adam-redhat-bugs)]

That's odd. I'm probably OTL but I left my EeePC 900 online for a few hours last night. Even with the 5-minute known issue, Fn-F2 still never triggered wireless. (I was trying roughly every 30 min.)

I saw [PATCH v3] on the LKML, I'll give it a shot next, plus the unique bits still in fedora's linux-2.6-eeepc-laptop-update.patch and linux-2.6-wireless-pending.patch.

I assume that if a patch is committed to Fedora's CVS server, it's been signed-off and tested by Fedora's team and they're promoting it for linux-tip?

Thx :)

[Matthew (matthew-redhat-bugs)]

Adam,

You have rfkill-input loaded, right?

[Adam (adam-redhat-bugs)]

Sorry, I forgot to mention that I did. However it didn't autoprobe on bootup like rfkill did c/o the eeepc-laptop dependency.

Shouldn't eeepc-laptop also depend on rfkill-input?

[Sitsofe (sitsofe-redhat-bugs)]

Adam:
I believe someone posted a patch for the rfkill dependency on http://lkml.org/lkml/2008/9/15/159 . I wouldn't have seen module issues as I don't build modules for my kernel...

[Olivier Samyn (olivier-oleastre)]

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.

[Carlo (carlo-redhat-bugs)]

I'm testing out the kernel 2.6.27.0-3 ...

rfkill-input and ath5k need manual modprobe. So I hope they will be automagically modprobed soon...

They SEEM to work... network manager doesn't like rfkill...it's unable to reload wifi...

maybe I'll try a rawhide network manager release... I'm with the fedora 9 stable one.

[Christopher (chriruud)]

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.

[elmurato (elmurato87)]

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

[Robin Sheat (eythian)]

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.

[Robin Sheat (eythian)]

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

[Robin Sheat (eythian)]

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

[Robin Sheat (eythian)]

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

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.