PocketBook-KOReader: a document reader for PDF, DJVU, EPUB, FB2, CBZ, ... (AGPLv3)

[rkomar]

Originally Posted by chrox

It's probably true when you use the PocketBook SDK heavily because of the incompatibility. But in Koreader we only use a minimum subset of the API to make Koreader to run. And the used APIs are only relevant to input events handling since we cannot read the /dev/input/event* directly. So we spawn a separate process running InkViewMain main loop and redirect all input events to koreader side via the event handler. Screen output is written to the /dev/fb directly in Koreader so we don't use any GUI facility provided by PocketBook thus the latest SDK should be enough to build Koreader for all recent PockeBook devices.

The SDKs also provide the system headers and libraries, so you wouldn't have to worry about which glibc/libjpeg/libtiff,... versions are being used. I cross compile using the old SDK, and I've never had a problem with the resulting objects on version 2 to version 4 firmwares. The system libraries stayed the same in the gnueabi firmwares until version 5, where some were updated. Using the old SDK, you can probably also build a version for the old 3XX devices (pre-gnueabi), as well. Those devices were built well, and many are still being used.

[WS64]

Originally Posted by chrox

4. Probably not, you need to copy fonts into applications/koreader/fonts directory in order to use them in Koreader.

Is there a reason why we really need the fonts in the Koreeader folder, or could we (maybe only for PB) allow a second path to the fonts?

[chrox]

Originally Posted by sadowski

Here come shots of the result with line_length+0..4 plus how the page looks like in FBReader. The picture of the clock on top is least distorted with +4 but still way to goand with +5 it crashes.

Likewise, using smem_len gives a segfault.

It really goes in the right way from +1 to +4. But the detected screen height might be larger than actual one so that the application crashes before pitch size goes right.

Could you also screen shot with these changes?

elseif vinfo.bits_per_pixel == 8 then
            self.bb = BB.new(vinfo.xres, vinfo.yres/2, BB.TYPE_BB8, self.data, finfo.line_length + 5)
else

to

elseif vinfo.bits_per_pixel == 8 then
            self.bb = BB.new(vinfo.xres, vinfo.yres/2, BB.TYPE_BB8, self.data, finfo.line_length + 8)
else

which only use the first half height of the screen for test and increases pitch size from finfo.line_length + 5 to finfo.line_length + 8. I expect a sane half screen in one of the four trials.

And could you also print some basic info of the framebuffer at line 40 like this:

print("pitch size", finfo.line_length)
print("framebuffer size", finfo.smem_len)
print("framebuffer width", vinfo.xres)
print("framebuffer height", vinfo.yres)

[chrox]

Originally Posted by wirtold

Ok, i've checked this on PDFs. It rather looks like touches are buffered or queued: when i touch screen and move finger, for example, up-down-up, faster than screen is refreshing, and then raise my finger, koreader continues to repeat my moves: document is scrolled up-down-up.



Ok, i just can't find a way to zoom any part of document



It is working for me, thanks!

1. This is confirmed a bug and will be fixed in https://github.com/koreader/koreader/pull/1400.

2. Currently there is no pinch to zoom gesture in Koreader. You need to use reflow mode / zoom to fit content width in PDF or change font size via the menu in EPUB.

[chrox]

Originally Posted by rkomar

The SDKs also provide the system headers and libraries, so you wouldn't have to worry about which glibc/libjpeg/libtiff,... versions are being used. I cross compile using the old SDK, and I've never had a problem with the resulting objects on version 2 to version 4 firmwares. The system libraries stayed the same in the gnueabi firmwares until version 5, where some were updated. Using the old SDK, you can probably also build a version for the old 3XX devices (pre-gnueabi), as well. Those devices were built well, and many are still being used.

GLIBC problem is handled properly now in Koreader with the latest SDK from PocketBook. We managed to compile all Koreader libraries targeting GLIBC_2.4. And almost all dependencies like libpng, libjpeg, libtiff, libgif, libfreetype are self-contained in Koreader distribution so Koreader won't be affected by the library versions provided by the system. If PocketBook provides a sane framebuffer configuration Koreader can also run on rather old device/firmware while building with latest SDK.

[chrox]

Originally Posted by WS64

Is there a reason why we really need the fonts in the Koreeader folder, or could we (maybe only for PB) allow a second path to the fonts?

Currently fontdir can only be set with a single directory, but we can extend it to be a directory list so that users can add custom font directories in their system. Hack probably will be here: https://github.com/koreader/koreader...i/font.lua#L44

[rkomar]

Originally Posted by chrox

GLIBC problem is handled properly now in Koreader with the latest SDK from PocketBook. We managed to compile all Koreader libraries targeting GLIBC_2.4. And almost all dependencies like libpng, libjpeg, libtiff, libgif, libfreetype are self-contained in Koreader distribution so Koreader won't be affected by the library versions provided by the system. If PocketBook provides a sane framebuffer configuration Koreader can also run on rather old device/firmware while building with latest SDK.

The older SDK targets two architectures: arm-linux and arm-none-linux-gnueabi. arm-linux is for the old 3XX devices, and is binary incompatible with the newer EABI ones. You cannot run code compiled for one system on the other (with the exception of the 360+, which had compatibility libraries for the old arm-linux binaries).

Anyway, it sounds like you don't want to be bothered compiling for pre-version 5 devices, so I won't say any more about it.

[chrox]

Originally Posted by rkomar

The older SDK targets two architectures: arm-linux and arm-none-linux-gnueabi. arm-linux is for the old 3XX devices, and is binary incompatible with the newer EABI ones. You cannot run code compiled for one system on the other (with the exception of the 360+, which had compatibility libraries for the old arm-linux binaries).

Anyway, it sounds like you don't want to be bothered compiling for pre-version 5 devices, so I won't say any more about it.

Thanks for the info. I'm a rather new PocetBook user, got my first Pocketbook device early this month. So I may have no idea what is the proven right method to build third-party software for Pocketbook. Since Koreader is designed for portable and distributable development, that's to say, anyone could setup a Koreader develop environment with only several commands. Take Pocketbook as an example, in root source tree of Koreader we can setup a toolchain with this: make pocketbook-toolchain . And it will clone the latest Pocketbook SDK from Github to Koreader's building directory. And that's all the Pocketbook-specific dependency to build Pocketbook port of Koreader. And it's confirmed that in this way the same Koreader binary can run on Pocketbook 840 with both firmware version 4.4 and 5.4. And Koreader will try to officially support Pocketbook firmware version 4.x and 5.x and possibly any later firmware within one package.

[chrox]

Originally Posted by WS64

Is there a reason why we really need the fonts in the Koreeader folder, or could we (maybe only for PB) allow a second path to the fonts?

Fixed this problem in https://github.com/koreader/koreader/pull/1400.

[WS64]

Any idea if we will see a working version for the Lux 2 at all?

[LucyOne]

Originally Posted by WS64

Any idea if we will see a working version for the Lux 2 at all?

I'd also be really interested in such a version.

[sadowski]

Here comes a shot with yres/2 and line_lenght+8. The screen is smaller and rotated but otherwise undistorted.

As for the basic framebuffer information: Where does the output from the print() statements end up? It is not in crash.log.

[WS64]

Great!

For Lux 2

self.bb = BB.new(vinfo.xres, vinfo.yres/2, BB.TYPE_BB8, self.data, finfo.line_length + 10)

works. (/2 and + 10)
Upper half screen is used, no distortions, not rotated:
[Image violates guidelines for size - MODERATOR]

But I can't work with it, I guess the touch still uses the full screen or something like that.
I also can't take screen shots, well, I can, but they are empty...

[wirtold]

I think i've found a bug. Koreader does not save last reading position when reader is turned off during reading. Generally it is not a problem: if you want to turn reader off, you can just quit koreader and then position is stored. But, if i put reader into sleep, and then, after some time, it turns off, position will not be stored.

[rkomar]

I tried v2014.11-39-g917f45a on my Touch Lux (623), and it seems to be working. The display is fine, although it is a bit faint and hard to read in places. It seems that little horizontal white lines appear inside black areas. Perhaps those pixels are getting missed when flood-filling an area?