Plato: A document reader for PDF, ePUB, DjVu, etc.

[Mavireck]

Originally Posted by baskerville

I'm working on it.

That is awesome! Hope you won't have too much trouble

EDIT : Just discovered your Hook system. I love the way it is integrated. I will definitely use the demo article fetcher you shared, and I also use it to start my own script (my dashboard). Thank your for that feature!

[rien333]

I'm looking to contribute some code to this project, i.e. do something from the TODO list. Preferably, I would like to write a little terminal application, maybe not good enough to include, but enough as a basis to build on or at least something for my own purposes.

I'm kinda new to kobo development though. @baskerville What does your development process look like? The simplest I could come up with is make changes to the code (including something that logs error/development messages), compile a binary, copy that binary over, (re)start plato, play around with new feature, check the logs, and repeat.

[baskerville]

Originally Posted by rien333

Preferably, I would like to write a little terminal application

Well, the Calculator is already a terminal that runs bin/ivy/ivy!

The problem you'll face is that the current handling of standard output and error is line based. It works because ivy is told not to display a prompt and ends every output with a new line character.

If you were to write a general terminal application, it'll have to be character based. And unfortunately, when I tried this approach, I wasn't able to prevent the standard output and error to intertwine, producing an unreadable mess.

Originally Posted by rien333

@baskerville What does your development process look like?

I'm using the emulator: cargo run --bin plato-emulator --features emulator.

For this to work, you'll have to install the required dependencies.

A few notes regarding the above instructions:

• The emulator requires an additional dependency: SDL2.
• I'm now targeting MuPDF 1.16.0.

[rien333]

Thanks for your guidance!

Originally Posted by baskerville

Well, the Calculator is already a terminal that runs bin/ivy/ivy!

Yeah haha, when I realized that I hoped it would be trivial to make a terminal app, but oh well. Nevertheless, I will see if I can cook up something, possibly using a character based approach.

Originally Posted by baskerville

If you were to write a general terminal application, it'll have to be character based. And unfortunately, when I tried this approach, I wasn't able to prevent the standard output and error to intertwine, producing an unreadable mess.

In case you haven't seen it: there is already a somewhat decently working (although not yet well coded) terminal emulator based on fbink. I'm currently using it with plato and it works fairly decently. It emulates a framebuffer terminal using the small terminal app fbpad, with ncurses support! I can quickly get it to show up by pressing a key/doing some sort of action, and then I can pause the terminal's render process and refresh plato by long-processing to quickly get back to a document.

[baskerville]

In order to catch performance bugs, I'd like to simulate MXCFB_WAIT_FOR_UPDATE_COMPLETE within the emulator. I'm assuming that the waiting time depends on the waveform mode and the area of the update region?

[NiLuJe]

Yup, depending on how stressed the EPDC/PXP is, but since none of us are really doing anything heavy on that front, except possibly for the virtual keyboard, where a wait_for mechanism doesn't really have a place anyway .

(The gist of the delay depends on the wfm mode, rather than the region size. And, of course, of the update mode for wfm modes that do flash).

Note that the ioctl itself generally returns "late", (i.e., the screen has already visually finished flashing for quite a few dozen ms at least).

IIRC, it's using the generic wait_for kernel macros, so the logic flow is mostly readable by mere mortals in the epdc sources.

----

FBInk prints the actual delay in an accurate-ish manner (because jiffies :/).

(/!\: Mk. 7 kernels use a smaller timeout, c.f., the _mk7 codepath).

----

It's generally only useful around FULL updates (either before, or after, or both), or before an A2 one you *really* don't want to let get merged w/ anything else.

IIRC, on Kobo, the stock reader does it *after* FULL updates, and possibly ony the full-screen ones at that.

----

Fun fact: Kindle kernels have a WAIT_FOR_SUBMISSION variant, which lets 'em do very fancy stuff with the virtual keyboard and A2 updates in general with much more accuracy.

----

FWIW, KOReader's emulator basically just sticks a configurable sleep in the codepath that emulates flashing updates.

[favero_]

Hey @baskerville, congratulations on this amazing ereader app, and specially for the quick support!

I only have two questions:

1. I have a kobo forma. How can I invert the page turn buttons? I saw someone asked it already but no one answered it.

2. I installed plato on my device using KFMon. How can I update Plato as new releases come up?

Thanks!

[NiLuJe]

@favero_:

1. I feel like that was implemented shortly after the original request, but I may be misremembring that .

2. Assuming you meant with these packages, you can basically assume update == install. It won't affect your settings/content .

[baskerville]

Originally Posted by NiLuJe

(The gist of the delay depends on the wfm mode, rather than the region size. And, of course, of the update mode for wfm modes that do flash).

So the area has a minor impact?

I'll have to test and see if I can come up with a formula.

Originally Posted by NiLuJe

It's generally only useful around FULL updates (either before, or after, or both),

This is used in Plato to avoid writing to a region of the framebuffer that's being displayed.

Originally Posted by NiLuJe

or before an A2 one you *really* don't want to let get merged w/ anything else.

Can the hardware be damaged by this?

[baskerville]

Originally Posted by favero_

1. I have a kobo forma. How can I invert the page turn buttons?

This setting isn't available yet.

[NiLuJe]

@baskerville:

The EPDC itself already does collision checks & merging (c.f., UPDATE_SCHEME_QUEUE_AND_MERGE). They (generally) behave well, things only get hairy in some corner-cases, generally around A2 updates, because they're much faster, and they also do some weird magic where they basically no-op a large part of themselves if the fb content in that region hasn't changed.

Or sometimes if an *unrelated*, non-overlapping region of the fb was updated between a quick succession of refresh calls (c.f., "papercut" glitches, which appear to be easier to trigger on Kobo kernels than on Kindle).

TL;DR: While doing the overlap check on your end certainly makes sense, in terms of choosing which region to feed to encompass everything in a single refresh ioctl, I'd be inclined to say that combining that with a wait_for is overly conservative, and potentially not actually helpful in avoiding EPDC corner-cases .

YMMV, of course .

----

And, no, your hardware is safe, no matter what you feed the ioctls . At the very worst you'll deadlock the kernel (f.g., passing 0 as a marker, or a 0x0 region or 1x1 region). And even then, that only affects some kernels (I'm fairly sure marker 0 is invalid and crashes everything, but the region stuff may be sanely handled by some).

[NiLuJe]

I'd view the wait_for mechanisms as a kind of vsync fence: when you want to make sure everything that you sent *before* a point has been shown on screen (i.e., wait_for_submission(prev_marker) on Kindle, or wait_for_complete(prev_marker) on Kobo) right before sending something new.

And the same when you want to make sure what you've just sent has been shown on screen on its own (wait_for_complete(marker) right after a refresh).

----

In a single-threaded app, you also have to think of when you can actually afford to block (i.e., waiting_for(prev) right before something new is probably more appealing, because there's a chance by the time you need to wait for it, it'll already have gone through, so it won't wait long/at all).

[baskerville]

Originally Posted by NiLuJe

While doing the overlap check on your end certainly makes sense, in terms of choosing which region to feed to encompass everything in a single refresh ioctl, I'd be inclined to say that combining that with a wait_for is overly conservative, and potentially not actually helpful in avoiding EPDC corner-cases .

You might have misinterpreted the code excerpt. Waiting is necessary here, because if we write to a region of the framebuffer that's being transmitted to the display, it will lead to a display state that's inconsistent with the framebuffer state.

[NiLuJe]

@baskerville: Ah, I was under the mistaken impression the rendering was decoupled from the refreshing, but I was afraid that wasn't actually the case, as that logic would then indeed make much more sense .

(Incidentally, decoupling rendering from refreshing would probably solve this particular conundrum ).

[baskerville]

I've released 0.7.6.

The firstPage key is no longer part of the database format. If you don't want to loose the firstPage keys you might have defined, you can use the attached converter:

./fix_metadata.py < .metadata.json > metadata.json
mv metadata.json .metadata.json