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.

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.

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.

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.

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.

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.

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?