On a purely theoretical level, I'm midly puzzled, because UIManager works on CLOCK_MONOTONIC, which does not tick during suspend/standby, so I would naively assume that rewinding shceduled task by the amount of time spent in standby would just wreak havoc?

Oh, wait, that's the whole point ;p. (I was mixing clock sources in my head, never mind me ;p).

It appears GitHub ate my first comment (or I'm so tired that I messed up ;p), so:

Just as a heads up, I won't be able to properly review/test this until next week ;).

Just as a heads up, I won't be able to properly review/test this until next week ;).

Absolutely no problem, as this is draft. I will have to figure out the open tasks and test it myself. You don't need to test it yourself until it is "ready for review". But I would appreciate anything jumping out :)

@NiLuJe Rebased and ready from my side. But no hurry.

After rebaseing I got some strange behaviour. So draft now until I can explain or fix.

Update: I had plugged the device onto a different power source as usual (I knew, that the device sometimes gets crazy after using that charger), but forgot about that (but I am sure it was this way, now).
After two hours of bisecting and debug logs I restarted the device -> and voilà it works.
I am pretty sure, the charger-device combination doesn't fit and leaves the device in some strange state after using the charger (Kobo you have to be more generous in future).

So from my side no changes.

I've had the PowerCover break suspend in fun and interesting ways until a reboot, yeah...

Ready from my side.

I've slacked off a bit, and only juuust started reinstalling my linux env, so I still haven't tried this either. Hopefully this weekend ;).

@NiLuJe Maybe off-topic here, but I don't want to open an additional issue for this. I am sure I saw this behavior before, and it can be provoked in the Terminal emulator (which has not been touched with this PR).

When playing with my Sage sometimes I get strange screen refreshes during reading. The refreshes look like that the screen is split into 4 parts, which are refreshed clockwise starting from the bottom left. Very fast, hard to follow.

I can provoke these refreshes in the Terminal emulator when entering:
echo standby > /sys/power/state
but not when entering:
sleep 3; echo standby > /sys/power/state

The refresh will always happen, when I get a write error: Operation not permitted; with the sleep command, there is no refresh and no write error.
Additionally, the device does not enter standby without the sleep.

Interestingly I found this strange refreshes during read, and I have also notices that the device sometimes does not enter standby.
This often happens, when enabling or disabling WiFi. I have spotted down a minimal change in the code to eliminate this special quirk.

But after seeing this, I looked closely to the fact, that the device does not enter standby.
Then I noticed two things:

• With disabled notifications (Screen->Notifications) the device enters standby almost every time.
• With enabled notification (my favorite) the device does not enter standby after showing a notification. Which would be schedule with scheduledIn(time, onClose). When reducing the time artificially to 0.5 seconds, the refresh never happens and the device goes to standby (but then you can't read the notification :-( ).

So I guess there might be a race hazard. I have tried to add a UIManager:waitForVSync() before entering standby (directly in device.lua) but this didn't help (in fact, I feel the behavior even gets worse).

Do you have any ideas about the root of the problem?
Thanks

When playing with my Sage sometimes I get strange screen refreshes during reading. The refreshes look like that the screen is split into 4 parts, which are refreshed clockwise starting from the bottom left. Very fast, hard to follow.

That's a kernel issue. It appeared with the first kernel update that touched the collision handling code (can't remember the FW version), and subsequent tweaks haven't really managed to entirely squash it.

It's specific to the Sage; the Elipsa has a different collision handling code (also broken, but slightly less user-visibly so).

FWIW, I hadn't traced it to PM at all, as the main spot I was seeing it was actually inside Nickel (and I wasn't the only one ^^); I've only very rarely seen in KOReader.

Then again, if I think about it, I think I added a slight delay to the screensaver display on sunxi because I was tripping another collision handling bug there (I don't think it was this exact one, though, but I can't quite remember), so it makes sense.

As for the Notification thing, that's interesting, but I'd be inclined to leave it alone: it's perfectly normal for PM to fail if it happens too soon after a screen update. We handle that gracefully by waiting for the timeout again, and since it's likely to be in the one digit range of seconds, it feels like a non-issue to me ;).

(Still have'nt had time to test this; I'm hoping to deal with it tomorrow, but we'll probably merge this tomorrow regardless, as it looks perfectly sensible to me ;)).

As for the Notification thing

The NO_MERGE flag might help (because it bypasses said broken collision handling codepath), but we're probably already using it for Notifications because of my last attempt at dealing with the Libra 2 crashes?

(Can't check right now, though).

I think I have solved that issue (minimal invasive) by adding

    if dirty then
        Screen:afterPaint()
        self.last_after_paint_time = self:getElapsedTimeSinceBoot()       -- add this line
    end

and test for time.to_number(now - UIManager.last_after_paint_time) > 2 before entering standby in the autosuspend plugin.

Anyway I want to test this solution and optimize the time distance (the 2) and move that maybe to a device specific property.
If successful, I will do that in a subsequent PR.

Fair warning: I'll probably veto something like that, FWIW ;).

Fair warning: I'll probably veto something like that, FWIW ;).

To expand a bit on that, I'm happy with the current behavior (i.e., that PM fails too soon after a screen update is perfectly normal, we should handle that properly (and we do)), so attempting to deal with this corner-case seems like gratuitous complexity at first glance.

On the other hand, if that happens to, as a byproduct, workaround a sunxi display driver issue, that's another kettle of fish, and I might be more lenient with this ;).