Follow me, if you can

I have been watching Qt progressing though, and ever since they introduced Qt Kinetic and QML it became very interesting for me again. QML looks like EFL’s Edje been thought through — don’t get me wrong, Edje was groundbreaking (as most of Rasterman’s work) when it made its debut, however in my opinion it got stuck in the middle and never lived up to what I was expecting from it.

Once QML ships with Qt — hopefully in the next minor or at least major version of Qt, I will get back on doing some FOSS work on application level to complete creating a smart phone stack. That’s going to be fun!

Due to the short notice, we could not manage to create a video recording infrastructure, so I’m afraid this year we can only provide the slides — which are a notoriously bad substitute for real talks though. We try to improve for next year — if we can get a devroom again. The pictures you are seeing are courtesy Dr. Nikolaus Schaller from Goldelico, btw. — thanks!

The FOSDEM team did certainly improve its organization over the last years, I was very pleased to see some of my criticism being taken into account. Apart from the lack of good coffee in Brussels (which the FOSDEM team probably is unguilty for), I can’t complain about anything. Even WiFi worked tremendously well on saturday. I still think due to the size of the ever growing interest in this conference that the ULB as location should seriously be reconsidered though. The special service transport on sunday to the main station is a great idea, folks — thanks a lot! Funnily enough, half of the ICE that took me to/from Frankfurt/Main to Brussels Zuid was filled with hackers, btw.

I have met some interesting people working on mobile devices, such as dcordes, leviathan, GNUtoo, cr2, larsc, heinervdm, etc. It’s great to see there is still momentum in real mobile FOSS architectures (i.e. something besides the Android, Maemo, or WebOS systems). I’m glad to tell you that this year we will see an exciting breakthrough in freesmartphone.org middleware supporting new platforms, i.e. progress on the HTC Dream and the Palm Pre is looking _very_ well. Stay tuned for more details appearing here soon.

I wish every conference would be like that. The only slightly disappointing thing was the cross-buildsystem-session in the embedded room. Just when I was expecting the discussion about the problems and potential collaboration to start, the time for the session was over. Rather than wasting time watching Andy Green telling us that our projects will die soon and we should all start using Fedora/Embedded now, we could have had some progress… Oh well, perhaps next year.

Hope to see you there!

• devtmpfs — kernel support for the /dev file system
• dbus system activation — on-demand launching of dbus-based services

I’m going to carry out the following two tasks in OE:

1. Writing fso-boot, a small executable written in C, which mounts the filesystems, brings up DBus and (optionally) launches X11
2. Setting fso-boot as new init process, that way you still have sysvinit and udev in your root file system, but they’re not active unless explicitly asked for

I’ll do that for the freesmartphone.org adaptation for the HTC Dream (T-Mobile G1, Google ADP-1), which I’m running on 2.6.32 (necessary for devtmpfs) — stay tuned for the first benchmarks.

The idea behind this is a very important one. With only the Openmoko FreeRunner as a platform, the FSO stack is doomed into oblivion sooner or later, since its a very limited hardware platform — in quantity, but considering the closed alternatives also in quality. Hence, we need to proof that FSO can run on current, competitive hardware — to embrace companies that want to adopt FSO in their niche.

The Palm Pre is currently our major hope — all other hardware being either too closed (yes, this includes the Nokia N900) or already outdated.

• GPE
• FSO
• OpenEZX
• OpenMoko
• Gnufiish

in a more relaxed way — giving room to dive into some technical issues, when interested folks come around.

Find me there, if you’re interested in any of the aforementioned projects. I’ll be there until Friday afternoon.

freesmartphone.org

Let’s start with the major project I’ve been working on, the freesmartphone.org project, funded by Openmoko, Inc. FSO grows, and it grows in the right directions. We get more API customers — notably the SHR project and the Paroli project — and refine our API and the reference implementation. The 5th milestone has just been released and apart from a major foobar with read-only partitions, it’s pretty good. We are going to fix this OE-inheritance and release a milestone 5.1 in a couple of days.

fso-abyss (GSM 07.10 Multiplexing)

For some modems — e.g. the TI Calypso (see my previous post on ogsmd and its modems) — until now we have relied on pyneo’s gsm0710muxd. Over the last weeks we found some severe problems (race conditions, buffer overflows) with this though, so I thought I have a shot at developing my own GSM 07.10 Multiplexer.

The result is called fso-abyss and is — as with all our software — available at git.freesmartphone.org under a free software license. The major difference to gsm0710muxd is the architecture (and maintainability). While gsm0710muxd combines talking to the serial ports, the pty’s, handling dbus queries, and doing modem specific things, fso-abyss went a different route.

At the heart there is a minimal protocol engine implementing GSM 07.10. Since there was already something available in Qtopia — even nicely seperated without any external dependencies — I took that one and factored it out in a dedicated project called libgsm0710 (available in git as well). The idea here is that different interest groups can collaborate on getting the protocol engine right, since not everyone wants a DBus frontend such as implemented in fso-abyss. The next step was writing a VAPI file for glueing the protocol engine to Vala (more about that one in a bit), which has been used to develop the upper layers of fso-abyss.

Last but not least, there was the pty implementation, the serial port communications abstraction, and finally the dbus server. The DBus API originally designed in cooperation with pyneo has been enhanced to feature the additional features (only) present in fso-abyss. Apart from the architecture, fso-abyss also can handle virtual serial port signalling, 07.10 test commands, automatic session handling, has a wakeup service, and more. Next up is adding support for the Cinterion mc75i which has some proprietary extensions to GSM 07.10 Basic Multiplexing.

dbus-hlid (DBus High Level Introspection Daemon

Modern DBus APIs are pretty dynamic, i.e. objects can come and go at any time. Depending on the hardware, you may find more or less objects of a certain kind. You can now add infrastructure to query the objects (essentially a duplication of what DBus should provide), or just rely on the existing DBus introspection API. Unfortunately this API is missing some critical features to make it really usable, such as querying objects that implement a certain interface.

So I took the plunge and factored this out of the freesmartphone.org frameworkd, since it has broader use. This is the API for it (as introspected by mdbus):

root@om-gta02:~# mdbus -s org.freesmartphone.DBus /org/freesmartphone/DBus
[METHOD] org.freesmartphone.DBus.ListBusNames() -> ( as:result )
[METHOD] org.freesmartphone.DBus.ListObjectPaths( s:busname ) -> ( ao:result )
[METHOD] org.freesmartphone.DBus.ListObjectsByInterface( s:busname, s:iface ) -> ( ao:result )


Here are examples of how you can use it (demonstrated within a Python shell):

>>> hlid.ListBusNames()
[ 'org.freedesktop.DBus',
'org.freesmartphone.omuxerd',
':1.21',
'org.bluez',
'org.tichy.launcher',
':1.13',
':1.0',
'org.freesmartphone.frameworkd',
':1.14',
':1.1',
':1.2',
':1.3',
':1.4',
'org.freesmartphone.ogsmd',
':1.6',
'org.freesmartphone.DBus']

>>> hlid.ListObjectPaths("org.freesmartphone.ogsmd")
['/org/freesmartphone/GSM/Device', '/org/freesmartphone/GSM/Server']

>>> hlid.ListObjectPaths("org.freesmartphone.odeviced")
[ '/org/freesmartphone/Device/Audio',
'/org/freesmartphone/Device/CPU',
'/org/freesmartphone/Device/Display',
'/org/freesmartphone/Device/Display/0',
'/org/freesmartphone/Device/Display/gta02_bl',
'/org/freesmartphone/Device/IdleNotifier/0',
'/org/freesmartphone/Device/Info',
'/org/freesmartphone/Device/Input',
'/org/freesmartphone/Device/LED/gta02_aux_red',
'/org/freesmartphone/Device/LED/gta02_power_blue',
'/org/freesmartphone/Device/LED/gta02_power_orange',
'/org/freesmartphone/Device/LED/neo1973_vibrator',
'/org/freesmartphone/Device/PowerControl/Bluetooth',
'/org/freesmartphone/Device/PowerControl/UsbHost',
'/org/freesmartphone/Device/PowerControl/WiFi',
'/org/freesmartphone/Device/PowerSupply/ac',
'/org/freesmartphone/Device/PowerSupply/adapter',
'/org/freesmartphone/Device/PowerSupply/apm',
'/org/freesmartphone/Device/PowerSupply/battery',
'/org/freesmartphone/Device/PowerSupply/usb',
'/org/freesmartphone/Device/RealTimeClock/0',
'/org/freesmartphone/Device/RealTimeClock/rtc0']

>>> hlid.ListObjectsByInterface("org.freesmartphone.odeviced", "org.freesmartphone.Device.LED")
[ '/org/freesmartphone/Device/LED/gta02_aux_red',
'/org/freesmartphone/Device/LED/gta02_power_blue',
'/org/freesmartphone/Device/LED/gta02_power_orange',
'/org/freesmartphone/Device/LED/neo1973_vibrator']


fso-monitord

While working on implementing GSM time(zone) support for ogsmd, we found we had too few samples, especially since time(zone) information are only sent by few providers all over the world. Moreoever, we missed a generic means to record all the data the frameworkd is sending out via its signals, such as:

• Usage statistics
• Location Updates
• Diagnostic Data

To support this (and more), we came up with fso-monitord, which is available from git as well. fso-monitord logs its data to a flat file format that you can send to us to improve our databases or for debugging. We also figured this would be the best place to add a generic frameworkd watchdog — monitoring all fso components — shutting down or restarting components as necessary and also logging incidents such as API violations.

What’s next in FSO?

For milestone 5.5 (due end of march), we have two major features on the roadmap, namely bluetooth networking (headset profile) and extended PIM support. Milestone 6 will then sport full-fledged networking.

Beyond milestone 6 — apart from one major thing, which I’ll cover in a second — we only have some rough plans, such as revamping or refining the subsystems we’re not perfectly happy with (oeventsd and opreferencesd come to mind). Also, alsa audio scenario handling is broken by design, but this is something we have to take up with upstream.

The freesmartphone.org reference implementation has been progressing incredibly fast. This is partly due to choosing Python as the implementation language (which has been a wise choice) of our DBus APIs. Now you all know that although I truely love Python (I even wrote a book about it) and try to use it everywhere it fits, I’m very well aware that for the future of the freesmartphone.org project, it might be important to come up with a frameworkd reimplementation in a compiled language — to reduce the footprint and squeak every possible bit of performance out of the (embedded) system.

This is why I have decided to encourage a second reference implementation. This one will be written in Vala (I might have mentioned it before, did I?) which is an incredible combination of elegance and performance, featuring a complete lack of any runtime penalties and additional dependencies. It’s simply amazing and I’m seriously thinking about writing an introductionary book about Vala later this year.

Anyways, back to the topic, the first bits of this Vala implementation has landed in the freesmartphone.org git in the form of the very successful GSoC project odeviced, written by Sudarshan S. Stay tuned for some amazing FSO runtime speedups coming in autumn and winter this year to your device.

XeTex

Next to writing software for the freesmartphone.org project, I also found some time to pick up working with my favourite writing tool LyX. LyX, which could be described as a LaTeX frontend, nowadays features integration with the new LaTeX variant XeTex. In contrast to other incarnations such as pdfLaTeX, XeTeX can utilize system fonts such as AAT or OpenType, which are the latest technology in computer-assisted typesetting.

I can now use my “corporate” fonts FF Meta and FF Meta Serif from LyX — amazing!

Conferences

Although still working on cutting down my travelling, I can’t miss some conferences this year. I managed to skip FOSDEM, which made me a bit sad, but I’ll be compensated by attending

• Chemnitzer Linux-Tage
• FOSS Aalborg
• OpenExpo 2009
• LinuxTag 2009

and possible some more… This year my main topics will be OpenEmbedded and freesmartphone.org — both dedicated to reducing the fragmentation of Linux-based embedded systems and to ease writing software for mobile devices running free and open source software. I hope we’ll bump into each other at one of these occasions.

Stay tuned!