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

[chrox]

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

It will show up on the terminal screen when you run koreader in SSH session.

In order to write the print output to log file you need to change line 30 in the "applications/koreader.app"

./reader.lua "$args" 2> crash.log

to

./reader.lua "$args" 1> koreader.log 2> crash.log

This will redirect standard output like the "print" to local file koreader.log. After you exit koreader you can find the framebuffer info in the "applications/koreader/koreader.log" file.

[chrox]

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

The result is interesting and proves my hypothesis. Then you can try decrease yres one by one with line_length + 8 until koreader not crashes this way:

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

to

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

.

[chrox]

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

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...

You can also try with the approach described in https://www.mobileread.com/forums/sho...6&postcount=47 but with finfo.line_length + 10 and see the result.

[chrox]

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

By design, koreader should flush reader settings and reading progress into storage file when device goes to asleep. I will try to reproduce this bug on my PB840.

[chrox]

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

It's great to hear that some device other than PB840 could also run koreader. It will be great if you could also post a screenshot of koreader on Touch Lux so that we may figure out what's wrong. I guess the framebuffer on PB623 may be not a continuous block of memory.

Probably I need to ping @hawhill on this topic.

[WS64]

vinfo.yres - 1 does already crash, -10 also (have not tested other steps.)
vinfo.yres/2 uses only the upper half, /4 only the upper 4th.
vinfo.yres/1.01 looks perfect, although I am not sure if really all pixels are used.
vinfo.yres/1.001 crashes again.
On vinfo.yres/1.01 I had a problem at first, the msg "opening book 'filename.epub'." appeared, but nothing else happened. After I pressed a button it the msg disappeared and the book opened, I have to watch this to see if it happens agains.
Right now it works on the Lux 2, does not look thin or anything, on a first sight it looks perfect!
But I think "vinfo.yres/1.01" can't be the final solution, but at least it shows that it is working on Lux 2!

[wirtold]

Originally Posted by WS64

On vinfo.yres/1.01 I had a problem at first, the msg "opening book 'filename.epub'." appeared, but nothing else happened. After I pressed a button it the msg disappeared and the book opened, I have to watch this to see if it happens agains.

I can confirm that - even on InkPad koreader is very often stuck at this message and i have to tap screen to go further. At least on PDFs.

[WS64]

More info:
Sending the device to sleep seems to clear the screen which is not necessary since the PB firmware takes care of these things, but it wakes up fine and on the right position. (UPDATE: Like the second point below this depends on how you open the book. With Koreader as application it behaves as it should => screensaver shows the book cover from Koreader), with "open with" the screen gets blanked and then the zzzz appears (no zzzz on application sleep).

There is a difference between opening a book through the PB library ("open with", not sure this exists on PB840 with firmware 5.4, it does NOT exist on PB Lux 2 with firmware 5.2, but it exists on 4.4) and opening Koreader itself and then opening a book.
Through PB the position of the book is not remembered, books start from the beginning.
Through Koreader itself (Filemanager) I need to press a button after "opening book" message (else the msg does not go away), but then the position is fine. Through PB I don't need to press the button, the book opens fine by itself.

[rkomar]

Originally Posted by chrox

It's great to hear that some device other than PB840 could also run koreader. It will be great if you could also post a screenshot of koreader on Touch Lux so that we may figure out what's wrong. I guess the framebuffer on PB623 may be not a continuous block of memory.

Probably I need to ping @hawhill on this topic.

No, the white lines are quite short, only about a centimeter long. It is hard to capture in a photo, because it's most obvious when a black bar comes up, but that only lasts for about 1 second. So, I tried taking a movie with my camera, and cropping out part of a frame that showed the problem. It's blurry, but hopefully you can see what's going on in the black region. I'm wondering if the same thing isn't happening in the text, as well, making it faint in places. You can see where it says "Page 1 of 1" that the text is missing some "ink".

By the way, I also have to press a button the first time something is opened before it appears on the screen.

[sadowski]

yres-8 and line_length+8 generate a perfect, full-screen, non-rotated page image in the PB mini.

Now with this solved I realize, that with a non-touch reader, there are no buttons other than page forward/backward available which limits the usability of koreader to paging through a book. No menus, not even closing the book is possible ... Are there more key codes hidden in the code or is it simply a touch-only implementation?

[WS64]

@sadowski, I am very sure this can be configured within Koreader.
I can't tell for sure since I only used koreader so far on Kobo devices without any buttons, so I never even cared for those.
I wonder where to configure this though too, since the up and down keys page into the wrong direction in my beloved upside down landscape view. i know I could reassign the buttons within PB itself, but then they would work the wrong way in the other readers too. So I hope I can swap them somewhere within Koreader...
To close Koreader, on the Lux you can at least use a long tap on both "up"+"down" to close the actual application (in this case Koreader)...

[mikmak]

Does someone know when/if Pocketbook will release an SDK for the Pocketbook Sense (630)?
I've built koreader with their current SDK (481), but the reader crashes with a segmentation fault, so I assume the SDK needs to be updated for that particular reader.

[rkomar]

Originally Posted by mikmak

Does someone know when/if Pocketbook will release an SDK for the Pocketbook Sense (630)?
I've built koreader with their current SDK (481), but the reader crashes with a segmentation fault, so I assume the SDK needs to be updated for that particular reader.

Maybe it's not a problem with the SDK. @chrox mentioned that they use very little functionality from libinkview. Anyway, the SDK is not something PocketBook have spent much effort on recently, so I wouldn't hold my breath waiting for an update. I'm just grateful they released what they did.

[WS64]

Did someone else notice that Koreader is really really slow on PB? Things that needs CPU like opening a book for the very first time or searching for books takes WAY longer than I am used to it on Kobo devices. I am talking about things that take 30 seconds on Kobo and something like 20 minutes(!) on PB.
I know the hardware is slower, and especially just 256MB computer memory (not storage!), not sure how much the Kobo devices have here.
It also might be that the multitasking of PB slows things down, I really hope there is a way to speed things up a little!

[mikmak]

Originally Posted by rkomar

Maybe it's not a problem with the SDK. @chrox mentioned that they use very little functionality from libinkview. Anyway, the SDK is not something PocketBook have spent much effort on recently, so I wouldn't hold my breath waiting for an update. I'm just grateful they released what they did.

Hm, ok. Is there any way I can further debug this on the PB 630? In the crash log only "segmentation fault" is reported, so not really helpful.