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