Johannes Berg wrote: .. > (b) take rfkill state and transform it into conf.radio_enabled along > with the internal conf.radio_enabled state that mac80211 may decide > on based on iwconfig txpower off. assume that users know what > they're doing if they iwconfig txpower off, I think it's pretty > pointless to have in light of rfkill and for all I care we can > remove it
From a usability perspective anything but a single control at the core is utterly confusing and must IMO be avoided at all cost. > Driver only has to follow conf.radio_enabled and inform mac80211 of > the hard state. > > Where's the flaw? Seems complete. I like it. b43 radio state in hardware is a simple logic nor; when both bits are 0 the radio is on. There are many different ways for the user to signal radio enable or disable; radio control is not symmetric. I think the confusion may come from the two separate methods of disabling radio in b43 hardware. There can be both a button suitable for rfkill integration, and a button that overrides whatever software tries to do. The latter is notification only (but pressing it does generate a notification, right? Or is it polled?) and should maybe not be handled by rfkill (I too am not very familiar with the rfkill design :\) but must certainly be reflected in LEDs. Again, LEDs _must_ follow hardware state. Usability. I think the simplest way to accomplish that is logic that funnels into one single radio setting and the LED following that setting. The twist is that radio state is not only controlled by the kernel, but also by hardware. //Peter
pgpcyYXN4IcY4.pgp
Description: PGP signature
_______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
