View Single Post
Old 08-31-2010, 10:11 AM   #74
CoolDragon doesn't litterCoolDragon doesn't litter
Posts: 232
Karma: 122
Join Date: Feb 2010
Device: none
My clock solution

Originally Posted by Mackx View Post
When the UDS is pre-rendering pages, it can delay idle mode by using the background busy ipc-call ("sysSetBgBusy"). This would allow the clock updates to continue until pre-rendering is finished. I think that is what you are seeing. The extra eripc-call makes sure that the change is 'significant-enough' to trigger a screen-update I guess.
Ahhhhh, the pre-rendering...... that makes perfect sense

I don't understand how can the eripc call trigger a screen update if the CPU clock is disabled. Anyway, it doesn't matter now. So here is the solution:

Since it is not worth the battery to update the clock by itself, we will leave the clock timeout to be anyway between 30s-60s. If the device is busy for more than this period, the clock will be updated automatically, and the power overhead should be minimal.

Add this line to the end of /usr/bin/
dbus-send --print-reply --dest='com.irexnet.popupmenu' /com/irexnet/popupmenu com.irexnet.popupmenu.updatesFinished
So after resume from idle, do a clock sync with hwclock, and update the clock. Any external event will trigger this resume: flipbar click, page turn, menu popup, stylus click....

Of course we need to change the code a little bit:
1. At the beginning of statusbar_update_toolbar() (statusbar.c), call toolbar_timeout_clock()
2. To avoid potential re-entry problem of toolbar_timeout_clock(), though very unlikely, add a semaphore around it.

static gboolean in_clock = FALSE

static gboolean toolbar_timeout_clock()
    if ( in_clock )
       return TRUE;
    in_clock = TRUE;
    ..... //update clock
    in_clock = FALSE;
    return TRUE;
This has been working great on my device!
CoolDragon is offline   Reply With Quote