Oooh!

I wasn't so interested when I found you'd written all your modifications in flash, to run on top of their software edifice. Now I know you've got some C code that will hopefully be available open-source very soon to do some important things in elegant ways I'm much more interested.

that will hopefully be available open-source very soon

Good point; it's probably about time I moved it out into my public svn repository. I'm not yet sure it merits an actual web page of its own, since it's a pretty niche program, but as of now the code is available from svn://svn.tartarus.org/sgt/tring (or you can browse it on the web here) if you want it.

I don't know how much of my code will be directly useful to you. Probably the thing you'll find most useful is the enormous comment at the top of chumby.c which documents everything I know about the programming interfaces to the Chumby hardware from the POV of a userland application.

(from chumby.c)

    pollfds = malloc(npollfds_both * sizeof(*pollfds));
    pollfds[0].fd = touchscreen_fd;

Shouldn't there be a check for malloc failure in there?

Fixed :-)

(Not very important in practice: that code only runs once at program startup, and unless I'm doing debugging that's always just after a reboot so the Chumby will pretty reliably have plenty of memory to spare at that point. But thanks anyway.)

Or switch to epoll instead?

Gosh, I didn't know about that. My choice of poll was mostly dictated by the ALSA library API, which provides a pre-cooked set of struct pollfds for detecting when more data needs to be sent to the sound device. I suppose I could have read those and translated their contents into my poll-equivalent of choice, but it didn't seem particularly worth doing.

epoll looks like massive overkill for a job this small, anyway!

`` The root "tring" is unknown. ''

tartarus.org's ViewVC has been reorganised in the three years since I posted that. New webified SVN interface is here. (Proper svnserve interface through which you can check out is unchanged.)