Koreader running on Kobos (all of them, hopefully!)

Originally Posted by Ken Maltby

To get out of that nonfunctional display, I have to plug in the USB cable connected to my PC and poweroff. Just using the poweroff doesn't work.

Powering off does work, at least on my unit.

If you want to verify that powering down without the USB rigmarole works on your unit, I suggest turning the light on before starting koreader. Let it do the whole screen corruption bit, then try shutting down by holding the power switch for several seconds. When it's off, the light will turn off. (I suggest turning the light on simply because it gives some feedback when the unit turns off.)

As for the [X] in the corner, I think the button is too small and too close to the edge to register the tap.

[giorgio130]

On the glo the x is clickable, you just have to stay as close as possible to the screen border. However it is possible that on the aura the x becomes too small given the higher res. Regarding the screen corruption I wouldn't know how to debug it since I'm not affected. Could someone give feedback for a Glo?

[giorgio130]

I'd like a confirm of what I could infer from the pictures above: it seems like the lower part of the screen does not update anymore after the first time. Is this right? Could be that the screen gets rotated somehow.

[ewphoenix123]

Yep the lower part is not affected.

My theory so far was that some part of the code writes the screen with a fixed 1024 height, and an automatic 100% width, which causes a broken ratio on the Aura, causing the fragments.

Probably the menu code, or whatever else shows up on the screen after you touch a folder to open it.

I don't have a glo here atm so I can't look what it should look like. .(

[giorgio130]

my guess instead is that the upper corrupted part extends until "y = x_res", if you get what I mean... so in the mini the upper 600 pixels get corrupted, and in the Aura whatever is the x resolution. I don't get why this is not happening on glo though. I have something in mind that could solve this, I'll upload a new build later...

[cgm999]

on Aura it works to run directly with pdf file(either from ssh or from launcher):

[root@(none) ~]# /mnt/onboard/.kobo/koreader/koreader_kobo.sh /mnt/onboard/test1.pdf


(maybe it wants to switch landscape - then back)

edit:
something else is going on, now that I've run it with arg /mnt/onboard I can select file and it just works! Need to do more testing

[giorgio130]

That's great to know, thanks!

[WS64]

I tried cdm999's test too and started it from the Kobo Launcher with a book instead the path to the home directory, but actually I tried it with an epub (I have no PDFs on my Mini).
It opened the book (I could see the cover), but the next touch on the screen damaged the screen again. No change after a reboot at the File Manager, the first touch always distortes the screen.

[giorgio130]

I think @cgm999 meant that the second time you start it from ssh the screen is updated correctly. That is quite strange, but you could probably obtain the same behaviour by changing koreader_kobo.sh with this:

#!/bin/sh
export LC_ALL="en_US.UTF-8"

# we're always starting from our working directory
cd /mnt/onboard/.kobo/koreader/

# export trained OCR data directory
export TESSDATA_PREFIX="data"

# export dict directory
export STARDICT_DATA_DIR="data/dict"

# stop nickel
killall nickel

# finally call reader
./reader.lua "$1" 2> crash.log &
sleep 1
killall reader.lua
./reader.lua "$1" 2> crash.log

# continue with nickel

reboot

basically the change is, we're starting koreader, wait 1 sec and then closing it, and reopen another instance (that would hopefully work).
Please test this and let me know!

[cgm999]

It seems that KoboLauncher somehow affects koreader on Aura. Here is a test that can be tried:

rename /mnt/onboard/.kobo/KoboLauncher/KoboLauncher.sh to KoboLauncher.sh-old then put in /mnt/onboard/.kobo/KoboLauncher/KoboLauncher.sh :

#!/bin/sh
/mnt/onboard/.kobo/koreader/koreader_kobo.sh /mnt/onboard


this will make that when you click on the Launcher png it will start directly koreader(to poweroff after this long trag the power buton then trag it back).

[WS64]

cgm999, confirmed, this way it works without prolems!

[giorgio130]

Very nice job I am still starting koreader through telnet to test under 2.6.1 so I couldn't notice the thing. I'll try to investigate why this is happening.

[cgm999]

Is it possible that x/y are swapped?

from normal/KoboLauncher:

/sys/devices/platform/mxc_epdc_fb/graphics/fb0/
bits_per_pixel:16
dev:29:0
modes:U:1440x1080p-0
modes:U:1440x1080p-0
name:mxc_epdc_fb
pan:0,0
rotate:2
state:0
stride:2880
uevent:MAJOR=29
uevent:MINOR=0
ueventEVNAME=fb0
virtual_size:1440,2304


from koreader:
/sys/devices/platform/mxc_epdc_fb/graphics/fb0
[root@(none) fb0]# grep . *
bits_per_pixel:8
dev:29:0
modes:U:1080x1440p-0
modes:U:1440x1080p-0
modes:U:1440x1080p-0
name:mxc_epdc_fb
pan:0,0
rotate:3
state:0
stride:1088
uevent:MAJOR=29
uevent:MINOR=0
ueventEVNAME=fb0
virtual_size:1088,3072


To me in koreader text is not as sharp as in Kobo native reader(again on Aura) . Any ideea why ?

[Ken Maltby]

Originally Posted by cgm999

It seems that KoboLauncher somehow affects koreader on Aura. Here is a test that can be tried:

rename /mnt/onboard/.kobo/KoboLauncher/KoboLauncher.sh to KoboLauncher.sh-old then put in /mnt/onboard/.kobo/KoboLauncher/KoboLauncher.sh :

#!/bin/sh
/mnt/onboard/.kobo/koreader/koreader_kobo.sh /mnt/onboard


this will make that when you click on the Launcher png it will start directly koreader(to poweroff after this long trag the power buton then trag it back).

I must have something wrong, it just acts like its only a .png image.

Luck;
Ken

Originally Posted by Ken Maltby

I must have something wrong, it just acts like its only a .png image.

I ran into the same problem, and ended up removing the various bits of KoboLauncher then reinstalling everything. The problem is that I went through the process the first time without really following the instructions, while I followed the instructions to the letter the second time around. (I think that it's exploiting some sort of quirk in the system, so achieving the same end result on the filesystem isn't the same thing as achieving the same result functionally.)

Maybe you're running into the same issue?