View Single Post
Old 08-27-2010, 12:42 PM   #57
Iņigo
Guru
Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.Iņigo did not drink the Kool Aid.
 
Posts: 730
Karma: 72743
Join Date: Feb 2008
Location: Here or there
Device: iRex iLiad, iRex DR800S. K4NT. Kobo Aura, Aura One, Libra 2.
Quote:
Originally Posted by CoolDragon View Post
Hi Iņigo,

Unfortunately, unfortunately, this eripc trick doesn't help on my device (dr800sg), still the same behavior as without the ipc call. What do you see on your device if you don't touch anything for more than 1 minute?
That's strange, it works (* see comment below) on my DR800S with some random behaviour, but works.
Could you test attached binary, please?

Quote:
Originally Posted by CoolDragon View Post
I believe Mackx is correct with regard to this CPU suspended after 5 seconds of no activity. And there seems to be another timer that controls or schedules screen update (reading sysd code).

Anyway, if the CPU suspend only causes a pause of the timer, decrease the timer should increase the probability that the clock be updated after a page turn. For example, after system reboots, the clock timer starts, along with the CPU suspend timer. After 5 seconds, the CPU suspends, along with the clock timer. Next time some external event happens, the CPU resumes, along with the clock timer. If the remaining time of the clock timer is less than 5 seconds, it will timeout during this 5 second window. So when the clock updates really depends on the frequency of external events.

The more important question is: if the timeout event of a user function will reset this CPU suspend timer (5 seconds). If it does, then the clock timeout period should be larger than 5 seconds, otherwise, it will disable the CPU suspend timer and cause significant battery drain. If it doesn't, then it doesn't matter how long this clock timeout is.
The suspend finishes when some external action is triggered... but the question is if this external action must be physical (button pressed) or could be logical (a refresh request from software).

(*) what I referred as this last version "randomly" works means that it works for the first minutes but if there is no action on some time the clock will not refresh until next action. And so on.
Thus, again, 2 internal timers?

I also observed some race conditions, f.e. clicking on the battery icon to see the real % blocked the device a couple of times (clock tried to refresh at the same time?).

Quote:
Originally Posted by CoolDragon View Post
If Gertjan can provide some explanation, it would be very helpful.
Yep, that would help a bit...
Attached Files
File Type: gz popupmenu.dr800+.gz (27.8 KB, 334 views)
Iņigo is offline   Reply With Quote