Hi, > The probblem we faced was that the hardware changes the hard rfkill > _and_ sends the WLAN key at the same time. Since the rfkill input > handler toggles the soft rfkill at each WLAN key, if the rfkill > state at boot is like > hard: block > soft: unblock > then it'll change like > hard: unblock > soft: block > so the WLAN is never activated. Heh, funky. > In the end, we fixed the problem by disabling the keymap for WLAN > key. But this is also assuming that BIOS does always rfkill. If BIOS > behavior suddenly changes, you'll loose the rfkill behavior. Yeah, this is kinda dumb. But really it needs to be encapsulated in the rfkill platform driver I think? Or is the WLAN key just a regular key on the keyboard? Maybe the platform driver on this platform could bind it and eat it? > Also, another drawback is that now rfkill isn't triggered immediately > with WLAN key but it waits for some seconds until hard block is > polled. Ideally, it'd be good if the rfkill hard state can be checked > immediately when WLAN key is issued (but without touching soft > block). This has been talked about before I think, but I'm not sure it'd be good generic behaviour? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
