On Tuesday 16 September 2008 21:18:27 Carlos Corbacho wrote: > On Tuesday 16 September 2008 18:08:48 Larry Finger wrote: > > I agree with Michael. From what I know, the only possible reason for > > having [RFKILL_STATE_HARD_BLOCKED] would be if user space could > > somehow affect the state of the hardware switch. > > When I disable the b43 device in my laptop via acer-wmi (which in turn, calls > into the laptops firmware), b43 physically cannot re-enable it (a not > uncommon case on a lot of laptops). In which case, as far as b43 is > concerned, the wireless radio is then in RFKILL_STATE_HARD_BLOCKED, since b43 > is unable to re-enable the radio on the hardware. > > So yes, it is quite possible for b43 to be in RFKILL_STATE_HARD_BLOCKED. Sure it is. It's the common case, if there's a button. But I don't know how to tell the rfkill subsystem about the states and I do not _want_ to. See, that crap code _always_ blew up for every single patch we did. I'm tired of this and I am not interested in that anymore. Please revert that patch and if that makes it work I'm fine with it. I'm still waiting for the sane rfkill API where we have three functions rfkill-allocate rfkill-hw-state-changed rfkill-free That's all I need. All that input stuff, which was _the_ way to go some months ago, but is now deprecated it seems (but I don't know what it it replaced by) is just so really confusing. -- Greetings Michael. -- 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
