On Tue, Sep 16, 2008 at 02:30:35PM -0500, Larry Finger wrote: > I didn't say it was not possible. What I said is that _ONLY_ the > operator's finger could change the state, just like in your laptop. > Thus it makes absolutely no difference what state RFKILL thinks it is > in. Of course it makes a difference. The reason why two states are provided is to allow userspace to distinguish whether it can unblock the device or not. It's clear that b43's rfkill code is astonishingly broken (and that's not a criticism of anyone involved - the documentation's confusing and there weren't any good examples of how it should be implemented). The real question is how the LED state is supposed to be being toggled, and what that's got to do with rfkill. I /think/ that the current state of events is: 1) User toggles state 2) State toggle is used by b43 to generate KEY_WLAN (this is broken) 3) rfkill-input toggles the rfkill state, changing the LED state in the process What *should* be happening is: 1) User toggles state 2) b43 changes rfkill state (by using rfkill_force_state). The LED state should also be changed in the process. It looks like the commit in question gets part of the way to implementing the second of these situations, but will now change the rfkill state at the same time that rfkill-input tries to. I agree that it should be reverted for now, but because it's (a) broken (changing the state member directly is wrong) and (b) potentially open to strange states being generated by rfkill-input trying to change the state after it's already been changed. The general intent is correct. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- 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
