Hello, planet maemo

OK, so now I have relevant posts aggregated onto planet maemo, hi everybody </dr-nick>.

For those who haven't discovered it, I run a personal repository of packages for maemo. If you break your maemo device by using my repository, you get to keep both pieces. I have a few n810 units and of course my primary open source software suite, libferris, is ported to maemo and available in my repository. Libferris is a virtual filesystem which includes rich index and search capabilities. There are many nice choices for index+search for maemo, with Tracker coming out soon in the standard maemo distribution, strigi available for the n810 etc. Of course, I use libferris on maemo for my indexing ;)

My repo also contains a few handy misc packages like unison, sshfs, fuse, and tinc. Anyone notice the hints that I like filesystems? The unison package could be made to have a few less dependencies, but it works well already. I have compiled afuse, obexftp and obexfs for maemo but those are not in my repository yet because I'm having trouble getting the 810 bluetooth to work from the normal obex packages instead of through the osso-gwobex layer. It would be nice to be able to mount a mobile phone's sd card through FUSE on the n810 and share storage a bit more, but I digress.

You'll also notice cwiid and libsixdof added recently to the repository. I have been playing with a wiimote on the desktop and on the n810. The libsixdof on the 810 can read the state of the wiimote OK. The wmgui tool locks the CPU of the n810 at 100% when using the accelerometer mode, so clearly you have to be somewhat smarter about what you update for each event on an embedded device. I have hopes that I can hack maemo mapper to use libsixdof soon and thus be able to control it on an n810 using a wiimote ;) Getting other six degree of freedom controllers to work will be more of a problem on maemo because you need to use a very recent evdev with a patch for some devices.

One of the issues that still plagues libferris on maemo is the lack of prelinking. Starting an application that uses libferris causes the CPU to spend a bunch of time resolving symbols before it can start executing anything. I've enabled hidden symbols, compiled with a later gcc than the scratchbox normally uses and played games to speed things up, but getting close how quick a desktop machine can resolve symbols at application startup has still escaped me. I might end up rsyncing / to nfs:/foo and running prelink on an n810 just to see if/how much that helps things out.