On Mon, 2008-05-12 at 18:20 -0400, Tony Espy wrote: > Dan Williams wrote: > > On Mon, 2008-05-12 at 17:46 +0200, Khashayar Naderehvandi wrote: > >> I really might be misunderstanding something here, but deactivating > >> wireless through nm-applet should in fact (as things are currently > >> with NM from svn), do a ifconfig wlan0 down? Is this correct? Because > >> doing that manually, my wifi doesn't suck battery power anymore. > >> However, nm-applet seems to take down the wireless device _only_ when > >> I deactivate network completely, that is, when I deactivate wireless, > >> wired and GSM capabilities. Only deactivating wireless leaves the > >> device up, and hence reduces uptime on battery. > > > > We do need to mark the device down when it's disabled; that somehow went > > away when rewriting the device state handling. Should be a pretty easy > > fix in nm-device-802-11-wireless.c::nm_device_802_11_wireless_set_enabled(). > > > > I was going to change that code to set the TX power of the card off > > instead of taking it down, because some hardware (iwl3945) needs > > firmware loaded to notice rfkill changes, and setting the device down > > unloads the firmware. So at least on some devices you need to always > > keep the card up. But HAL isn't smart enough yet to distinguish between > > soft rfkill and hard rfkill, so setting TX power off, to HAL, looks just > > like a hard rfkill and you can't turn the rf back on in software :( > > That's a fairly easy patch to HAL though. > > I've been following this thread with interest because I've recently > implemented this feature on top of network-manager-0.6.6~rc2 ( the > version in Ubuntu 8.04 ) as part of some custom Ubuntu Mobile work. > > I added logic to invoke the Hal KillSwitch::SetPower method from within > the wireless_set_enabled() function. I also added a sw_rf_enabled flag > to handle allowing the user to re-enable wireless ( otherwise as Dan > pointed out, the hw_rf_enabled flag would prevent this ).
Ideally that's what NM would be doing; unfortunately many machines still don't actually use rfkill, and there's no way to map the rfkill button to a specific hardware device by design. So NM will still have to touch the device directly. > One caveat...it appeared to me as if the NM code in 0.6.6 was > interpreting the GetPower return values incorrectly( ie. it looked like > interpreted TRUE as killswitch ON, as opposed to power ON ). I had to > reverse the value returned by my KillSwitch::GetPower method, otherwise > NM disabled wireless on startup. NM calls GetPower(), which should return 0 if power is off, and 1 if power is on. NM sets it's internal "hw_rf_enabled" state directly from that value. So if GetPower() returns 1, NM should be setting it's "hw_rf_enabled" value to 1. I'd be curious to see exactly what your killswitch method is returning for GetPower() in nm_killswitch_getpower_reply_cb() and then the overall "tmp_hw_rf_enabled" state in handle_killswitch_pcall_done(). > I additionally implemented a power-saving feature using some of the same > logic. I modified the scanning code so that when the scan_interval gets > bumped to INACTIVE ( ~2min ), I disable the interface at the beginning > of the interval and then wake it up right before the next scheduled scan. That's neat; and something we should definitely do in upstream NM. > Note - the one caveat is that my Hal KillSwitch method utilizes a > private DeepSleep ioctl, so the card isn't totally powered off, but is > close enough to show some substantial power-savings. We probably should call SetPower() as well, but we should really do: set TX power off SetPower(0) ... SetPower(1) set TX power on to cover both rfkill-incapable cards and rfkill cards. > I plan on publishing my work via my launchpad PPA ( personal package > archive ), and will drop a note to the list when the code's available ( > hopefully tomorrow ). Patch submissions gratefully accepted :) Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
