Dear Notaz and EvilDragon!
I detected differing behavior of the state of PND games while Standby.
Some properly resume just where your left off, some have progress a little (less than real time) in the meantime, some have progressed equivalent to real time.
And also concerning the state in which the machine really gets depending on the running PND, differs! Traced this with dmesg!
Fact is: If the system detects a running PND, it goes not into standby, but rather only into Low Power Mode (which is also quite good concerning battery runtime, but
Standby is about 4 times more efficient than Low Power mode, total runtime with Standby ~180
hours, with Low Power Mode 30-75 hours). Thus you first need to manually pause your game, then suspend, else your game runs on (in the Low Power Mode)!
The Low-Power mode has ALWAYS paused PNDs
This was definitely not 'ALWAYS' true for Low Power Mode in the past. In multiple games, after resume your game state has progressed far. Where I remember it certainly: Super Methane Brothers.
I did the standby test with Super Methane Brothers no under Beta 3, and it pauses/resumes correctly!
See a whole PND standby test series below.
and it sure does this on my unit (I've been playing PSX games all weekend long and were only taking breaks by directly going into low-power mode).
Glad to hear that, but I hope you understand my skepticism from the observations I made with the other PNDs.
Could it be somehow that Gianas Return uses the clock (or some other timer that continues to run) and updates itself once it starts up again?
The direction of your guess is the only plausible explanation if the Pandora was indeed in proper Standby and not only in Low Power Mode BUT nevertheless the game has progressed as much as real time happened. Maybe some games calculate everything which happened in that long execution pause at once on resume, (and drop quite many many thousand frames to catch up). But I don't know much about timing and game development. Info anyone?
Suspending with running PNDs works now!? Sort of...
Fact is: If the system detects a running PND, it goes not into standby, but rather only into Low Power Mode (which is also quite good concerning battery runtime, but
Standby is about 4 times more efficient than Low Power mode, total runtime with Standby ~180 hours, with Low Power Mode 30-75 hours). Thus you first need to manually pause your game, then suspend, else your game runs on (in the Low Power Mode)!
Proof: Game "Giana's Return" running, game countdown at 140 seconds. Sliding power button to start standby. OP (seemingly) goes into standby. Power LED lights in less bright green (indicating standby). Waiting 60 seconds (with stop clock) then sliding power button again. OP resumes, screen goes on, "Giana's Return" is immediately responsive, counter at 79 seconds. Exactly 60 seconds, as in real time, have passed in the game! (The 1 seconds rounding error is just my finger/eye delay. 140 - 79 = 61 = 60 + 1)
I've just checked this, it does the unsafe suspend, and time passed is compensated on resume, otherwise it would confuse programs that try any kind of real time tracking. If you suspend for longer time with Giana, you'll see her death animation and only 1 life loss on resume, even if you suspend for 1 hour.
Checked dmesg, and it further proofs this.
For a real standby the Pandora logs:
Code:
Successfully put all powerdomains to target state.
For an attempted standby the Pandora logs:
Code:
Powerdomain (per_pwrdm) didn't enter state 1
Powerdomain (core_pwrdm) didn't enter state 1
Could not enter target state in pm_suspend
And then chooses Low Power Mode instead.
Seems to be unrelated bug, OMAP fails to suspend fully, perhaps because audio DMA is not drained.
The log file events are no coincidence, an unrelated bug unlikely.
All the power state success/failure messages correlate with my attempts to suspend/resume while having active PNDs!
See the chart below to learn the correlations, which I could always reproduce.
Standby test in various PND applications (via power slider)
Chart Format:
PND's Title
App resuming: Whether the running PND continued slow or fast and correct or with glitches.
Game State: Does it continue where you left off, or did the game "progress" while standby? (Whatever the technical reason is)
dmesg: Are there any time correlated power state messages in the system log file? (To ensure to not confuse it with the message from a more recent PND or Standby event, I always noted the last timestamp, to be sure that the next log message is really related to my PND / standby actions.)
MiniMenu idle
App resuming: Instantly without any glitches.
dmesg: Successfully put all powerdomains to target state.
Super Methane Brothers
Game State: Resumed properly (quickly moving opponents at same position as remembered).
App resuming: Instantly without any glitches.
dmesg: Could not enter target state in pm_suspend
GNU Jump
Game State: Game progressed, was already over on resume.
App resuming: Instantly without any glitches.
dmesg: The exceptional case: No log events for that time frame, neither confirming suspend success nor failure!
Hamster's Escape
Game State: Resumed properly (score, which normally quickly changes, was still same)
App resuming: Instantly without any glitches.
dmesg: Could not enter target state in pm_suspend
Primate Plunge
Game State: Game progressed, score 3 was suddenly 17 on resume, and game was over.
App resuming: Instantly without any glitches.
dmesg: Could not enter target state in pm_suspend
Retrobattle
Game State: Game progressed about 10 times slower than real time. Timer was at 195, suspended for 60 seconds, on resume timer continued at 188.
App resuming: Instantly without any glitches.
dmesg: Could not enter target state in pm_suspend
Super Geometry Dust
Game State: Could not resume after standby. Counter was at 10 secs, suspended. Tried to wake after 60 secs. Power slider has no effect. Crashed? Okay, seems that Super Geometry Dust has some troubles under Beta 3 now. Had to do a hard reset. Other topic.
Mr Drillux
Game State: Resumed properly (Quickly dropping air percentage (=timer) continued exactly, where it stopped).
App resuming: Instantly without any glitches.
dmesg: Could not enter target state in pm_suspend