Hum, what does this have to do with toggling Wi-Fi, since this is the standby scheduler?

(If it "fixes" anything, this is just because of the added delay this incurs, which is why I'm not a fan of this approach; on the other hand, if it actually does somethign because of a mismatch between getWifiState and isWifiOn, I'd much, much, much rather fix NetworkManager instead ;)).

I wouldn't mind a comment on that one, too; but I'm fine with this approach (even if I'm still not quite sure what's happenign here, and if it isn't very very very timing-specific to your setup...).

Let us wait with this one too.

I assume the idea is to prevent entering suspend right when we stop blocking from the WiFi stuff (which would probably fail, even if there were no weird display stuff entering the mix), which certainly makes sense on paper ;).

This opens up another can of worms though: should we take the plunge and hope that our onNetwork(Dis)Connected events are reliable, and simply stop scheduling standby on connected, and resume on disconnected? (Instead of checking that inside the scheduler).

(Not necessarily recommending that, mind you, just a brain dump ;)).

This commit fixes my problems with the strange screen refresh on turning Wifi on.

The root cause is, that toggleWifiOn in NetworkManager might take long (up to 12 seconds here).

Additionally, this solution quasi disables the standby when Wifi is on (by setting a laaarge time for the next sleep; then wie don't have to bother with allow/prevent-standby symmetry). Which simplifies the program flow with Wifi on.

Makes sense ;o).

Now we just have to hope that my Network* events are reliable ;o).

Ready to merge?

lgtm