On Wed, 2008-12-10 at 19:05 +0100, Johannes Berg wrote: > On Wed, 2008-12-10 at 17:51 +0000, Matthew Garrett wrote: > > > They may not be physical buttons, but we can often control this anyway. > > For instance, my HP has a button that will perform a hardware disable of > > the wifi card. However, I can control that button's state through > > software with the hp-wmi driver. > > That's indeed a complication I wasn't aware of. > > > The way we currently handle that (and, > > I think, the only way we *can* handle that) is to provide two separate > > rfkill interfaces - one tied to the wireless device, one tied to the > > platform device. > > Yes, but how do we currently do this? > > Does the wireless driver get the notification about this from the > hardware, like it would if this was a real physical switch? Then it's > probably pretty simple: provide a rfkill struct from the driver that > updates hard-kill and provide a second rfkill struct for the platform > device that doesn't get hard-killed, but also provide a soft-kill input > form the platform device. That way, you can toggle that button, but you > can also software-enable the platform rfkill device and that in turn > re-enables the wifi-rfkill "hw" switch device. This sort of sucks for userspace, because we see the actual wifi card as hardblocked, but some other random button as softblocked. There's no indication that changing the softblock one will affect the hardblocked one. What are userspace processes supposed to do here, assume that if a non-radio-associated softblocked switch exists, that it can re-enable a hardblocked radio of some random wifi card? Dan -- 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
