Clara HD Display time when reading

[poczynek]

Originally Posted by frostschutz

Not really sure what is going on with the Forma, any chance any of you could enable debug=1 for a while? (guess I should have made that a debug log textfile instead of on-screen display... I might do that in the next version.)

Need more info or it's a blindfold guessing game

Yes all good - i will enable debug=1.

So i enable and then use it for a bit to test?

[poczynek]

Ok have enabled debug and tested with about 20 to 30 pages - just cycling through pages. I think the time and date came up every 3rd page maybe?

How do i export the debug file? The debugging comes up live on the top left of the Forma too for some pages.

[frostschutz]

there is no debug file yet... it just prints to the screen

so... does it print but not update the clock? then - just what did it print? ;-)

(the debug output also comes with an additional 3 second delay so... with debug on, if you turn page too quickly, not updateing is normal)

the interesting question is also if it prints anything when not interacting with the device at all ... basically there are events coming it that cause cooldown to kick in (when not in standby)

I previously assumed the magnet event only goes crazy during standby (sleepcover closed) and not while reading... but that assumption, might be wrong, or the input devices on the forma do something else unexpected

it's frustrating because everythign seems to be working just fine - on my H2O

[poczynek]

Originally Posted by frostschutz

there is no debug file yet... it just prints to the screen

so... does it print but not update the clock? then - just what did it print? ;-)

(the debug output also comes with an additional 3 second delay so... with debug on, if you turn page too quickly, not updateing is normal)

the interesting question is also if it prints anything when not interacting with the device at all ... basically there are events coming it that cause cooldown to kick in (when not in standby)

I previously assumed the magnet event only goes crazy during standby (sleepcover closed) and not while reading... but that assumption, might be wrong, or the input devices on the forma do something else unexpected

it's frustrating because everythign seems to be working just fine - on my H2O

Ah yes sorry i probably simulated reading a little too quickly with clicking through! I did a riveting 2 minute video - see:

https://streamable.com/abzo7

And attached a photo of a long debug message that occurred at the end.

[frostschutz]

OK, those are button events (KEY:F23 KEY:F24 in your video) as well as touchscreen event (ABS:MT_POSITION_X/Y on your photo). As long as you have these in your whitelist that is all normal up to here...

The version below changes the on-screen debug display to a debuglog.txt file to be found in .addons/miniclock/debuglog.txt (logs only if debug=1 is set in config file)

ithe logfile looks like

[1564039443 ABS:MT_TRACKING_ID 1]
[1564039443 ABS:MT_TOUCH_MAJOR 1]
[1564039443 ABS:MT_WIDTH_MAJOR 1]
[1564039443 ABS:MT_POSITION_X 935]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 09:24:05 CEST 2019 --
-- clock update Thu Jul 25 09:24:06 CEST 2019 --
-- clock update Thu Jul 25 09:24:07 CEST 2019 --
MiniClock debug event:
[1564039461 KEY:F1 1]
-- whitelist not matched - negative 1 --
MiniClock debug event:
[1564039462 KEY:F1 1]
-- whitelist not matched - negative 2 --
MiniClock debug event:
[1564039472 KEY:F1 1]
-- whitelist not matched - negative 3 --
-- cooldown start, Thu Jul 25 09:24:33 CEST 2019 --
-- cooldown end,   Thu Jul 25 09:25:03 CEST 2019 --

so this was me touching the touchscreen (MT_POSITION_X event), followed by updating clock x3 (due to delay = 1 1 1 setting), followed by three times magnet sensor (me testing with fridge magnet), after 3 negative events in a row there's a 30 second cooldown due to 'cooldown=3 30' setting.

this log will grow, uh, rather big over time. and although it prints times and dates, it might still be hard to corelate the log to real events if you don't remember when you pressed the keys ^^;

so if you notice miniclock misbehaving maybe you could note down the time or something then see if anything is in the log for that time frame

PS: oh, I see it actually misprints the BTN_TOUCH as 0x14a, gotta fix that (but unless you were trying to use BTN_TOUCH in the whitelist, that's not your issue)

PPS: edit - fixed in 20190725_b_

[poczynek]

Ah ok got it. Use this version - it will output to .txt file that will get big but make note when things look haywire for times.

Ok will do!

It does appear to be intermittent and will monitor over next few days.

Thanks again.

[jackie_w]

@frostschutz,

I've attached a small debug log below. I started with a full reboot then read at normal speed for a few minutes. I also tried to manually note down when a next page button succeeded or failed:

10:56 fail
10:57 OK
10:59 fail
11:01 OK
11:03 OK
11:04 OK
11:06 fail
11:08 OK
11:10 OK
11:11 fail

debuglog.txt

Spoiler:

MiniClock debug event:
[1564048299 KEY:POWER 1]
[1564048299 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 10:51:40 BST 2019 --
-- clock update Thu Jul 25 10:51:41 BST 2019 --
-- clock update Thu Jul 25 10:51:42 BST 2019 --
-- config file read Thu Jul 25 10:52:14 BST 2019 --
-- cfg_debug = '1', format {debug} = '0' --
-- cfg_whitelist = 'ABS:MT_POSITION_X ABS:MT_POSITION_Y KEY:F23 KEY:F24 KEY:POWER' --
-- cfg_whitelist (str2int) = ' 3:53 3:54 1:193 1:194 1:116' --
MiniClock debug event:
[1564048341 REP:DELAY 400]
[1564048341 REP:MAX 80]
[1564048341 MSC:RAW 24]
[1564048341 SYN:REPORT 0]
[1564048341 MSC:RAW 28]
[1564048341 SYN:REPORT 0]
-- whitelist not matched - negative 1 --
-- config file read Thu Jul 25 10:52:23 BST 2019 --
-- cfg_debug = '1', format {debug} = '0' --
-- cfg_whitelist = 'ABS:MT_POSITION_X ABS:MT_POSITION_Y KEY:F23 KEY:F24 KEY:POWER' --
-- cfg_whitelist (str2int) = ' 3:53 3:54 1:193 1:194 1:116' --
MiniClock debug event:
[1564048350 KEY:BTN_TOOL_FINGER 1]
[1564048350 KEY:BTN_TOUCH 1]
[1564048350 ABS:MT_TRACKING_ID 0]
[1564048350 ABS:MT_DISTANCE 0]
[1564048350 ABS:MT_POSITION_X 541]
[1564048350 ABS:MT_POSITION_Y 1202]
[1564048350 ABS:MT_PRESSURE 79]
[1564048350 ABS:MT_TOUCH_MAJOR 23]
[1564048350 ABS:MT_TOUCH_MINOR 23]
[1564048350 ABS:MT_ORIENTATION 123]
[1564048350 SYN:MT_REPORT 0]
[1564048350 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 10:52:31 BST 2019 --
-- clock update Thu Jul 25 10:52:32 BST 2019 --
-- clock update Thu Jul 25 10:52:34 BST 2019 --
MiniClock debug event:
[1564048359 MSC:RAW 24]
[1564048359 SYN:REPORT 0]
[1564048359 MSC:RAW 28]
[1564048359 SYN:REPORT 0]
-- whitelist not matched - negative 1 --
MiniClock debug event:
[1564048388 KEY:F24 1]
[1564048388 SYN:REPORT 0]
[1564048475 KEY:F24 0]
[1564048475 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 10:54:36 BST 2019 --
-- clock update Thu Jul 25 10:54:37 BST 2019 --
-- clock update Thu Jul 25 10:56:11 BST 2019 --
MiniClock debug event:
[1564048575 MSC:RAW 24]
[1564048575 SYN:REPORT 0]
[1564048575 MSC:RAW 28]
[1564048575 SYN:REPORT 0]
-- whitelist not matched - negative 1 --
MiniClock debug event:
[1564048581 MSC:RAW 24]
[1564048581 SYN:REPORT 0]
[1564048581 MSC:RAW 28]
[1564048581 SYN:REPORT 0]
-- whitelist not matched - negative 2 --
MiniClock debug event:
[1564048586 KEY:F24 1]
[1564048586 SYN:REPORT 0]
[1564048665 KEY:F24 0]
[1564048665 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 10:57:46 BST 2019 --
-- clock update Thu Jul 25 10:57:48 BST 2019 --
-- clock update Thu Jul 25 10:59:54 BST 2019 --
MiniClock debug event:
[1564048800 KEY:F24 1]
[1564048800 SYN:REPORT 0]
[1564048890 KEY:F24 0]
[1564048890 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 11:01:30 BST 2019 --
-- clock update Thu Jul 25 11:01:32 BST 2019 --
-- clock update Thu Jul 25 11:01:33 BST 2019 --
MiniClock debug event:
[1564048896 KEY:F24 1]
[1564048896 SYN:REPORT 0]
[1564048994 KEY:F24 0]
[1564048994 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 11:03:14 BST 2019 --
-- clock update Thu Jul 25 11:03:16 BST 2019 --
-- clock update Thu Jul 25 11:03:17 BST 2019 --
MiniClock debug event:
[1564049000 KEY:F24 1]
[1564049000 SYN:REPORT 0]
[1564049090 KEY:F24 0]
[1564049090 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 11:04:51 BST 2019 --
-- clock update Thu Jul 25 11:04:53 BST 2019 --
-- clock update Thu Jul 25 11:06:24 BST 2019 --
MiniClock debug event:
[1564049190 KEY:F24 1]
[1564049190 SYN:REPORT 0]
[1564049299 KEY:F24 0]
[1564049299 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 11:08:19 BST 2019 --
-- clock update Thu Jul 25 11:08:21 BST 2019 --
-- clock update Thu Jul 25 11:08:22 BST 2019 --
MiniClock debug event:
[1564049305 KEY:F24 1]
[1564049305 SYN:REPORT 0]
[1564049408 KEY:F24 0]
[1564049408 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 11:10:09 BST 2019 --
-- clock update Thu Jul 25 11:10:11 BST 2019 --
-- clock update Thu Jul 25 11:11:50 BST 2019 --
MiniClock debug event:
[1564049514 KEY:BTN_TOOL_FINGER 1]
[1564049514 KEY:BTN_TOUCH 1]
[1564049514 ABS:MT_TRACKING_ID 0]
[1564049514 ABS:MT_DISTANCE 0]
[1564049514 ABS:MT_POSITION_X 1165]
[1564049514 ABS:MT_POSITION_Y 791]
[1564049514 ABS:MT_PRESSURE 99]
[1564049514 ABS:MT_TOUCH_MAJOR 23]
[1564049514 ABS:MT_TOUCH_MINOR 23]
[1564049514 ABS:MT_ORIENTATION 124]
[1564049514 SYN:MT_REPORT 0]
[1564049514 SYN:REPORT 0]
[1564049514 KEY:BTN_TOUCH 0]
[1564049514 KEY:BTN_TOOL_FINGER 0]
[1564049514 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 11:12:05 BST 2019 --
-- clock update Thu Jul 25 11:12:06 BST 2019 --
-- clock update Thu Jul 25 11:12:07 BST 2019 --
MiniClock debug event:
[1564049531 KEY:BTN_TOOL_FINGER 1]
[1564049531 KEY:BTN_TOUCH 1]
[1564049531 ABS:MT_TRACKING_ID 0]
[1564049531 ABS:MT_DISTANCE 0]
[1564049531 ABS:MT_POSITION_X 1318]
[1564049531 ABS:MT_POSITION_Y 786]
[1564049531 ABS:MT_PRESSURE 89]
[1564049531 ABS:MT_TOUCH_MAJOR 23]
[1564049531 ABS:MT_TOUCH_MINOR 23]
[1564049531 ABS:MT_ORIENTATION 124]
[1564049531 SYN:MT_REPORT 0]
[1564049531 SYN:REPORT 0]
[1564049531 ABS:MT_TRACKING_ID 0]
[1564049531 ABS:MT_DISTANCE 0]
[1564049531 ABS:MT_POSITION_X 1320]
[1564049531 ABS:MT_POSITION_Y 792]
[1564049531 ABS:MT_PRESSURE 27]
[1564049531 ABS:MT_TOUCH_MAJOR 23]
[1564049531 ABS:MT_TOUCH_MINOR 35]
[1564049531 ABS:MT_ORIENTATION 122]
[1564049531 SYN:MT_REPORT 0]
[1564049531 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 11:12:12 BST 2019 --
-- clock update Thu Jul 25 11:12:14 BST 2019 --
-- clock update Thu Jul 25 11:12:15 BST 2019 --
MiniClock debug event:
[1564049546 MSC:RAW 26]
[1564049546 SYN:REPORT 0]
[1564049546 MSC:RAW 28]
[1564049546 SYN:REPORT 0]
-- whitelist not matched - negative 1 --
MiniClock debug event:
[1564049549 MSC:RAW 23]
[1564049549 SYN:REPORT 0]
[1564049549 MSC:RAW 27]
[1564049549 SYN:REPORT 0]
-- whitelist not matched - negative 2 --
MiniClock debug event:
[1564049550 KEY:BTN_TOOL_FINGER 1]
[1564049550 KEY:BTN_TOUCH 1]
[1564049550 ABS:MT_TRACKING_ID 0]
[1564049550 ABS:MT_DISTANCE 0]
[1564049550 ABS:MT_POSITION_X 1311]
[1564049550 ABS:MT_POSITION_Y 797]
[1564049550 ABS:MT_PRESSURE 113]
[1564049550 ABS:MT_TOUCH_MAJOR 23]
[1564049550 ABS:MT_TOUCH_MINOR 23]
[1564049550 ABS:MT_ORIENTATION 124]
[1564049550 SYN:MT_REPORT 0]
[1564049550 SYN:REPORT 0]
-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 11:12:32 BST 2019 --
-- clock update Thu Jul 25 11:12:33 BST 2019 --

A small observation, in case it helps. I had a feeling that when a next button failed, there was a brief sighting of an updated time/battery display AFTER the button press but BEFORE the page actually turned. But once the page turn had completed the display was blank.

ETA: I forgot to mention that there was no excessive battery drain overnight with the Forma on standby in a magnetic sleepcover. So definite progress on that front.

[frostschutz]

[1564048341 REP:DELAY 400]
[1564048341 REP:MAX 80]
[1564048341 MSC:RAW 24]
[1564048341 SYN:REPORT 0]
[1564048341 MSC:RAW 28]
[1564048341 SYN:REPORT 0]

These events are new to me (also REP:MAX should be REP:PERIOD... the woes of parsing input-event-codes.h in reverse :-) ). I don't see anything the like on my H2O. They didn't trigger cooldown for you in this instance but it came close (event occured 2 times in a row when 3 times by default triggers the cooldown).

-- whitelist match -- 
-- cfg_delay = '1 1 1' --
-- clock update Thu Jul 25 10:54:36 BST 2019 --
-- clock update Thu Jul 25 10:54:37 BST 2019 --
-- clock update Thu Jul 25 10:56:11 BST 2019 --

There should be 1 second delay between these but it turned out as almost 2 minutes. Issue repeates at 10:59 and 11:06.

This is probably a case of nickel putting background process in the freezer.

EDIT: You could try and see if it improves by setting delay=1 or delay=2 onstead of 1 1 1. but delay=1 will miss update time if the pageturn (or other screen refresh action) is slower than 1 second. pageflips on H2O can be quite slow hence I used 1 1 1 but maybe Forma has faster pageflip so delay=1 will work. :EDIT

With the current code I guess it is possible to miss the first event after wakeup... as during those 2 minutes, the update was still in progress and no new events were listened to. Most likely the 10:56:11 update then happened straight on wakeup, to be erased by the pageflip that follows.

[jackie_w]

Originally Posted by frostschutz

EDIT: You could try and see if it improves by setting delay=1 or delay=2 onstead of 1 1 1. but delay=1 will miss update time if the pageturn (or other screen refresh action) is slower than 1 second. pageflips on H2O can be quite slow hence I used 1 1 1 but maybe Forma has faster pageflip so delay=1 will work.

Encouraging news, I think. I set the config to delay=2 and read a whole chapter (kepub with 29 screenfulls), at normal reading speed (not very fast), using only the Next button to turn pages. The only failure I had was on the first page as the new chapter was being loaded. As well as text, this page also needed to render a medium-size image (620x620) and a dropcap which referenced a sideloaded fancy font (rather than embedded font).

I suppose this extra rendering time might have contributed to the failure, but when I turned (via button) to the first page of the next chapter there was no failure.

I'm going to turn off debug now and see how it goes.

[Bean_There]

Hi, Like this a lot and have got it installed with a ttf and tuned-in position just right. My question is how to format for a font color other than black or white (i.e. gray)?


I see in the config file the following:
# Color: (BLACK GRAY{1-9A-E} WHITE)
#
fg_color=BLACK
bg_color=WHITE

but any attempt I've made to get gray working breaks something.

Any pointers? I've searched the thread but can't find anything.

Thanks!

[NiLuJe]

@Bean_There: Full list here (i.e., GRAY1 to GRAYE in base16).

@frostschutz: Ah, yeah, that'd be the Forma key repeats and the Gyro status over MSC events .

[NiLuJe]

@frostschutz: I was vaguely wondering if we could somewhat get rid of the delay= shenanigans by plotting a pixel (say, the last one on the bottom right) in a specific sentinel color (say, 0xEE), then checking regularly if it hadn't been cleared to white (as the very bottom-right corner pixel ought to be white pretty much everywhere except the USB screen), which would indicate that the page has been redrawn...

[jackie_w]

Originally Posted by NiLuJe

... then checking regularly if it hadn't been cleared to white (as the very bottom-right corner pixel ought to be white pretty much everywhere except the USB screen), which would indicate that the page has been redrawn...

... unless the screen is in Inverted mode, when it would (mostly) be black.

[NiLuJe]

Not at the framebuffer level, the inversion is done by the eInk controller at refresh time .

(... unless you're running a mightily old legacy nightmode hack that did in in software, brrr.)

[jackie_w]

Originally Posted by NiLuJe

Not at the framebuffer level, the inversion is done by the eInk controller at refresh time .

(... unless you're running a mightily old legacy nightmode hack that did in in software, brrr.)

I should know better than to attempt to argue tech with you