On Wed, 2007-01-31 at 16:30 +0000, Matthew Garrett wrote: > On Wed, Jan 31, 2007 at 11:10:16AM -0500, Dan Williams wrote: > > > Ok, I think I know what you mean here. I guess I'd rather have this > > sort of thing in HAL. If it's going to be a global "kill everything" > > switch, having that in HAL makes sense. David? It doesn't quite feel > > right to put this into NM, because NM isn't really that close to the > > hardware, and NM isn't a standard tool that everyone ships, but I think > > we view HAL in that light. > > Ok, just to make sure I understand your opinion on this - hal should > recognise that the key has been hit (whether from the keyboard > controller, rfkill or whatever), ensure that all the cards are set to > one state or the other and then let n-m know to bring the interfaces up > or down as appropriate?
Well, if we do actually want the "one key to rule them all" model, then wouldn't it be simpler to have a global wireless rf-enabled state in hal? I think that's what you initially proposed before I misunderstood and asked for a signal-per-device. NM would then bring down the devices if they weren't already hardware-disabled by some other mechanism. But I don't think this model is decided yet. We keep going back and forth on netdev about it. > > Seriously, what other possible reason than "kill my radio" could pushing > > the "kill my radio" button mean? :) > > You'd actually be surprised - I've had several bugs from people asking > for support for toggling between the four different combinations of > bluetooth and wireless. Oh man. WHY? WHY? WHY? I seriously don't get it; because nobody has actually explained to me before what the reason would be to disable one and not the other. Not that I'm opposed to it, but it seriously complicates the interaction for everybody else for apparently little reason. I personally think it's acceptable that if you want to disable bluetooth but not wireless, right-click on your DE's panel and tell bluetooth to turn off. But the interaction model should not be popping up a dialog or stepping between all 4 combinations (which requires you to look at all your status icons 4 times to ensure you really have done what you want). It comes down to a question of whether that button is really an rfkill button, or just a really quick and easy way to turn off your wireless. If people are using it to save battery life, then that's _not_ the right way to go about saving battery life. Maybe I have some outdated notion that you only really want to use it when you're on a plane or in a blast zone. > > This is true; and I don't really care either way I guess. To _me_ > > logically if I say "kill wireless" that means all of bluetooth, > > GPRS/CDMA, and 802.11. The corner case is if you have more than one > > button on a laptop (does this happen? ISTR it has) and if you slide the > > bluetooth toggle button to off, but the 802.11 toggle is still "on", > > what does that mean? There's a ton of variability here; but I think the > > corner case I brought up is exceedingly rare and I guess we shouldn't > > care about it. > > Some machines do have more than one button, but I guess we just flag > those in fdi files and treat things differently there. Though, to be > honest, in most cases we have little influence over bluetooth anyway - > the hardware tends to simulate plugging/unplugging. Yeah, thankfully most of these tend to be USB devices which would just magically work. Too bad the 802.11 stuff doesn't use PCI hotplug or something. > > Right. The problem I have with all of this is that it will be pretty > > hard to make sure that all the different variations of rfkill are > > synchronized between the state keeper (HAL?) and the driver in the case > > where the rfkill switch and the hardware are more tightly integrated > > than your machine. > > Ok. So how about the following: > > 1) User hits wireless button > 2) Hal notices this event (somehow). Depending on its understanding of > events, it places all controllable radios into either the on or off > state. What do you mean by "place"? Does HAL actually talk to the driver or hardware and do the radio disable? Or does it just modify it's internal per-device disabled state? > 3) Hal notifies n-m of this (or alternatively n-m gets a netlink event, > but I don't think we have the infrastructure for that yet?) > 4) n-m either downs the interfaces (which ensures that the hardware is > powered down in the new world order) or brings them up and attempts to > connect to the world again > > ? The alternative would be that step 4 is done by hal itself. I don't think the alternative is appropriate; hal doesn't touch network device operation yet and probably shouldn't yet. DavidZ and I have talked about splitting pieces of NM out into hal addins, but that's a ways off if it happens. > Thinking about it, while rfkill provides a mechanism for tying together > the interface between kill switches and hardware, does it provide a > common interface for userspace to determine whether an interface has a > working radio? We need that too. I had assumed that the _driver_ would be able to present that information via sysfs or something, which means HAL could pick it up or a script could poke /sys/class/net/wifi0/radio_state. Basically, we really need to figure out whether it's rfkill-a-la-carte, or global disable before making more of these types of decisions. dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
