Clara HD Display time when reading

[desterly]

Originally Posted by 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...

That would only work after a full screen refresh though no?

IE: I have mine set to only refresh after X number of pages (say 10). With this method, pages 1-9 the pixel would still be set.

What we really need is a way to

1) check if currently reading a book (probably could get this from the events but would need to watch the sqlite db then)

2) monitor for frame buffer calls...

If both of those were true, the clock would need to be redrawn.


This is an off the wall question I know but has anyone looked into using the actual Kobo plugins to extend functionality??

Ran across an older github example that shows doing things like hiding the footer, etc utilizing that.

[NiLuJe]

Nope, the reader re-renders the full page no matter what (you can check by running fbink -Vmph -y -1 " ", that'll draw a black band at the bottom of the screen).

(Note that *drawing* and *refreshing* are two different concepts. Although, in this case, it's somewhat irrelevant, since the reader does *both* anyway. Whether the screen flashes or not is simply another *type* of refresh . strace -fitv -e trace=ioctl -X verbose -p $(pidof nickel) if you want to take a look at what's happening on the refresh front.).

1/ We've tried that before, and the results were... inconclusive (IIRC, the least unreliable way was the Event table, which is only updated in batches, and needs to be actively tracked to pinpoint what actually happened, which makes the whole thing tedious and not-actually terribly reliable ;p).
I don't recall where the latest round of discussions occurred, exactly, but there was a small amount of messages on the subject, with at least @davidfor and myself participating, if you want to take a look at that . (It, err, might even be in this very thread, come to think of it ).

2/ That's essentially what @frostschutz was hinting at by mentioning the nightmode hack (because it interposes the MXCFB refresh ioctl).
While hooking that, and writing to the fb before executing the incoming call as-is might be neat, the extra processing involved might end up significantly delaying the call. Probably better to just pass it through, and simply do another draw+refresh *after* that.

AFAIK (before my time), the plugins system dates back to earlier Qt4 versions of Nickel, so, nope .

[desterly]

Originally Posted by NiLuJe

2/ That's essentially what @frostschutz was hinting at by mentioning the nightmode hack (because it interposes the MXCFB refresh ioctl).
While hooking that, and writing to the fb before executing the call as-is might be neat, the extra processing involved might end up significantly delaying the call. Probably better to just pass it through, and simply do another draw+refresh *after* that.

AFAIK (before my time), the plugins system dates back to earlier Qt4 versions of Nickel, so, nope .

Well... I was thinking (or wishing there was a way) of a way to do it w/out having to utilize a LD_PRELOAD to hook into ioctl

The plugins system is actually still in the recent firmware... I'm looking at it in IDA right now. Be interesting to see if we can still utilize it (even if no one hasn't yet). I'm sure it needs to be updated from the existing examples as they are a few years old.

I might setup the koboreader build box and see if it still works. If it does and can be hooked into readingview, even if it still utilizes FBInk, it might simplify a few other things.

[frostschutz]

Well... I (think I) have an improvement for the current freeze issue, and I'll reimplement the touchscreen/button option that went missing last update, and then... it's gotta be "good enough" at some point. Delays and such are customizable for a reason after all...

I'll upload a new version over the weekend. Hopefully to be the final version, at least for a while.

Tracking pixels is not something I will explore myself, good luck to anyone who makes the attempt... when reading Japanese ebooks, the pageflips actually don't re-draw full screen for me, top and bottom rows of pixels survive.

(edit: actually just the top few rows, after testing it again just now... even so, full page re-draws are not guaranteed so perhaps track the bounding box [four corners] of the clock display itself?)

[NiLuJe]

Huh. Wouldn't have thought there'd be extra shenanigans for Japanese...

For reference, after an eval $(fbink -e) the final *visible* pixel can be read by our friend dd as such:

dd if=/dev/fb0 skip=$(( ((viewWidth - 1) * (BPP>>3)) + ((viewHeight + (viewVertOrigin - viewVertOffset) - 1) * lineLength) )) count=$((BPP>>3)) bs=1

(It's essentially (x * bpp/4) + (y * line_length), with extra craptastic arithmetics because of the crappy viewports on the H2O & Aura, to make sure we don't end up reading a dead, under the bezel pixel, which Nickel won't necessarily touch).

Pipe to hexdump -vC for testing .

EDIT²: Fixed it! With a bit of help from FBInk master, because I wasn't exporting line_length before.

[Bean_There]

Originally Posted by NiLuJe

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

Triffic, thanks for that!

[frostschutz]

Originally Posted by frostschutz

Well... I (think I) have an improvement for the current freeze issue, and I'll reimplement the touchscreen/button option that went missing last update, and then... it's gotta be "good enough" at some point. Delays and such are customizable for a reason after all...

another day, another update. it should be more resilient to freezes and no longer miss inputs then

the touchscreen=1, button=1 that stopped working in the last few experimental updates, now merged into a generic input_devices settings:

#
# which /dev/input/eventX number devices to listen to
#
# input_devices=1    - event1 = touchscreen
# input_devices=0    - event0 = keyboard/buttons/magnet
# input_devices=1 0  - event1 event0 = both of the above
#
input_devices=1 0

so if a future device decides to change those numbers you can still configure it anyway

download here (20190729 version)

If you have any issues with it please don't report them to me because I don't want to update it anymore

j/k, let me know if it works

[jackie_w]

Originally Posted by frostschutz

another day, another update. it should be more resilient to freezes and no longer miss inputs then

the touchscreen=1, button=1 that stopped working in the last few experimental updates, now merged into a generic input_devices settings:

#
# which /dev/input/eventX number devices to listen to
#
# input_devices=1    - event1 = touchscreen
# input_devices=0    - event0 = keyboard/buttons/magnet
# input_devices=1 0  - event1 event0 = both of the above
#
input_devices=1 0

If you have any issues with it please don't report them to me because I don't want to update it anymore

j/k, let me know if it works

Buttons no longer working at all, even after a reboot. Touch seems to be OK.

I must admit I'm totally confused because you say that button=1 is no longer required (and has been removed from miniclock.example.cfg) but there is still a reference to it in miniclock.sh (line 180). Does this mean that the built-in patch to libnickel is no longer required either?

[frostschutz]

Damnation, I forgot about the patch. X_X It worked for me because of course, the patch was already applied.

now, if you look closely there is version B

[jamalau]

Works well with my Forma, thanks!

Gesendet von meinem SM-N960F mit Tapatalk

[poczynek]

EDIT: worked it out!

[albare]

Hello, I am testing this plugin and work perfectly.
Is difficult to add light % level to the format string like the battery %? (I love koreader status bar and I wan emulate it)
Thanks in advance!

Enviado desde mi SM-A705FN mediante Tapatalk

[NiLuJe]

@albare: Not on anything earlier than Mk. 7 devices, which are the first ones to introduce an easy way to actually *read* the frontlight status.

We can work it around in KOReader because we're the ones to *set* the value in the first place, so we keep track of that (and it's a huge pile of kludges).

[albare]

And how knows koreader the light level when I change it with nickel? If I set the level in nickel and I start koreader the light level is the same and the status bar shows it correctly.
Could be nickel write it in some file.


Enviado desde mi SM-A705FN mediante Tapatalk

[JSWolf]

All the KoReader posts belong in the KOReader forum.