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

Originally Posted by Ken Maltby

Another KoReader response to the users issues that are ignored by Kobo, Full Screen:

Think of it this way: koreader is a community response to Kobo's lack of response to our requests. Kobo can serve what they see as their core market, which is probably people who buy ebooks from Kobo and are looking for an experience that is as simple as a print book. koreader developers can serve the interests of our demographic, which is clearly more specific and is more accepting of complexity. As an added bonus, koreader is open source and is mostly developed in an interpreted language. This allows us to contribute to the project as well or, if our modifications aren't accepted, it is much easier to modify the software for personal use and share those modifications with like minded users. This is, in short, what I've been waiting for. It is a win-win situation. I am grateful to the core koreader developers, koreader porter (giorgio130), enthusiastic koreader moders (cgm999 and xor_), and users who have suggested both ideas and code to improve the project.

Please don't frown upon Kobo for their lack of response to specific requests. They are probably doing what they think is best for their product and their business.

Please do offer some sort of appeciation for those who are extending Kobo's hardware to our specific requests, because they have provided us with both a product (koreader) and the tools to improve that product (open source, and in a scripting language which makes it more accessible for semi-technical users to contribute).

[Ken Maltby]

We certainly must credit Kobo with bringing the device to market in the first place, in my case I have credited them three times, and think the credit they have received at the pricing they established ought to satisfy them. The others you mention are more deserving, in my mind. But the main reason I was pointing out Kobo's (probably fiscally prudent [see I didn't say greedy]) lack of response to issues of interest to their customers, was to point out the progress addressing those issues by the KoReader. I doubt that all those who have raised those issues and the likely larger number who also wished for those features/fixes, are aware of the strides made already.

Luck;
Ken

Originally Posted by Ken Maltby

We certainly must credit Kobo with bringing the device to market in the first place, in my case I have credited them three times, and think the credit they have received at the pricing they established ought to satisfy them. The others you mention are more deserving, in my mind. But the main reason I was pointing out Kobo's (probably fiscally prudent [see I didn't say greedy]) lack of response to issues of interest to their customers, was to point out the progress addressing those issues by the KoReader. I doubt that all those who have raised those issues and the likely larger number who also wished for those features/fixes, are aware of the strides made already.

I think that the credit to Kobo should go a little further than the hardware and pricing. Especially since I think that the Touch is much better designed than the Aura. (The Touch strikes me as being much more durable, even though the Aura definitely has better specifications.) I also definitely agree with "fiscally prudent" being used instead of "greedy" because they are a business that has to play within contemporary business practices in order to be competitive (even though I don't agree with current business practices because I value my privacy, particularly with respect to what I read). I also agree with those who created koreader and who adapted it to the Kobo deserving more credit simply because their purposes are more altruistic than those of almost any business.

Yet I also believe that Kobo deserves a bit more credit than they seem to receive at times. As far as I can tell, Kobo is a much more open system than its direct competitors. Modifying a Kobo device does require using a few tricks, but they are remarkably easy tricks to figure out. Once you figure out the basic trick (namely, how to obtain a firmware update) almost anything that a software hacker would want to play with is well documented by third parties. Yes, things could be better. On the otherhand, my recollections of my Kindle were that it's a hands-off device. I used mods to be sure. Yet I could not create my own mods nor modify the mods.

Overall, I wish that Kobo could meet my needs (and your needs) directly. Realistically though, I realize that we are both outliers. Realistically, I realize that my skills aren't quite up to par to do the deep modifications myself, so I depend upon others to do so. When I noticed that koreader was mostly based upon Lua though, I was overjoyed. I don't know the language, but I recognize that it is an interpreted language and it's far easier to tweak software based upon interpreted languages than compiled ones (e.g. there is no development environment to setup).

So kudos to everyone. Slightly more so for the modders because I respect what they're doing, but a great deal of credit should go out to Kobo for making their lives easier.

[cgm999]

I did not notice that in koreader epub my mod is not showing up, will see why is that and hopefully fix .

How about the Kobo devices with lower resolution?800x600 and 1024x7xx , what issues do we have for those ?

giorgio: let me know if you need any help with getting this last mods into koreader trunk

[paola]

Originally Posted by Markismus

@Xor: Thanks. It works like a charm.

@Paola: 1. Yes. 2&3 No for both pdf- and epubfiles.

thank you - and to you all, it is great to see this thread growing and growing. As Ken mentioned, especially on a 5" like the Mini, having a proper landscape orientation working (even for epubs, in case you have pictures) is great.

[giorgio130]

Originally Posted by fred01

Still no luck with cbz on koreader-v2013.03-266-g4f36cd2 under 2.6.1
I get this crash log:

lua config error: ./frontend/document/credocument.lua:75: calling 'zipContentExt' on bad self (string expected, got nil)
stack traceback:
	[C]: in function 'zipContentExt'
	./frontend/document/credocument.lua:75: in function 'init'
	./frontend/document/document.lua:76: in function 'openDocument'
	./reader.lua:125: in function 'showReader'
	./reader.lua:174: in function 'onFileSelect'
	./frontend/ui/widget/filechooser.lua:56: in function 'onMenuSelect'
	./frontend/ui/widget/menu.lua:197: in function 'action'
	./frontend/ui/uimanager.lua:132: in function 'checkTasks'
	./frontend/ui/uimanager.lua:158: in function 'run'
	./reader.lua:248: in main chunk

How would i go about compiling koreader with the new toolchain? I installed the linaro arm hf toolchain but got stuck soon after. Can I get the trunk koreader to compile on the new architecture or does it need some major changes? Any pointer is appreciated.

I've tried to open a cbz file as well, but it does not show up in the file manager for me... Are you opening it directly through the command line? If so, I'd say cbz is not supported...
Regarding compiling with arm-linux-gnueabihf, it is quite simple. Ensure that the linaro toolchain provided by kobo is in your path, then cd to koreader-base; open Makefile.defs and check that CHOST is set to arm-linux-gnueabihf, -mfloat-abi=hard. Then issue the command

make CHOST=arm-linux-gnueabihf kobo

when this successfully ends, cd to the main koreader directory and isse a

make CHOST=arm-linux-gnueabihf customupdate

that should produce a zip similar to the one I uploaded here.

[fred01]

Originally Posted by giorgio130

I've tried to open a cbz file as well, but it does not show up in the file manager for me... Are you opening it directly through the command line? If so, I'd say cbz is not supported...

Sorry, I forgot to mention that while cbz files don't show up in the file manager, plain zip files do, so I assumed it was some sort of minor overlook and went ahead. Does anybody know if cbz (or zip) files are correctly opened on the original koreader on a kindle?
In the mean time i managed to at least compile the emulated version and reproduce the same error, and I'm under the impression that it was caused by spaces in the filename or path. I tried working around the issue by renaming the files and I'm now getting a segmentation fault without any real information about what went wrong.

[giorgio130]

I found the problem with cbz files. They're supported by the pdf viewer but they had to be added to the supported extensions, somehow no one noticed that. I'll commit the fix to the main koreader. Thanks fred01 to point that out!
I'll wait to upload a fixed version since I'm planning to integrate some of your mods, like suspend support.

[cgm999]

Reattached zip that is based on koreader-v2013.03-266-g4f36cd2.zip

Fixed to include the mod for epubs. Also the list of debug commands is now in
defaults.lua as DEBUG_CMDS


[root@KOBO_AURAHD .kobo]# more koreader/defaults.lua
DEBUG_CMDS = {"reboot","w_on","w_off","inv",}

-- number of page turns between full screen refresh
-- default to full refresh on every page turn
DRCOUNTMAX = 6


I belive we need more tweaks for other devices with lower resolution. Since Device:getModel returns the full Kobo model I would guess is not that hard.


NOTE: starting wireless from koreader will have some issue due open files by wpa_suplicant and we need some wrapper that closes all files except 0/1/2 then execute it

edit: zip removed and attached on a later post

[fred01]

Originally Posted by giorgio130

I found the problem with cbz files. They're supported by the pdf viewer but they had to be added to the supported extensions, somehow no one noticed that. I'll commit the fix to the main koreader.

I tried your changes and i can confirm it works like a charm. I also went ahead and added zips as cbz (DocumentRegistry:addProvider("cbz", "application/cbz", PdfDocument)) and that also works perfectly.

[giorgio130]

Originally Posted by fred01

I tried your changes and i can confirm it works like a charm. I also went ahead and added zips as cbz (DocumentRegistry:addProvider("cbz", "application/cbz", PdfDocument)) and that also works perfectly.

do you mean
(DocumentRegistry:addProvider("zip", "application/zip", PdfDocument))
?
That would cause some issue since zip files are already being read by another reader application (probably for zipped htmls?). The line you posted is exactly what I've done.

@cgm999 could you recap what are your mods and what files do they involve? It would be faster for me to have a look. Moreover, what's the use of enabling/disabling wifi under koreader? There's no part of it making use of an internet connection (yet).
edit: nvm, I just noticed you just included modified files.

Not to be too fussy, but you include also binary files in your zip. Where can I find sources for those?

[cgm999]

giorgio130:

The only binary file is frontlight.c which is on one of the older topics, src:

#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>

int main(int argc, char *argv[])
{
if ( argc != 2 ) {
printf("Usage: %s brightness \n", argv[0]);
return 1;
}

int light;

// Open the file for reading and writing
if ((light = open("/dev/ntx_io", O_RDWR)) == -1) {
printf("Error opening ntx_io device");
}

int brightness = atoi ( (argv[1]) );
ioctl(light, 241, brightness);

return 0;
}


Also, the ideea with wireless on/off, is part of debug_cmds, is good to have a way run those right?,then ssh/sftp to upload debug.

as for wpa_supplicant issues I was just saying I need to find/make a wrapper to close all open files except 0/1/2 before running any commands out of koreader or we will see issues like input is frozen on 2nd koreader run

The list of changes that my mod include:
- suspend button works
- light button works
- light level from landscape bottom menu
- debug commands from bottom menu
- dpy set for aurahd (we need to add others like glo?)

Also we need to set changes in toggleswitch.lua based on main dpy or model I think, whoever have those need to test and report back.

[fred01]

Originally Posted by giorgio130

do you mean
(DocumentRegistry:addProvider("zip", "application/zip", PdfDocument))
?
That would cause some issue since zip files are already being read by another reader application (probably for zipped htmls?). The line you posted is exactly what I've done.

Yeah, I got that from your commit on github. It doesn't cause issues as it seems to have the precedence over the portion of code in credocument.lua that checks for zip files.

[giorgio130]

Originally Posted by fred01

Yeah, I got that from your commit on github. It doesn't cause issues as it seems to have the precedence over the portion of code in credocument.lua that checks for zip files.

That's the issue I was referring to zipped html that should be taken care of by crengine would just crash the pdf reader (I guess), just like happened when you changed from cbz to zip. I think a collection of images should have an extension of cbz, I won't add zip as an extension supported by pdf reader.
@cgm999 I don't think I'll merge the debug / custom commands part, it's just useful for developers I'd say. The same for wifi on/off... Feel free to create pull requests for those yourself if you feel like! It's taking a while since I'm cleaning the code up in order to reduce to a minimum the changes.

[cgm999]

Thats fine. I am curios if any1 else uses debug commands ?