Touch software and hardware

[notzed]

Hi All,

Got a touch last week - for the price the hardware is fine enough, and quite fun to play with.

The software though ... well it's pretty ordinary. Long delays at inopportune times, and limited features in strange places too. e.g. forgetting where you are in books, no bookmarks(!) or search in text files, etc. I'm using the latest firmware.

Mostly out of curiosity to start with I enabled telnet and ftp and started to poke around.

Since the hardware seemed fairly decent, I put a JVM on it (java's just my thing atm) and started hacking up some user interface software to test the input and output devices to see if it was a hardware or software issue. After working out the display driver and input devices, and writing some JNI and a basic toolkit to use them, I played with some simple gadgets: sliders, labels, buttons, and then made a paged text-only viewer prototype.

a) the touch input and buttons are almost always quite responsive: there's no reason the software shouldn't be most of the time. The touchscreen seems to have issues in some places with a non-dragged press-release, but that's fairly minor. i.e. any double-presses or missed touches are the fault of the front-end software. e.g. my paged text viewer can change about 5 pages/second from rapid button touches and because my code is so crap it's doing a lot more rendering that it needs to (obviously the screen can't keep up with this, but it remains interactive).

b) The e-ink display takes an age to update, but detaching rendering from input and processing can hide this from the application almost entirely and although it's ugly it updates in fairly interactive time and `settles down' fast enough.

c) I have occasionally had the input driver crash - requiring a hard reset - so there are still some kernel issues.

d) Opening text files takes forever - because it's paginating the whole document every time. This overhead seems unavoidable as paginating unicode text is simply expensive ... may make sense not to paginate or at least cache the results. Closing one takes ages too, but that points to shitty memory management (i.e. use memory pools).

I had bought the device to get away from the tv and computer screen and read some books again ... but it's way more fun hacking on it at the moment. Particularly since every time it sits there dumbly for what sees like an eternity after i've poked it a few times i'm reminded that I know for certain it could be a much better device.

[robko]

Originally Posted by notzed

The software though ... well it's pretty ordinary. Long delays at inopportune times, and limited features in strange places too. e.g. forgetting where you are in books, no bookmarks(!) or search in text files, etc. I'm using the latest firmware.

You can bookmark a page by tapping the upper right corner of it. It then dogears it and you can find your way back via the "annotations" option in the bottom menu. It should be automatically bookmarking your current page in the book when you leave it, HOWEVER there may be a small bug that means that this doesn't happen if you use the bottom menu "home" option rather than the physical home button (this may be fixed, haven't checked lately).

Out of curiosity: what are you using for the JVM? And how do screen updates with the JVM compare to Kobo's software? (I'm wondering if there's a way to optimize screen refreshes for eink devices.)

[ikarus9999]

Originally Posted by notzed

Hi All,

Since the hardware seemed fairly decent, I put a JVM on it (java's just my thing atm) and started hacking up some user interface software to test the input and output devices to see if it was a hardware or software issue. After working out the display driver and input devices, and writing some JNI and a basic toolkit to use them, I played with some simple gadgets: sliders, labels, buttons, and then made a paged text-only viewer prototype.

Would you mind releasing the source code of your project. I'm also investigating the Touch and playing a little bit with C++ and Qt. I'm still having issues with the screen refresh and the input.

[voom]

What he means is that specifically in TXT-files there is no bookmark-function... But there is always the option to convert TXT to epub with Calibre first...

[ah-]

I'm also interested in that, but like ikarus9999 I'm using C++ and Qt. Nickel already provides an interface for the development of custom plugins, so I think it's a good idea to base on the official software and just extend it where necessary instead of developing everything from scratch. Most things can be modified with some work. Writing a custom pdf reader (maybe based on okular, see http://code.google.com/p/qindle/), a more advanced library view or some kind of wireless sync should be possible.

libnickel exports pretty much everything and in addition we have qt introspection, so it's possible to interact with almost the whole system.

I'm also investigating the Touch and playing a little bit with C++ and Qt. I'm still having issues with the screen refresh and the input.

If you don't get input events, try QWidget::setAttribute(Qt::WA_AcceptTouchEvents);. This did the trick for me. As for the screen refresh, I'm also having problems with that. At the moment I'm trying to extend the "START" menu on the homescreen with custom options (something like rescan the onboard storage for ebooks would be cool, since copying books via scp is trivial but nickel doesn't recognize them immediately). But even though I can get a pointer to the menu and add new entries/change old ones the menu itself as displayed doesn't change.

Edit: I also got qtscript to run (which was trivial), and this might be a great way to do minor customizations.

[notzed]

robko: as voom suggested, I'm talking about the text file reader. I realise this isn't a core part of the product but it just happens to be what i've been using so far. Changing font size is a real pain there too.

Originally Posted by BWinmill

Out of curiosity: what are you using for the JVM? And how do screen updates with the JVM compare to Kobo's software? (I'm wondering if there's a way to optimize screen refreshes for eink devices.)

I'm using oracle's ARMv7 embedded javase 7, the headless one. http://www.oracle.com/technetwork/ja...ase/index.html (you need to register of course & cannot distribute).

The screen updates are similar for the most part, but:
a) If the source data is monochrome (or you ask the device to map it to monochrome) the updates are a fair bit faster, and leave less 'crap' behind. It looks fine enough for widget pages (e.g. try the page-setting slider whilst reading, which does this), and IMHO (with my eyes and a decent font) is fine for reading as well.
b) Again for widget pages, one can get away with quite a few updates without inverting the ink which speeds it up a bit too (and makes it nicer to look at).
c) remove all shading and styling from buttons: otherwise updates are very slow and ugly. inverting buttons to high-light is the fastest.

The main issue with the kobo software is the pauses and delays outside of the e-ink updates which interfere with the interactivity. For one it seems to love searching for and reading 'Kobo.conf' hundreds of times a second every now and then. Other delays seem toolkit related: e.g. try to set the date or time. Turning pages is about as fast as the e-ink will go though.

ikarus99: The code is a bit of a hack, but since I have a bunch of google code stuff already I will dump it there soon, check my blog for that. My blog about it is at http://a-hackers-craic.blogspot.com/search/label/kobo

The screen refresh is mostly pretty simple: update rectangle. But finding where that rectangle is can be a pain if you're retro-fitting an existing toolkit. I've played with the various ioctl options but most don't seem to make a noticeable difference. Doing an 'invert' will clean up the artefacts (as is obvious from using the reader). Now, if only I can work out how to resume from a suspend ...

I detest C++ so I wont be going there even if kobo provided a full sdk for it. I'm more interested in the journey than the destination so i've no real plans other than poking for fun.

[voom]

Whatever individual goals are, this thread leaves me hopefull that custom FWs are possible that will provide us with some of the stuff we might not geht from Kobo and maybe get rid of some stuff we don't like to be nagged with like "feature-disguised inline-advertising"...