Kobo Hacking

Update:See also the log of posts under the kobo label. I got quite far but still ended up stuck.

Hmm, so curiosity got the better of me and I played a bit more with my recently acquired kobo touch.

I downloaded the correct version of codesourcery gcc, and trivially compiled some binaries for it - being able to simply ftp code via wifi and run it in a telnet session provides for simple and rapid experimentation. I found also that if i just run the web browser and leave it on the google page the wifi stays active for longer; although I could always kill the ebook reader as well.

I ported a simple linux framebuffer example to run on it, and using the definitions and ioctls in mxcfb worked out how to tell the e-ink to refresh. It can be quite slow if you fully wait for the refresh, but that is only required sometimes by the looks of it. It seems to work a bit like an etch-a-sketch, and bits get left behind sometimes, requiring a full 'shake' once in a while to clean up the display (while reading, this makes the e-ink look even more like paper, since you seem to get the previous page 'showing through' as you do with most paperbacks).

I started playing with a simple 'hello world' using freetype to render some text ... but hell, that's just too much hassle. So I'm going to play a bit with Java first; Java on ARM is pretty gutless, so it may not be fast enough, but there's no harm in trying. The machine has 256MB/ram, so at least memory shouldn't be too much of a problem. It's a pity Java2D cannot write to a direct ByteBuffer so I will have to have a separate BufferedImage to render into, and some messy update code; but I think such overheads will be immeasurable compared to the e-ink update.

I tried the Sun JRE (actually it's about the only binary JRE i could find), which seems to work ok (at least with a simple 'hello world'), and now i'm working on a tiny bit of JNI to talk to the framebuffer display. Rather than have to do everything from scratch, I'm looking at porting a very simple toolkit 'thinlet' to work with this output device, and I'll also write some glue to the touchscreen input.

I've been really flat lately and so may not put much time into it, but the more I use the device the more the shitty software it comes with is pissing me off. It seems to be single-threaded and often blocked by inconsequential i/o operations - i.e. when it works the web browser is somewhat faster than the ebook reader is, so it's not so much the hardware or even the basic software, but some silly interactions going on in the background. Turning on aeroplane mode for example seems to eliminate many of the pauses.