On Tue, Sep 16, 2008 at 02:30:35PM -0500, Larry Finger wrote:
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@srcf.ucam.org
--
