Sunday, January 18, 2009
Like a walk in the park..
A walk through the botanical gardens the other day with a digital camera and I had a nice little harvest of background images. Unfortunately the initial scale and crop of the scaled creature to 800x480 means his head is hidden somewhat under the status icons. But many of the other more generic ones work well for backgrounds. Plus I get the added bonus of having a collection of prescaled 800x480 images for demoing Canola hacks.
Wednesday, January 14, 2009
Didn't your n810 come with an accelerometer?
Shown below is a video of the forthcoming 0.1.0 release of libsixdof with a wiimote. I have hacked up maemo-mapper to have initial support for libsixdof, I'll have to clean up the patch before letting other human eyes see it's nastyness :| I decided to use the C++ sixdof API which means there is a single C++ source file in my build of maemo mapper, it was just faster to get it coded that way. Perhaps I'll convert to the libsixdofc ANSI C API before sending the patch.
Didn't your n810 come with an accelerometer? from Ben Martin on Vimeo.
Although libsixdof supports other 6-degrees of freedom controllers too, getting those controllers to work on maemo is a little more of a challenge. For example, I would love to use the portable spacenavigator usb device with maemo. Even though most folks have the USB cabling to hook up the unit, and it gets detected by the n810 when you have USB in the right mode, getting XInput events from evdev on maemo might be another battle. It is not like that part is trivial on a desktop distro either right now unfortunately. I might end up hacking support for direct /dev/input/foo kernel devices into libsixdof to get around that issue and have "real" 6dof devices working under maemo.
Didn't your n810 come with an accelerometer? from Ben Martin on Vimeo.
Although libsixdof supports other 6-degrees of freedom controllers too, getting those controllers to work on maemo is a little more of a challenge. For example, I would love to use the portable spacenavigator usb device with maemo. Even though most folks have the USB cabling to hook up the unit, and it gets detected by the n810 when you have USB in the right mode, getting XInput events from evdev on maemo might be another battle. It is not like that part is trivial on a desktop distro either right now unfortunately. I might end up hacking support for direct /dev/input/foo kernel devices into libsixdof to get around that issue and have "real" 6dof devices working under maemo.
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.
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.
Tuesday, January 13, 2009
Combine: wiimote, Google Earth, libsixdof and Linux
Oh, and a nice seat, and you get another HID to use for moving around. This is using the upcoming 0.1.0 release of libsixdof which has wiimote support. Note that you can also use the spacenavigator true 6dof device. If you are using the later then you'll need evdev 2.1.0 or later, and if you're using 2.1.0 see this bug for a patch to get more than X and Y axis working.
More information to follow, including a video and details on the space navigator and GE.
libsixdof and a wiimote to control Google Earth under Linux from Ben Martin on Vimeo.
More information to follow, including a video and details on the space navigator and GE.
libsixdof and a wiimote to control Google Earth under Linux from Ben Martin on Vimeo.
Saturday, January 10, 2009
Chinook vs Diablo
While most folks have upgraded to Diablo long, long ago, I fell into the trap of actually using the n810 early on. So I had a nice chinook setup and didn't really want to do the Wintel mantra of reinstalling just to get diablo. But now I've been playing with both, with two n810 devices, because its always more fun with two ;)
So one is running the Chinook from about Feb 2008 and the other RX-44_DIABLO_5.2008.43-7. I thought that wifi felt faster on Diablo, so I did a little measuring. Its quite slap happy but does show some considerable difference, using the same DLink DIR-855 AP for both devices.
On the server:
dd if=/dev/zero of=10mb bs=1024 count=10240
On the tablet:
time wget -Y off http://x/10mb
The results:
chinook:
real 0m29.301s
user 0m1.047s
sys 0m1.828s
350k/s
diablo:
real 0m24.815s
user 0m0.656s
sys 0m1.188s
546k/s
The chinook k/s is quite stable at around 350. On diablo things move around quite a bit in terms of speed. Perhaps this bursty nature works well for browsing making things 'feel' faster too.
So one is running the Chinook from about Feb 2008 and the other RX-44_DIABLO_5.2008.43-7. I thought that wifi felt faster on Diablo, so I did a little measuring. Its quite slap happy but does show some considerable difference, using the same DLink DIR-855 AP for both devices.
On the server:
dd if=/dev/zero of=10mb bs=1024 count=10240
On the tablet:
time wget -Y off http://x/10mb
The results:
chinook:
real 0m29.301s
user 0m1.047s
sys 0m1.828s
350k/s
diablo:
real 0m24.815s
user 0m0.656s
sys 0m1.188s
546k/s
The chinook k/s is quite stable at around 350. On diablo things move around quite a bit in terms of speed. Perhaps this bursty nature works well for browsing making things 'feel' faster too.
Monday, December 15, 2008
Welcome to the libferris screencast on copy append.
1) I start a copy from the command line.
2) I decide I want to copy another file to the same place.
For example to the same USB stick.
3) In the old days, I would have to start a parallel copy
or wait for the first copy to finish before copying
the second file.
4) Now, with libferris, I can just append it to the existing copy task for this destination.
1) I start a copy from the command line.
2) I decide I want to copy another file to the same place.
For example to the same USB stick.
3) In the old days, I would have to start a parallel copy
or wait for the first copy to finish before copying
the second file.
4) Now, with libferris, I can just append it to the existing copy task for this destination.
Unfortunately the video quality is not so good in the final web version. Still some fun and games to be had getting things up to scratch.
Untitled from Ben Martin on Vimeo.
Wednesday, December 10, 2008
Automounting for the People
Now that the bad pun in the title has been read, you can't unread it!
So, now libferris has some closer HAL integration. Of course, some might say right away that ferris has been able to mount dbus for ages, so why have an explicit hal:// filesystem. The reason is that the fdo methods in the raw dbus interface for HAL are very coarse, and by explicitly having a hal:// and a volume manager daemon you get some interesting possibilities.
When the daemon can't work out what to do, it runs a nice little wizard:
One you choose how to identify the volume, you can tell libferris what to do:
More actions will arrive in time. I particularly like the auto copy mode, if a usb stick is readable at 20mb/s, a local scratch RAID-10 at 200Mb/s it makes sense to start moving the data to the scratch RAID right away and then pick it apart from there rather than from the USB stick directly.
So, now libferris has some closer HAL integration. Of course, some might say right away that ferris has been able to mount dbus for ages, so why have an explicit hal:// filesystem. The reason is that the fdo methods in the raw dbus interface for HAL are very coarse, and by explicitly having a hal:// and a volume manager daemon you get some interesting possibilities.
When the daemon can't work out what to do, it runs a nice little wizard:
One you choose how to identify the volume, you can tell libferris what to do:
More actions will arrive in time. I particularly like the auto copy mode, if a usb stick is readable at 20mb/s, a local scratch RAID-10 at 200Mb/s it makes sense to start moving the data to the scratch RAID right away and then pick it apart from there rather than from the USB stick directly.
Subscribe to:
Posts (Atom)