View Single Post
Old 08-27-2010, 12:00 PM   #56
CoolDragon
Addict
CoolDragon doesn't litterCoolDragon doesn't litter
 
Posts: 244
Karma: 124
Join Date: Feb 2010
Device: none
Quote:
Originally Posted by Iņigo View Post
Ok, We have it!!! Now clock label does automatic refreshes, no need to change page or anything.

The trick was Mackx's idea of using an eripc call with updatePageCounter message. A bit hackish but it works.
You can see the code in: https://bitbucket.org/inigoserna/dr8...t/3ee425f2e073

Clock is updated every 30 secs but I can't see any battery drain. It continues on 89% as 10 minutes ago when I installed the new popupmenu.
Anyway, perhaps we should change to do the checks every 1 min.

EDIT: WARNING: I've observed some inestabilities after installing this version of popupmenu!

Btw, I've already uploaded new erbrowse and notepad versions to BB.

Could anyone test if they work correctly before launching a new release tomorrow? They work well both in qemu and in my DR800S.
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?

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.

If Gertjan can provide some explanation, it would be very helpful.
CoolDragon is offline   Reply With Quote