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

[sadowski]

The screenshot is blank, obviously dumping a different buffer than koreader is using. I need to get hold of a camera to take an external shot.

It looks to me as if something like the pixel depth (bpp) or so is wrong. Like all pixels are extremely smeared out along the lines.

The log file says "xres=600 yres=800 bpp=4 vdepth=8". The first three are as I would assume (600x800, 16 shades of grey). I do not know what vdepth is and whether this is correct.

Jens

[WS64]

I got the same answer for PB Lux 2 with 5.2: some distored lines, unreadable.

Crash log:

Atached mp shm: id 0 addr 400cb000 size 18284
----------------> USING A2PLUS MODE <-----------------
attach_shm: mtfb key=251330798 size=833044
Atached mtfb shm: id 68008 addr 407bd000 size 833044
-------------------------
The task - koreader.app have
xres=758 yres=1024 bpp=4 vdepth=8
-------------------------
ndepth:4 hqdepth:4 orientation:0
attach_shm: ref key=2130378752 size=776192
Atached ref shm: id 8001 addr 408ad000 size 776192
[INFO] [/srv/einkbuild/test_build/ebrmain_build/inkview/src/partners.c:28: init_partner]Partner from device.cfg is Osiander
[INFO] [/srv/einkbuild/test_build/ebrmain_build/inkview/src/partners.c:35: init_partner]Partner is set to osiander
OpenTheme: /ebrmain/themes/.default.pbt
ts: loading default calibration values
Atached mqueue: id 8001
./luajit: frontend/device/input.lua:488: interrupted!
stack traceback:
frontend/device/input.lua:488: in function 'waitEvent'
frontend/ui/uimanager.lua:477: in function 'run'
./reader.lua:138: in main chunk
[C]: at 0x0000bdf1

[sadowski]

And this is how it looks like:

[chrox]

Originally Posted by sadowski

And this is how it looks like:

Yes, it looks like the pitch size (bytes for a single line) is detected wrong, more precisely pitch size is less than actual one used in the framebuffer device otherwise the application would very likely have already crashed.

So you can just hack this line: https://github.com/koreader/koreader..._linux.lua#L64 in the "koreader/ffi/framebuffer_linux.lua" file at line 64:

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

this way:

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

or:

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

until you make it right.

[wirtold]

OK, i've tested version v2014.11-39 on PocketBook InkPad 840 and it works very well. And there is even a small surprise: traslation in Polish - great! No problems with touch control anymore, everything is fast and smooth - just can't belive that

Some comments:
- I think there should be option to disable/reduce momentum on scroll - sometimes i've encountered an effect like it starts accelerating and scrolling too much (after releasing finger) and it becomes uncontrollable.

- I don't know if any multitouch controls are implemented, but i can't get any to work. When i'm trying the only effect is text marking or screen repaint.

- And i don't know how to use pdf multi-column reading with koreader.

- I have installed Georgia EInk fonts in default font directory. Is it possible for koreder to use fonts installed this way?

For now koreader becomes my no.1 for reading pdfs

[rkomar]

@chrox You should use the older 1.1a SDK release to build for the version 4 and earlier firmware devices. The latest SDK release seems to be just for version 5.

[sadowski]

Originally Posted by chrox

Yes, it looks like the pitch size (bytes for a single line) is detected wrong, more precisely pitch size is less than actual one used in the framebuffer device otherwise the application would very likely have already crashed.

So you can just hack this line: https://github.com/koreader/koreader..._linux.lua#L64 in the "koreader/ffi/framebuffer_linux.lua" file at line 64:

until you make it right.

I agree, it must be the pitch size. I tried a few combinations of TYPE_BB4, ...8, ...16, etc. with different increments of the line length without seeing a way forward. It changes but not in the right way. Line length increments greater than +4 crash the program. Can it be that this display type ist not yet defined? Or somewhere else in the code?

[j0r13n]

PocketBook 626 aka PocketBook Lux 2:

Tested build v2014.11-31 on FW 4.4 -> Doesn't run

Tested build v2014.11-39 on FW 4.4 -> Runs with garbled screen

Tested build v2014.11-38 on FW 5.2 -> Runs with garbled screen

Crash log last test:

Atached mp shm: id 0 addr 4005b000 size 18284
----------------> USING A2PLUS MODE <-----------------
attach_shm: mtfb key=251330696 size=833044
Atached mtfb shm: id 5000a addr 41ed7000 size 833044
-------------------------
The task - koreader.app have
xres=758 yres=1024 bpp=4 vdepth=8
-------------------------
ndepth:4 hqdepth:4 orientation:0
attach_shm: ref key=2130378752 size=776192
Atached ref shm: id 8001 addr 42074000 size 776192
[INFO] [/srv/einkbuild/brand_build/ebrmain_build/inkview/src/partners.c:29: init_partner]Partner from device.cfg is default
[INFO] [/srv/einkbuild/brand_build/ebrmain_build/inkview/src/partners.c:36: init_partner]Partner is set to default
OpenTheme: /ebrmain/themes/.default.pbt
Theme real name: Line
ts: loading default calibration values
Atached mqueue: id 8001
./luajit: ffi/blitbuffer.lua:713: interrupted!
stack traceback:
ffi/blitbuffer.lua:713: in function 'blitFrom'
ffi/blitbuffer.lua:735: in function 'addblitFrom'
frontend/ui/widget/container/alphacontainer.lua:51: in function 'paintTo'
frontend/ui/uimanager.lua:397: in function '_repaint'
frontend/ui/uimanager.lua:459: in function 'run'
./reader.lua:138: in main chunk
[C]: at 0x0000bdf1


Picture:

[hawhill]

Hm, it just might be no 8bit grayscale framebuffer for this device? Strange thing, this.

[chrox]

Originally Posted by sadowski

I agree, it must be the pitch size. I tried a few combinations of TYPE_BB4, ...8, ...16, etc. with different increments of the line length without seeing a way forward. It changes but not in the right way. Line length increments greater than +4 crash the program. Can it be that this display type is not yet defined? Or somewhere else in the code?

Yes, the screen should change when you set different pitch size. I still suspect it's only because of wrong pitch size. And I wonder what it would look like when you set pitch size from finfo.line_length + 1 to finfo.line_length + 4, could you do me a favor to make a screenshot for each of the four cases?

And you can also try to change finfo.line_length with finfo.smem_len at that line. Probably smem_len could be more accurate that line_length in PocketBook.

[chrox]

Originally Posted by rkomar

@chrox You should use the older 1.1a SDK release to build for the version 4 and earlier firmware devices. The latest SDK release seems to be just for version 5.

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.

[chrox]

Originally Posted by wirtold

OK, i've tested version v2014.11-39 on PocketBook InkPad 840 and it works very well. And there is even a small surprise: traslation in Polish - great! No problems with touch control anymore, everything is fast and smooth - just can't belive that

Some comments:
- I think there should be option to disable/reduce momentum on scroll - sometimes i've encountered an effect like it starts accelerating and scrolling too much (after releasing finger) and it becomes uncontrollable.

- I don't know if any multitouch controls are implemented, but i can't get any to work. When i'm trying the only effect is text marking or screen repaint.

- And i don't know how to use pdf multi-column reading with koreader.

- I have installed Georgia EInk fonts in default font directory. Is it possible for koreder to use fonts installed this way?

For now koreader becomes my no.1 for reading pdfs

1. For scrolling in PDF it should not be accelerating at all by design. If it does, it must be a bug. In EPUB documents I don't know.

2. You can use two fingers swipe right together to show the Table of Content. And use two fingers swipe left together to show the Bookmark window. More multi-touch gestures are documented in the project wiki linked in the first post.

3. Multi-column reading in PDF is only enabled when reflowing is ON.

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

[chrox]

Originally Posted by hawhill

Hm, it just might be no 8bit grayscale framebuffer for this device? Strange thing, this.

I still suspect it's only a pitch size problem. I can still see the mini progress bar at the bottom of the screen in the screenshot. Since the pitch size is smaller than actual one there is additional space under the minibar.

[sadowski]

Originally Posted by chrox

Yes, the screen should change when you set different pitch size. I still suspect it's only because of wrong pitch size. And I wonder what it would look like when you set pitch size from finfo.line_length + 1 to finfo.line_length + 4, could you do me a favor to make a screenshot for each of the four cases?

And you can also try to change finfo.line_length with finfo.smem_len at that line. Probably smem_len could be more accurate that line_length in PocketBook.

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.

[wirtold]

Originally Posted by chrox

1. For scrolling in PDF it should not be accelerating at all by design. If it does, it must be a bug. In EPUB documents I don't know.

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.

Originally Posted by chrox

2. You can use two fingers swipe right together to show the Table of Content. And use two fingers swipe left together to show the Bookmark window. More multi-touch gestures are documented in the project wiki linked in the first post.

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

Originally Posted by chrox

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

It is working for me, thanks!