Matthew Garrett wrote: > On Tue, Sep 16, 2008 at 12:08:48PM -0500, Larry Finger wrote: > >> I agree with Michael. From what I know, the only possible reason for >> having this state would be if user space could somehow affect the >> state of the hardware switch. As the user's finger is the only such >> thing, then there is no use for the RFKILL_STATE_HARD_BLOCKED state, >> particularly when it breaks LED operations. > > RFKILL_STATE_HARD_BLOCKED indicates that the hardware is disabled in a > way that userspace can't influence, so sounds like exactly the right > state to have here. I still have absolutely no idea what b43 rfkill is > supposed to be doing - why on earth is it requesting rfkill-input, and > why does it generate keypress events? I /think/ it should e something > like the following (untested, I'm not near any of my b43 hardware at the > moment). This basically does the following: > > 1) Split the update function in two, so it can be called by either > polling or an interrupt driven event on newer hardware (not implemented > yet) > 2) Remove all the input handling > 3) Change the state updates to use rfkill_force_state, which will > generate an event that gets sent up to userland > 4) Retains the RFKILL_STATE_HARD_BLOCKED code > > When the user flicks a switch or presses a button that physically > disables the radio, the state will now automatically change to > RFKILL_STATE_HARD_BLOCKED. If they have a key that generates KEY_WLAN > but doesn't change the radio state, rfkill-input will trigger a change > to RFKILL_STATE_SOFT_BLOCKED. > > Like I said, this is only build-tested - I won't be back at a b43 until > next week. If someone could give this a go, that would be great. It locks up tight with a kernel panic when booting. I have a screen picture that I will send separately to Matthew. Larry -- 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
