Openmoko Freerunner Test Application

A while back I wrote a little script in Python to test some of the new features of the Openmoko Freerunner. Several people have requested the source code, so I’ve cleaned it up a bit and made it available here: http://folks.o-hand.com/thomas/openmoko/gta02.py

There are a couple of items on the todo list and I’m sure anyone with more decent Python skills than me could do a fair amount of cleaning up with it. However, it works and is useful at least as a demonstration.

It requires python and pygtk.

81db03e78db4a5dc4e2ee9977bd44571.png

Contacts 0.9 Released

contacts.png
Plenty of bugs fixed in this version. I am hoping to use this as the release candidate for version 1.0, so please send in any updated translations either to me (thomas at openedhand.com) or attach them straight to bugzilla. Also, I haven’t fixed many Maemo issues because we don’t really support the Maemo version (Maemo already has an address book anyway…). However, I’m more than willing to apply patches if people are able to supply them.

I’d like to add a special thanks to Adrien Bustany and Gilles Dartiguelongue for their patches that I’ve included in this release. If anyone else has any (small) feature of bug fix they would like to see done before 1.0, now is the time to start working on your patches!

Overview of Changes in 0.9 (since 0.8)

Bugs fixed:

  • 139: Contacts does not exit cleanly, leaves socket behind
  • 169: horrificially non-obvious choices of field names
  • 224: Search chokes on non-ascii chars
  • 275: tab key behavior inconsistent
  • 305: Available labels for email are insane
  • 306: Better location labels for us stupid Americans
  • 308: No way to view “unfiled” contacts
  • 309: Groups dropdown in main window not alpha-sorted
  • 310: Contacts does not create “file under” field, not usable in Evolution
  • 318: Do not show fields that are blank
  • 338: Possible to add duplicate groups to a contact
  • 339: Keyboard shortcut conflicts
  • 341: Unexpected triple-click behavior in Name/Groups display
  • 368: Should import concatenated vcards
  • 489: Missing field definitions in Contacts.
  • 492: Only installing 26×26 icons when building for Maemo platforms.
  • 659: New contacts do not have a N: field – my mobile reject them
  • 774: Fails to build from source under Ubuntu Hardy
  • 808: All vcards for companies are displayed as ‘Unnamed’
  • 885, 42: Attributes not sorted in view mode
  • 888: Contacts segfaults when provided with incomplete options on command line
  • 890: Typos in source code
  • 893: Remove recursive function
  • 896: Simple DBus interface

Sources

Tarballs: http://pimlico-project.org/sources/contacts/
Subversion: http://svn.o-hand.com/repos/contacts/trunk/

Reporting Bugs

Please report any bugs using the bugzilla bug tracker at:
http://bugzilla.o-hand.com/

Website

Screenshots and more information available at:
http://pimlico-project.org/contacts.html

Opkg Memory Cleanup

Last Friday I decided to use Valgrind to check the memory usage in opkg and discovered that it was leaking quite a substantial amount of memory.

Over the last two and a half days I’ve been fixing all the memory leaks exhibited by running my libopkg_test application. I have reduced the directly lost and indirectly lost memory to 0 bytes. The reachable memory at exit has been reduced to 29kB (down from ~13MB), with the remaining blocks belonging to libgpgme and libcurl which does not appear to be freed by their
respective de-initialisation routines.

Having had such a detailed look at the code, I am fairly certain further optimisation work is possible in terms of both memory usage and speed.

Some interesting statistics:

  • I’ve add some 65 additional free and deinit statements
  • … of which 52 are additional free() calls alone
  • 18 files changed, mostly in libopkg, but also one in libbb
  • There where a total of 184 lines inserted and 25 lines deleted in the full diff

I used Valgrind’s memcheck tool to help identify the leaks and massif to visualise the memory usage. It seems the Valgrind authors have remove the postscript output from massif in favour of an ascii chart. I’d be interested if anyone knows a way to display the massif output in a more graphical (non-ascii) way.

N.B. The scales on the two graphs are different, so be sure to read the axis when comparing!

Before the cleanup…

 ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 67 from 1)
 malloc/free: in use at exit: 14,808,479 bytes in 577,152 blocks.
 malloc/free: 1,145,825 allocs, 568,673 frees, 1,444,779,097 bytes allocated.
 For counts of detected errors, rerun with: -v
 searching for pointers to 577,152 not-freed blocks.
 checked 12,358,812 bytes.

 LEAK SUMMARY:
    definitely lost: 611,971 bytes in 40,899 blocks.
    indirectly lost: 1,425,560 bytes in 83,798 blocks.
      possibly lost: 183 bytes in 7 blocks.
    still reachable: 12,770,765 bytes in 452,448 blocks.
         suppressed: 0 bytes in 0 blocks.
    MB
22.73^                                                   #                    
     |                                                  @#                    
     |                                                @ @# :                 .
     |                                              ,@@ @# : :   :. : . .. :::
     |                                            , @@@ @# : :,: :: : : :: :::
     |                                           ,@ @@@ @# : :@: :: : : :: :::
     |                                         , @@ @@@ @# : :@: :: : : :: :::
     |                                        @@ @@ @@@ @# : :@: :: : : :: :::
     |                 ,                     .@@ @@ @@@ @# : :@: :: : : :: :::
     |                @@.                  . :@@ @@ @@@ @# : :@: :: : : :: :::
     |              .@@@:                  : :@@ @@ @@@ @# : :@: :: : : :: :::
     |            . :@@@: :     ..@      .:: :@@ @@ @@@ @# : :@: :: : : :: :::
     |           @: :@@@: ::. . ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |          @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |        , @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |       .@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |     : :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |    .: :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |    :: :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |  : :: :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
   0 +----------------------------------------------------------------------->MB
     0                                                                   73.83

Number of snapshots: 53
 Detailed snapshots: [6, 7, 8, 11, 12, 13, 21, 30, 31, 32, 33, 34, 35, 36, 37, 38 (peak), 41]

The two peaks in the graph represent the parsing of the repository data into a hash table. In my test application, the repository data is updated from the feeds, so the package lists are re-parsed. Previously, the main de-initialisation procedure for opkg (which, I hasten to add, was inherited from ipkg) did not free the hash table of packages properly, which meant every time the package list was refreshed, the entire hash table of packages would be leaked. Had a user refreshed the package list several times in one session, it’s likely the device would very quickly have run out of memory.

After the cleanup…

 ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 65 from 1)
 malloc/free: in use at exit: 29,064 bytes in 2,013 blocks.
 malloc/free: 1,145,726 allocs, 1,143,713 frees, 1,443,951,146 bytes allocated.
 For counts of detected errors, rerun with: -v
 searching for pointers to 2,013 not-freed blocks.
 checked 390,804 bytes.

 LEAK SUMMARY:
    definitely lost: 0 bytes in 0 blocks.
      possibly lost: 0 bytes in 0 blocks.
    still reachable: 29,064 bytes in 2,013 blocks.
         suppressed: 0 bytes in 0 blocks.
 Reachable blocks (those to which a pointer was found) are not shown.
 To see them, rerun with: --leak-check=full --show-reachable=yes


    MB
13.04^             #                                 .                        
     |             #                                 :                        
     |            :#                                ::                        
     |           .:# @                             ::: :                      
     |           ::# @                            .::: :.                     
     |          @::# @    . ..                    :::: ::  .. ,.     ,:       
     |         :@::# @:  .:@::  :                ::::: :@  :::@:   .:@:.      
     |        .:@::# @: .::@:::::.              .::::: :@. :::@::::::@::      
     |       ,::@::# @: :::@::::::             .:::::: :@: :::@::::::@:::     
     |       @::@::# @: :::@::::::.            ::::::: :@: :::@::::::@::.     
     |      ,@::@::# @: :::@:::::::           .::::::: :@: :::@::::::@:::     
     |     ,@@::@::# @: :::@:::::::.         .:::::::: :@: :::@::::::@::::    
     |     @@@::@::# @: :::@::::::::         ::::::::: :@: :::@::::::@::::.   
     |    .@@@::@::# @: :::@::::::::         ::::::::: :@: :::@::::::@:::::   
     |    :@@@::@::# @: :::@:::::::::      . ::::::::: :@: :::@::::::@::::::  
     |    :@@@::@::# @: :::@:::::::::.     : ::::::::: :@: :::@::::::@:::::.  
     |   ::@@@::@::# @: :::@::::::::::     : ::::::::: :@: :::@::::::@::::::, 
     |  .::@@@::@::# @: :::@::::::::::    :: ::::::::: :@: :::@::::::@::::::@ 
     |  :::@@@::@::# @: :::@:::::::::::  .:: ::::::::: :@: :::@::::::@::::::@:
     | ,:::@@@::@::# @: :::@:::::::::::. ::: ::::::::: :@: :::@::::::@::::::@.
   0 +----------------------------------------------------------------------->MB
     0                                                                   94.44

Number of snapshots: 76
 Detailed snapshots: [1, 5, 6, 7, 10, 13 (peak), 14, 19, 32, 47, 53, 63, 73]

OpenMoko FreeRunner LEDs, etc.

Before I took my FreeRunner prototype along to Ole’s OpenMoko talk in London yesterday, I hacked up a little demo application in python/pygtk to display various new features in the FreeRunner (Wifi, accellerometers, LEDs). If you where there yesterday, you probably saw this live in action:

81db03e78db4a5dc4e2ee9977bd44571.png

On my previous post OpenMoko post, someone asked about the LEDs on the FreeRunner. Obviously, you can’t see any proof of the LEDs in screenshots, so I took some very quick photographs:

Red LED

Blue LED

Orange LED

History Meme

Desktop:

$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
91 cd
75 ls
49 svn
45 ssh
37 vim
37 make
13 ./test-notes
11 svn-prepare-ChangeLog.pl
11 ./openmoko-messages
11 ./openmoko-dialer

Laptop:

$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
91 vim
53 sh
52 svn
47 cd
40 ls
31 find
21 git
18 ssh
11 su
11 make

More Moko GTK+ Theme

Spurred on by the positive comments in my last little theme experiment for the OpenMoko, I have made a few adjustments based on some of the comments. It’s also now available in OpenMoko svn.

If you have a OpenMoko build set up, you can try it out. Firstly you need to build the package and then rebuild the package index:

bitbake moko-gtk-engine && bitbake package-index

You may have issues if you have built this before, because I did made some changes to the repository that svn can’t handle very cleanly, so if you have problems, wipe your svn checkout and start again.

Then you need to ssh into your neo and run the following commands:

  • opkg upgrade
  • opkg install moko-gtk-engine
  • dbus-launch gconftool-2 –t string -s /desktop/poky/interface/theme “Moko”
  • /etc/init.d/xserver-nodm restart

Here are some more screenshots of the theme running on the device. There are still some bugs with colours in a few places, so testing would be much appreciated.

screenshot-1.pngscreenshot-2.pngscreenshot-3.png

I think the GPS icon is green because the GPS chip was on when I took the screenshots. I’ve been testing a couple of the peripherals on my GTA02 lately and I’m happy to report so far Wifi, GPS, accellerometers and the LEDs all seem to be working correctly. I got a fix from the GPS today which according to Google maps, was within 1 meter of my actual location.

Brand New Moko Theme (Idea)

Inspired by ScaredyCat’s discovery that the default GTK+ theme was much faster on the Neo1973 than the current pixbuf based theme (well, no real suprises there…), I set to work stealing his colour scheme and completely redesigning my Moko theme engine. This time totally optimised for speed and simplicity. It’s still a work in progress, but here are some screenshots to give a general idea:

dialer.png contacts.png

Lines and other visual distractions are kept to a complete minimum. Although it doesn’t look that great on a desktop display, when it is on a 2.8″ 285dpi touch screen, it feels a lot better.