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.

e-reader

So ... I ended up cancelling my order with JB HI FI for the e-reader I ordered. For a retailer apparently struggling with on-line competition they really need to get their shit together: after 7 days, an 'in stock' item had still not shipped, let alone arrived. For online shops who have got their shit together, I typically have much larger items (e.g. a rotary clothes line!) arriving in only a few days.

So anyway, I ended up just going to officeworks; another evil corporation, but it's close. Originally when I looked last week they had it at RRP, then I was there Tuesday for something else and I saw it at the same price as JB Hi-fi, and by the time I decided to buy one anyway (I was nearly going to drop the whole idea ...) they'd dropped another 15$ off that price. Apart from having to stand around like an idiot for 10 minutes before anyone would serve me (unfortunately, the aren't just stacked on a shelf like everything else) it was an easy buy ...

Kobo Touch

So the device is a Kobo Touch.

The hardware is quite nice - solid feel. It's a bit smaller than I'd imagined - it's like a small paperback - but the screen is readable enough. A bit heavier than I expected too, but it's ok. I've never seen e-ink screens before, and the screen is better in brighter light but it's still ok in more subdued lighting. Screen updating is pretty slow - but for it's purpose to read text it is ok, it feels a it like very old LCD displays with a low battery. Using the 'sketch' tool or an event reader from a login shell, the touch input isn't perfect but does seem fine enough and quite responsive.

But the software ... is pretty crap. Usually it's ok, but sometimes it's super-slow. Dunno why - the hardware is beefy enough. Text files (book sized) are really slow, as it seems to re-paginate the whole thing every time you open a book, and for such text files it always forgets where you were up to. Changing display preferences on such a text file also takes about 30 seconds per change ... The touch input (apart from the sketch tool) is a bit hit and miss some of the time, and it is often un-clear if the tool is just too busy to process your input, or it just didn't pick it up in the first place. Which leads to double-actions or nothing happening.

I managed to get telnet working and installed strace (from the opensuse arm7l rpm) to see what the GUI was doing. During one of the long pauses where top showed the system wasn't very busy it spent an inordinate amount of time trying to read a config file with the following sequence was being executed thousands of times:

stat64("/mnt/onboard/.kobo/Kobo/Kobo eReader.conf", {st_mode=S_IFREG|0755, st_size=3495, ...}) = 0
stat64("/mnt/onboard/.kobo/Kobo/Kobo eReader.conf", {st_mode=S_IFREG|0755, st_size=3495, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2202, ...}) = 0
stat64("/mnt/onboard/.kobo/Kobo.conf", 0x7eacbfc8) = -1 ENOENT (No such file or directory)
stat64("/mnt/onboard/.kobo/Kobo.conf", 0x88f080) = -1 ENOENT (No such file or directory)
stat64("/mnt/onboard/Kobo/Kobo eReader.conf", 0x7eacbfc8) = -1 ENOENT (No such file or directory)
stat64("/mnt/onboard/Kobo/Kobo eReader.conf", 0x88f228) = -1 ENOENT (No such file or directory)
stat64("/mnt/onboard/Kobo.conf", 0x7eacbfc8) = -1 ENOENT (No such file or directory)
stat64("/mnt/onboard/Kobo.conf", 0x88f228) = -1 ENOENT (No such file or directory)

Which looks like pretty sloppy coding/mis-using a tool-kit.

The reader application turns off the wifi when you restart it, so I gave up for now rather than trying to fight with it to get stuff done. Might read some books first ...

When I get an arm compiler going again (my beagleboard stuff is all backed up ... somewhere), I might have a closer look. Installing new binaries is pretty easy, and there's some info on the forums about the touch screen and frame-buffer.

Another year.

Well i've been pretty lazy since my leave started - well not entirely lazy just not wedded to the computer keyboard as I usually am. Not really missing it either, yet.

I did however install an automatic watering system and with looking after the garden that keeps me busy enough. The main tomato plant is nearly spent (after about 13kg of tomatoes, not bad for a 2 year-old plant), but i've had a pile of purple beans and the fresh sweet-corn is very nice too and all the citrus is booming now the wine barrels aren't drying out every warmish day.

I went to the country for xmas with my sister & niece, my twin brother and mum; but after a week of that and them it was a relief to come home. I was so over drinking by then I went to bed early on NYE and have been dry since - it didn't help that I had hardly any sleep for weeks beforehand and during so my mood was all over the place. I couldn't keep up with her nightly drinking and she's too much of a know-it-all to put up with for too long!

After returning we had a bit of a heat-wave, so I just sat inside with the AC on, sleeping a lot and watching a lot of shit on tv. I'm a bit full of that too so I've started trying to do some recreational reading again - it's been a long long time - a few years - since I read anything. Starting with reading EE Doc Smith's Lensman series: the 40s style romance and kill-everyone action is a bit funny but it's better than repeats of some shitty american sitcom ... On an impulse buy I even ordered an 'ebook reader', although to my chargrin an 'in sock' item still hasn't shipped 4 days later ... reading on the laptop is ok but I'm interested to see how purpose-built device will compare.

Given I was off the booze for a few days I dropped the coffee too (until this morning) to see if that was the cause of my sleep apnoea going off the scale lately: unfortunately it had no noticeable effect. I was still tired and able to nap for hours every afternoon (thankfully the work next-door has ceased for the moment which let me `sleep'). So it's most probably just being too lazy and sedentary, too overweight, and perhaps some hay fever.

Wheee

In the nick of time, i've got a big block of leave coming up starting COB today (actually i've basically knocked off - too many hours this week - but have to hang around for something).

I've been put off travelling for a few years - all those trips to Boston and around the world from Perth were a bit much, so I probably wont be going anywhere. The garden needs plenty of up-keep anyway so I will probably just bum around the house a lot. Who knows, maybe i'll get somewhere with the deck and shed floor ...

Although I should probably take a break from the keyboard I'll no doubt end up doing some hacking - no real plans so I'll see where my interests take me. Apart from the projects I already have on the go, eventually I want to resurrect my own effort at an internet publishing platform too.

Another long outstanding task is to build a woodworking bench from some recovered timber, and perhaps a set of steps from the back porch. Maybe get a welder? Really should do that shed floor first ...

I'm still really dark on Sony for cutting my ps3 in half, so i'm not sure i'll play too many games - I would like to look at uncharted 3 though.

The main dissapointment of the moment is that I ran out of beer last night and haven't brewed anything for months either. This sounds like something that needs to be rectified with prejudice.

DTCWT denoising

So I poked at the wavelet code enough to get it to work, and included it in ImageZ. It still fails with certain sized images, but oh well ...It's based on the dual-tree quaternion wavelet, and does a quaternion-to-complex translation during the thresholding which produces a cleaner de-noised result (i.e. it is still using a dual-tree-complex-wavelet-transform ...). I haven't particularly tried to optimise it much - but it's already about 3-4x faster than the DCT Denoising algorithm I implemented earlier (for which there is little opportunity for further improvement). It also implements the sharpen algorithm I developed, which I wasn't able to get to work with the DCT code.

I've started working on the OpenCL version for socles as well, but it's got a way to go yet.

The de-noising isn't my primary interest in this stuff, it's just a freebie to test some of the algorithms and is interesting nonetheless.

Update: Yes it's been a long time between drinks, but I finally poked at the socles GPU version again nearly 3 months later, see this follow-up post.

rmi

So i'm stuck a bit with a problem at work, we're using some crappy obsolete API that only works in 32-bit mode, but the rest of the application needs to run in 64-bit to fully utilise the hardware. Bit of a shit really - it's unclear if there is a 64-bit API available - I think there is - but I don't have access to the device and he who does is currently travelling ...

As a fall-back in-case there isn't another way I hacked up a quick system based on RMI - and I was surprised how easy it was considering I started from scratch. I think it helped that I already had a relatively simple API that abstracted different devices, so I just wrote a proxy object in a few dozen lines of code. And of course it helped that I've played with CORBA before and know how it all works.

The nice thing about RMI is it lets you send classes across the wire (with local processing behaviour as well), which meant I could implement some backend dependent code like getControls() in the GUI front-end process with only a few minor changes to use a more generic property interface.

No doubt it could be (much) more efficient, but I think it should suffice for this project. It's something i've been meaning to try for a while and if this experience is any guide it wont be the last either.

Yeah, i'm happy (as happy as i get anyway) to be hacking again after being stuck in maths for so long, although we had a phone meeting today and I've some more ideas to try so it's not over yet.

jjmpeg video creation

Been a bit quiet around here lately - actually it hasn't at all. Building going on next door means I haven't had a decent sleep in a couple of weeks and it's really wearing me down. Add to that I was stuck for a few weeks trying to grok some hairy maths for work and I just haven't had the inclination nor energy to pursue much other than eating, drinking, and some TV.

But back OT, I've started looking at moving my client's application to using jjmpeg - as I need 64-bit microsoft to work, and i'm also having some troubles with gc load with lots of transient objects.

Getting video frame reading going was trivial but I had to code up a fair bit of extra stuff to be able to create videos in proper containers which is the other requirement I have. I've checked in a first cut at that - although I need to do more testing particularly wrt GC performance.

I tried to come up with a helper class with a nice API to use it, and the following demonstrates it's use:

        AVFormatContext.registerAll();

        JJMediaWriter writer = new JJMediaWriter(filename);
        JJVideoStream vstream = writer.addVideoStream(width, height, fps, 400000);
        BufferedImage image = vstream.createImage();

        writer.open();

        Graphics2D gg = image.createGraphics();
        gg.setBackground(Color.black);
        gg.setColor(Color.white);
        for (int i = 0; i < fps * 5; i++) {
                gg.clearRect(0, 0, width, height);
                gg.drawString("Moving Text!", i, i);
                vstream.addFrame(image);
        }

        writer.close();

Well I can't imagine it being much simpler than that. This also (for the most part) avoids transient object creation, so should be (relatively) efficient.

Unfortunately things aren't so clean under the bonnet, but I guess what you don't see wont hurt you will it?

The full example is in VideoWriter.java

Bad typesetting, and evince sucks.

I've been reading a lot of papers of late, and any that aren't typeset using TeX are blatantly obvious and hard to read. Even very old papers are much easier to read than some of the modern ones - I wonder how they are being formatted. The microsoft word ones are really obvious - and utterly awful - but there are others which are pretty crap too. The mathematics is the obvious really low-point, but even the typefaces and layouts are pretty rank.

It is however quite a pleasure when I do come across a properly typeset manuscript in the familiar CMR typeface.

I am also utterly fed up with evince. It refuses to remember anything I ask it - from the location I save files to, to the size of the window, and the lack of global close is just annoying. I had a very wide two-page book I just played with at full two-monitor wide size ONE FUCKING TIME a few days ago, and Now every time I open EVERY document, evince opens at the same ginormous size. Fucking ticking me off big-time.

I even tried mupdf - which is just a bit bare-bones for my liking (although it renders much better), and discovered jmupdf along the way who's tiny demo test application is almost as 'featureful' as evince (not that that means much ...), so I might feel another project coming on ... apart from reading them, i'm staring to get a sizeable collection of papers and it's hard to keep track of them based-on-the-title-in-the-filename.