DR800 DR800+ development discussion

[Iñigo]

Originally Posted by CoolDragon

OK, now your markup becomes handy. Just wrap the string with <tt> and </tt>.

Good idea!

Originally Posted by CoolDragon

By the way, <big></big> seems a little bit too big, the default size (nothing specified) is the same as gtk_button_set_label()

That was the poll. c) same size e) big size

You have time to vote until friday 23:59:59 UTC+2.
Call +234 54764579823463244
0.25 EUR price first minute, then 0.10

[CoolDragon]

Originally Posted by CoolDragon

This seems to further justify Mackx's hypothesis: on the real device, if you tap on the separator(blank space between toolbar icons and status icons), the clock will update very nicely (just the changed digits, nothing else).

So what's the easy way to trigger this event in statusbar_timeout_clock()?

Actually, this is not limited to the separator, as long as it is some widget that accepts a "click" event, such as the separator, the "cycling icon(pen, eraser, pan, etc), any status icon, taskbar label, or taskbar blank space.

So, someone knows a way to fake such an event?

[Iñigo]

Originally Posted by CoolDragon

Actually, this is not limited to the separator, as long as it is some widget that accepts a "click" event, such as the separator, the "cycling icon(pen, eraser, pan, etc), any status icon, taskbar label, or taskbar blank space.

So, someone knows a way to fake such an event?

I don't know.
Anyway if we "fix" this issue, waking the device from the microsuspend state, will drain battery so maybe it's better to make it require human action or wait until the device does something. What do you think?

BTW, I've uploaded a DR1000-like notepad onto BB (bitbucket).
Next will be erbrowse, and after that a new release with these 3 changes (clock, notepad, erbrowse).

[CoolDragon]

Anyway if we "fix" this issue, waking the device from the microsuspend state, will drain battery so maybe it's better to make it require human action or wait until the device does something. What do you think?

I agree with the potential battery drain issue. If we can find a way to trigger such event on a page turn (flipbar left/right) event, it should be good enough.

[Mackx]

Originally Posted by Iñigo

I don't know.
Anyway if we "fix" this issue, waking the device from the microsuspend state, will drain battery so maybe it's better to make it require human action or wait until the device does something. What do you think?

Yes keeping it 'awake', just for the clock isn't a good idea.
I assume that UDS after a page change sends the updatePageCounter-message to popupmenu, maybe also the updatesFinished-message. Is it possible to react on those event to update the clock (on a page-change), i.e. update the clock in the statusbar_update_toolbar() - function. (Or is that already working with the current implementation?)

[Iñigo]

Originally Posted by Mackx

Yes keeping it 'awake', just for the clock isn't a good idea.
I assume that UDS after a page change sends the updatePageCounter-message to popupmenu, maybe also the updatesFinished-message. Is it possible to react on those event to update the clock (on a page-change), i.e. update the clock in the statusbar_update_toolbar() - function. (Or is that already working with the current implementation?)

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.

[Mohammad Reza]

Originally Posted by Iñigo

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.

hum.mm.mmmm !
good work Iñigo

I am a little confused. When our clock precision is 1 min why do we need to refresh clock every 30 secs !?

anyway, guys for making my reading experience something different from before

[Mohammad Reza]

Originally Posted by Mackx

I guess the device will go into 'suspend-mode' after 5 seconds and will only 'wake-up' from external events (buttons, stylus). Does it update the clock when switching pages?

I don't know if the popupmenu code reuploaded or not, but mine does update on switching pages.

[Iñigo]

Originally Posted by Mohammad Reza

hum.mm.mmmm !
good work Iñigo

I am a little confused. When our clock precision is 1 min why do we need to refresh clock every 30 secs !?

anyway, guys for making my reading experience something different from before

Suppose your update is scheduled every 1 minute, starting at 11:11:54.
Until 11:12:54 the clock would still show previous time, 11:11. That is, it would be wrong for 54 secs in this example. Maximum possible error is 59 secs.

Updating every 30 secs would improve the precision. 24 secs in previous example and 29 secs as worst.

Anyway, I don't think that level of precision is important, and thus I proposed the change to 1 min. Less battery consumption as well.
We even could change time rounding up to next minute if secs > 30.

[Iñigo]

Originally Posted by Mohammad Reza

I don't know if the popupmenu code reuploaded or not, but mine does update on switching pages.

Which bitbucket revision are you using?

Btw, which look&feel do you prefer? https://www.mobileread.com/forums/sho...4&postcount=23
Option f) is font with fixed size

[CoolDragon]

Originally Posted by Iñigo

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.

[Iñigo]

Originally Posted by CoolDragon

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?

Originally Posted by CoolDragon

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?).

Originally Posted by CoolDragon

If Gertjan can provide some explanation, it would be very helpful.

Yep, that would help a bit...

[CoolDragon]

I have tested your binary on my dr800sg. Here is the story:

Rebooting the device, the clock is up-to-date. Do nothing, the clock automatically updated about 30 seconds later (same as what you see). Using flipbar to go to my directory, in between, the clock updates again.

Opened a PDF file, doing nothing for more than 1 min. Clock is not updated. Using flipbar to go to next page, after about 30 seconds, it updates. Doing nothing on the current page for more than 1 min, clock is not updated. Using flipbar to next page, clock updated after some seconds. Repeating this, sometimes, clock is updated in several seconds after page turning.

In the folder view, clock does not update when staying in the same directory, changing directory of course updates.

Tried checking battery status several times, no hanging. Maybe just lucky. :-)

So, this behavior sort of justifies my assumption(based on Mackx's hypothesis): in-activity for longer than 5 seconds will stop a user timer, and some external events (such as page turning using flipbar, or flipbar press to other directory etc) will restore the user timer. The thing that doesn't justify my assumption is that with your binary, in PDF view, clock updates after about 30 seconds. It appears that the clock timer is restarted by the flipbar turning, and not paused/stopped after 5 seconds of in-activity. There might be another timer in the display hardware?

Anyway, I have tested a clock timer of 6 seconds (less than 5 may prevent CPU from suspending, not sure), and not calling eripc in the clock update function. Without activity, clock won't update by itself. But after every page turning, it will do a nice local update after about 5-6 seconds. This is quite acceptable, although I have to test the battery consumption rate.

By the way, it's best to have fixed font for the clock, otherwise, a local refresh of the toolbar becomes a little bit messy due to the changed width of clock string.

[Iñigo]

Originally Posted by CoolDragon

I have tested your binary on my dr800sg. Here is the story:

Rebooting the device, the clock is up-to-date. Do nothing, the clock automatically updated about 30 seconds later (same as what you see). Using flipbar to go to my directory, in between, the clock updates again.

Opened a PDF file, doing nothing for more than 1 min. Clock is not updated. Using flipbar to go to next page, after about 30 seconds, it updates. Doing nothing on the current page for more than 1 min, clock is not updated. Using flipbar to next page, clock updated after some seconds. Repeating this, sometimes, clock is updated in several seconds after page turning.

In the folder view, clock does not update when staying in the same directory, changing directory of course updates.

Tried checking battery status several times, no hanging. Maybe just lucky. :-)

Your experiences are similar than mine, I get some refresh on folders view though.
And the behaviour I see is not so random (only refreshes with page changing, not after some seconds).

The hangs were produced clicking on battery every 30-60 secs during 5-10 minutes. Maybe it's the effect of not having a 'g' in my device

Originally Posted by CoolDragon

So, this behavior sort of justifies my assumption(based on Mackx's hypothesis): in-activity for longer than 5 seconds will stop a user timer, and some external events (such as page turning using flipbar, or flipbar press to other directory etc) will restore the user timer. The thing that doesn't justify my assumption is that with your binary, in PDF view, clock updates after about 30 seconds. It appears that the clock timer is restarted by the flipbar turning, and not paused/stopped after 5 seconds of in-activity. There might be another timer in the display hardware?

Anyway, I have tested a clock timer of 6 seconds (less than 5 may prevent CPU from suspending, not sure), and not calling eripc in the clock update function. Without activity, clock won't update by itself. But after every page turning, it will do a nice local update after about 5-6 seconds. This is quite acceptable, although I have to test the battery consumption rate.

By the way, it's best to have fixed font for the clock, otherwise, a local refresh of the toolbar becomes a little bit messy due to the changed width of clock string.

I don't like the idea of having a timer every 4-6 secs.

Current implementation is not perfect, but it somehow works... I prefer to have something working that waiting until we discover the solution.

So what do you think if I do a public release of current code (i.e. with eripc) but 1 min. timer and tt font? Is robust enough?

[CoolDragon]

I don't like the idea of a 4-6 sec timer either, such a waste. It is just an experiment to "guess" how the hardware/firmware/os works with regard to timers and timer's timeout events.

Anyway, I'll say go ahead with a public release with eripc, 1 min, and tt font. Seems to be stable enough on my device (although I have one more toolbar icon and smaller gap between clock and icons :-) ).

By the way, you don't need to pass "button" to statusbar_timeout_clock, g_menu_button is static, just register the function and call it after g_menu_button is assigned.