Comment 5 for bug 395358

Steve, sorry for not providing more details. Since I was seeing the exact same symptoms on my machine, I simply assumed I had the same bug. Particularly since the kernel part supposedly causing the issue is the platform independent rfkill module (as per LP #397698).

I'll try to give some more details here, and if you still think I have a different bug, let me know and I'll just go away.

In jaunty, the state of my bluetooth and wlan device, were controlled by means of /sys/devices/platform/asus-laptop/bluetooth, and /sys/class/net/wlan0/device/rfkill/*/state, respectively. In Karmic, they're both controlled by means of "/sys/class/rfkill/rfkill*/state".

Now, in Jaunty pressing Fn+F2 (which corresponds to Fn+F5 on the thinkpad) cycles the different possible states of bt+wlan. In Karmic, however, bt+wlan are turned off simultaneously. What's peculiar is that when FN+F2 toggles the radio devices to off, the /sys/class/rfkill/rfkillX that corresponds to the bluetooth device is removed (leaving me with just one rfkill device), and when it's toggled back on, the bluetooth-rfkill device comes back but, but this time named rfkillX+1 (that is rfkill1, becomes rfkill2, next time around rfkill3, etc.)

All this is being done with acpi-support stopped, which means (if I'm not misunderstanding anything here), that none of the platform specific scripts in /etc/acpi/* are run.

Likewise, I can't change the value of /sys/class/rfkill/rfkill*/state manually.

Shouldn't hal be in charge of hotkeys nowadays, instead of acpi-support? If I don't misremember this, hal doesn't know how to cycle states, but rather changes the state of bt+wlan the way described here.