hi daniel -- daniel wrote: > Hi Paul, > > For 11.3.0 I'd like to implement a solution for the issue where powerd > idle-suspends while wifi connections are being established, causing > connection failures and other undesirable activity. > > The solution I'm thinking of isn't ideal in that it adds a mini-daemon > alongside powerd. But hey, you just got rid of HAL, we have breathing > space ;) and I can't think of a better way. > > Here is what I've thought up: > > > Instead of being on-demand and short lived, powerd-dbus will be > launched by powerd and will become a full-time daemon. > In addition to the functionality that it already has, it will connect > to the dbus system bus and monitor NetworkManager's StateChanged > signals. > > The NM states are: > DEVICE_STATE_UNKNOWN = 0 > DEVICE_STATE_UNMANAGED = 1 > DEVICE_STATE_UNAVAILABLE = 2 > DEVICE_STATE_DISCONNECTED = 3 > DEVICE_STATE_PREPARE = 4 > DEVICE_STATE_CONFIG = 5 > DEVICE_STATE_NEED_AUTH = 6 > DEVICE_STATE_IP_CONFIG = 7 > DEVICE_STATE_ACTIVATED = 8 > DEVICE_STATE_FAILED = 9 > > Lets assign a variable: > nm_suspend_ok = state <= 3 && state >= 8
since that can't be true, i assume you meant: nm_suspend_ok = state <= 3 || state >= 8 > (i.e. suspend is only OK if we aren't establishing a connection) > > It will also monitor the wpa_supplicant signals for the same device, > watching for the Scanning signal. > wpas_suspend_ok = !Scanning > > Finally: > suspend_ok = wpas_suspend_ok && nm_suspend_ok you're far more familiar with the details of how NM and wpa_supplicant operate, so i'm sure your proposed conditions are likely correct. > When the suspend_ok flag changes, it would be communicated to powerd > through the powerevents socket, as "network_suspend_ok" or > "network_suspend_not_ok". > > There would be a 2 second settle period after a not-OK to OK > transition before sending the powerd event (and the event would be > aborted if the situation changes within those 2 seconds). This > captures the case where NM says the device is disconnected, and > wpa_supplicant has finished a scan (suspend_ok == TRUE), but NM will > initiate a connection immediately after (once it has processed the > scan results). > > When powerd has been told network_suspend_not_ok, it would not suspend > until told otherwise. (I'll probably ask you to implement this bit, I > guess you could do it rather quickly?) sure. as john suggested in another message, this is yet another application-specific "protocol" being implemented in powerd, as a heuristic to keep the user happy. while i have no problem adding it (what's one more? :-), we should certainly be tracking the ongoing kernel work which might support all our suspend inhibitors in a more cohesive way. > > > The above is the main functionality I want to implement. But, to kill > 2 birds in 1 stone, having this full-time daemon around lets me solve > another issue: rfkill. > > You probably recall that sugar-0.84 executed "rfkill block olpc" when > the "disable wifi" checkbox was ticked. Unfortunately this was never it used to be "rfkill block wifi", but perhaps that's changed. > upstreamed (boo), so 11.2.0 doesn't have that functionality. In > 11.2.0, the NM WirelessEnabled property is manipulated, and the > interface is brought down, but we don't actually cut power. > > We do have the option of reimplementing it in Sugar, but (for now) I > think powerd would be a nicer place to do this. (Ultimately, we want > NM to do it). > > So, in addition to the above, powerd-dbus would monitor for > NetworkManager's PropertiesChanged signal, and apply this simple > logic. > > if WirelessEnabled == true: > rfkill unblock olpc > else: > rfkill block olpc again, you're closer to the wireless bits than i am. i guess we know that NM won't be confused by having the card logically disappear when it brings the interface down? if so, then it sounds like a reasonable plan. (though it feels like a bit of a hack for it to be in powerd-dbus.) paul > > > How does this sound to you? > > Thanks, > Daniel =--------------------- paul fox, p...@laptop.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel