powerd-dbus network extension

Daniel Drake dsd at laptop.org
Wed Aug 3 14:07:31 EDT 2011


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



More information about the Devel mailing list