powerd-dbus network extension

[Peter Robinson]

Hi Daniel,

Not sure if powerd makes use of it at all already (for things like watching
videos in totem) but why not use the kernel/upower inhibit functionally just
like totem and the like does. Then powerd just needs to
listen/check/whatever for the inhibit and it would then also work (if it
doesn't already) for those apps like totem in the gnome desktop.

Peter

On Wed, Aug 3, 2011 at 7:07 PM, Daniel Drake <dsd at laptop.org> 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
> (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
>
> 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?)
>
>
>
>
> 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
> 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
>
>
> How does this sound to you?
>
> Thanks,
> Daniel
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20110803/2c8df97a/attachment.html>