It’s been a while, so:

1) I’ve posted the final version of the patches to add rfkill support to acer-wmi on the 15th September to the ACPI mailing list.

_Hopefully_ these will go in for 2.6.28.

(This is only for wireless and bluetooth - still waiting for someone to use Linux on an Acer laptop that has built in 3G).

2) For now, rfkill is implemented by polling WMI every second to find the current state of the wireless and bluetooth devices. In future (at least, for WMID compatible laptops), it may be possible to switch this over to a WMI event based system, and avoid polling on those machines, but this will require extensive testing (especially on older machines, such as the Aspire 5040). I may get round to reposting my patch for this somewhere so the more adventurous among you can try it out and feed back.

3) From a button perspective, this will depend on how well rfkill-input is working these days (I haven’t tested lately). However, in HAL, all Acer laptops should be using the same basic keymap now, so we don’t need to keep patching for every single (near identical) laptop for KEY_WLAN and KEY_BLUETOOTH.

4) Unrelated aside to Acer Aspire One owners (so that this is documented somewhere) - it’s not supported by acer-wmi. It only provides a ‘dummy’ interface - the methods in the interface itself don’t actually do anything.

I may explicitly blacklist it in future so that people are aware of this.

I’ve been experimenting now for the last few months with adding rfkill support to acer-wmi in my (rather limited these days) free time (the short, short version of ‘why’ is that this will allow the wireless & bluetooth buttons to just work out of the box on those laptops which have them properly mapped by HAL[1]).

Unfortunately, I’ve been hitting a few snags, most of which I’ve now been able to identify (but there are no solutions at present to all of them):

1) The mysterious double toggle:

Pressing either the wireless or the bluetooth button would trigger both to change states. I tracked this one down yesterday and the fix is pretty trivial.

2) rfkill-input not working until after being reloaded

rfkill-input won’t attach to an input device that doesn’t have KEY_WLAN. But KEY_WLAN isn’t added until HAL kicks in, which is much later. The ‘workaround’ to this is to build a modular rfkill-input, and then reload it after HAL has called setkeycodes. No proper solution yet for this one…

3) The KEY_WLAN cycle of doom

Unfortunately, some of the rfkill enabled wireless drivers send a KEY_WLAN when they detect that the device state has changed. So the following happens:

1) User presses KEY_WLAN
2) rfkill-input toggles all rfkill registered wireless radios
3) acer-wmi gets this signal, and changes the wireless radio state
4) Wireless driver detects the state change, and then helpfully sends a KEY_WLAN
5) Goto 2

And so on until I unload acer-wmi or the offending wireless driver. Consensus so far seems to be that wireless drivers should not using keypresses for event notification.

[1] I now have commit access to the hal-info repository, so I can get your keymaps added as soon as you send them to me