Clara HD Display time when reading

[NiLuJe]

It could potentially be done, but only in conjunction with a custom Nickel patch to prevent it from grabbing the input device exclusively... (which I *think* @frostschutz has some experience with?).

[frostschutz]

it can be done, it's even simple to do, I just didn't get around to it yet

[frostschutz]

Originally Posted by frostschutz

Update 2019-07-17: add button support ( add button=1 in miniclock.cfg to enable )

Please test.

# This update caused battery drain so I removed it.

[NiLuJe]

Random notice: You may end up with *slighty* (like, 1px) larger fonts than before w/ TTF/OTF fonts. On the upside, you can now use decimal values for the TTF/OTF font size .

[jackie_w]

Originally Posted by frostschutz

Update 2019-07-17: add button support ( add button=1 in miniclock.cfg to enable )

I only installed it on my Forma 5 minutes ago but the new buttons option seems to work fine at first glance.

I'll report back if anything strange happens later on.

Thank you very much

[poczynek]

EDITED - worked it out

[poczynek]

Ok so installed 5 hours ago and all good. Left it sleeping.

Has now dropped 40% battery in 5 hours with no use.

I know it shouldn't affect battery drain but not sure what to do?

[frostschutz]

Originally Posted by poczynek

Has now dropped 40% battery in 5 hours with no use.

I know it shouldn't affect battery drain but not sure what to do?

What are your settings? (update=60, button=1, delay=...?)

Which Kobo firmware version?

It's possible for there to be a bug. Not noticed any drain on mine H2O so far, though. Added some debug messages and all looked normal at first glance.

(MiniClock does update the screen, and that uses some battery. But it should not be so excessive as to drain the battery in a day. You'd have to do a LD_PRELOAD hack to piggyback it onto nickel's own framebuffer updates to get rid of additional screen update overhead.)

[poczynek]

Originally Posted by frostschutz

What are your settings? (update=60, button=1, delay=...?)

Which Kobo firmware version?

It's possible for there to be a bug. Not noticed any drain on mine H2O so far, though. Added some debug messages and all looked normal at first glance.

(MiniClock does update the screen, and that uses some battery. But it should not be so excessive as to drain the battery in a day. You'd have to do a LD_PRELOAD hack to piggyback it onto nickel's own framebuffer updates to get rid of additional screen update overhead.)

Yes am sure i did something wrong. I did notice a kfmon error message when i rebooted a few times but that has gone now. I ended up resetting to make sure and have just reloaded it all so will monitor next few hours.

Am sure it is my mistake!

Yes sorry am on latest firmware 4.15 and have not changed default update settings. Made minor changes to font and placement of font.

EDIT

Here are my update settings:

touchscreen=0
button=1

#
# Update frequency: (update once every 60 seconds)
#
update=60

#
# Delay: (update delay 1 second repeat 3 times)
#
delay=1 1 1

#
# Repeat: (deprecated setting, use multiple delay instead)
#
# repeat=3

[frostschutz]

Okay, there is one possibility. Are you using a sleep cover with magnet?

MiniClock reacts to any button activity, without looking at the specific keycodes. (Same as touchscreen - touch anywhere, without caring whether you touched a "pageflip" action or something else entirely).

Now, unfortunately, the magnet sensor... technically it is also a keyboard button. So any perceived change in magnetism also triggers a button event, which in turn causes MiniClock to wake up and update.

And that happens even if you disable sleepcover support in the settings. The magnet sensor is always active (or at least that is the case on my H2O), best you can hope for that magnet events are ignored, which MiniClock does not know how to do.

[Terisa de morgan]

Originally Posted by frostschutz

Okay, there is one possibility. Are you using a sleep cover with magnet?

MiniClock reacts to any button activity, without looking at the specific keycodes. (Same as touchscreen - touch anywhere, without caring whether you touched a "pageflip" action or something else entirely).

Now, unfortunately, the magnet sensor... technically it is also a keyboard button. So any perceived change in magnetism also triggers a button event, which in turn causes MiniClock to wake up and update.

And that happens even if you disable sleepcover support in the settings. The magnet sensor is always active (or at least that is the case on my H2O), best you can hope for that magnet events are ignored, which MiniClock does not know how to do.

Strange. Kobo Clare here, with sleep cover and mini-clock, and no drain.

[jackie_w]

@frostschutz,

I didn't get time to do any more reading after my previous post, so my Forma was in standby mode for about 14 hours before I opened it again. The battery had dropped from 94% to completely dead. The Forma was in a magnetic sleepcover the whole time.

To test your magnet theory I'll remove the cover and disable the auto sleep/wakeup setting before settling down to read for a couple of hours. I'll report back later.

[frostschutz]

Originally Posted by Terisa de morgan

Strange. Kobo Clare here, with sleep cover and mini-clock, and no drain.

using the latest version from yesterday?

with button=1 or button=0 in miniclock.cfg?

the current theory is the issue only happens with button=1

I'll try to add a {DEBUG} option as format string so it will show onscreen what triggered the update (touchscreen, button or simple update frequency timeout).

That way if you get button updates even though no button was touched, you know something else in the keyboard is being noisy.

I didn't think of this problem beforehand... I don't use sleep cover and my H2O has no buttons (other than the power button) so keyboard has radio silence most of the time.

[frostschutz]

Something to test. Set your date format string to {debug} or {debug}{battery} or the like.

{debug} will show the event type that caused miniclock to update, (touch)screen, (butt)on, or update (freq)uency (with update=60 that's once per minute - if the device is not asleep).

So current theory is you get a lot of "touch butt" events even when not touching buttons or screens.

If not then it's something else.

# This update caused battery drain so I removed it.

[frostschutz]

OK, now I can reproduce the issue with my H2O.

Put the device into standby, all is fine. Use a refrigerator magnet to wiggle the sensor a bit: even though the device is supposed to be sleeping, and sleepcover support is turned off, the magnet sensor wakes the device and MiniClock updates.

Worse, the device does not go back to sleep when removing the magnet, instead for some mysterious reason it keeps receiving touchscreen events in an endless loop(*). It does not stop at all. So the clock keeps updating and updating while sleeping and yes, eventually that will drain the battery, for the screen updates for one, and due to the device itself only pretending to be in low power (standby) state when it's really not.

At this point I'm not sure what to do about it. I'm also not sure if this is just a bug in Kobo firmware itself or the modification that's keeping the device awake, etc. In any case, it's weird and even if I took the effort of ignoreing the magnet key event, that does still not fix the issue.

(*)This may be misbehavior of how I'm reading the touchscreen... not entirely sure what's going on there, yet.