After Trolltech dropping the ball with the community back in the old days of Opie, I pretty much gave up on Qt (and C++) apart from accepting some contract work, so my C++/Qt skills would not get too rusty. Since my nightmares with getting something fluid out of Gtk+ (back in the Openmoko days), I did not have the chance to do much UI work - the freesmartphone.org middleware kept me busy enough.

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!

27 Feb 2010 3:44pm GMT

Just came back from FOSDEM 2010, which - after skipping the last incarnation - was a great inspiring and productive event. The Openmoko devroom we originally requested was declined, however thanks to the initiative of Serdar Dere, it turned out we could snatch a last minute 3 hours timeslot that was left open by the Xorg guys. Very shortly we prepared a schedule and managed to get a nice program which was very well received.

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.

08 Feb 2010 7:56pm GMT

Due to some lucky coincidences, we got a devroom at this year's FOSDEM. I'll be there, presenting a short overview about the history of the Openmoko project as well as a wrap-up of the latest work on the freesmartphone.org mobile devices middleware.

Hope to see you there!

03 Feb 2010 12:14pm GMT

I'm fed up with booting my Linux-based smartphones like desktop-systems. Two major developments will help me accomplish enormous improvements in boot speed:

• 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.

01 Feb 2010 11:59pm GMT

As mentioned, the freesmartphone.org team and community has taken the challenge to put the FSO stack on the Palm Pre which is out next month. The goal is to manage a voice call with the FSO stack within four weeks.

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.

25 Sep 2009 5:18pm GMT

Something wonderful has happened! Jürg Billeter - mastermind of Vala - pushed support for server-side async dbus into Vala. I hope I didn't annoy him too much (having continuesly pestered for almost a year now), but the net effect is that we can now continue working on fsogsmd, the Vala implementation of our dbus GSM server (see http://docs.freesmartphone.org for an overview of the API). Yay!

13 Sep 2009 5:44pm GMT

I'm on my way to LinuxTag 2009. Instead of a "real booth" like last year, we settled on a developer table in the hacking area - there we can present our Linux on mobile projects such as

• 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.

24 Jun 2009 5:34am GMT

I felt it's time to recap the stuff that kept me busy the last months and give you an overview over the achievements planned for this year - always focusing the free software movement, of course.

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!

17 Feb 2009 6:36pm GMT

Although traditionally the Chaos Computer Congress' schedule is slightly suboptimal for me (12/26th is my birthday), I'm going to be in Berlin from 12/28th to 12/30th and will visit CCC on the 3th day (12/29th). I'm going to attend Harald's talk about GSM base stations, so if you want to talk to me, just pick me up afterwards.

27 Dec 2008 1:29am GMT

好久不見! Three weeks passed within a blink. Last sunday, we smoothly landed in Frankfurt/Main after 14 hours of a calm flight. 4/5 of the Openmoko Framework Team (while Stefan was on vacation in .au and missed all the fun) met in Taipei to tackle some outstanding issues and synchronize with the plans for the next major Openmoko release.

For a start, please refer to the blog postings of Charlie and Daniel, who mentioned some of the things we did in detail. Let me cover the current status and what we are going to work on in the remainder of this year and then step back and talk a bit about the meaning of all this. Right now the framework offers you support for the following tasks, everything accessible via consistent and convenient DBus interfaces:

• Device control (Backlight, Peripheral Power, Real Time Clock, USB, Switches, Buttons, Audio) covers the basics for embedded systems. Thanks to kernel 2.6, most of these interfaces are working on all devices - adding a new device should require almost 0 work. In fact the only machine specific module we have in odeviced is neo-powercontrol which takes care of the Openmoko specific peripheral devices.
• GSM Telephony (SIM access, SMS, Network, Calls, Supplemental Services, GPRS) is more or less feature complete minus some of the more esoteric features such as advice of charge (AOC) and GSM time (zone) reporting, which are only supported by few providers. Right now we have support for the following modems:
• • Generic singleline and multiplexed multiline, serving as start points for your customizations,
  • TI Calypso, as found in Openmoko devices and some HTC ones,
  • Sierra USB, as found in Lenovo Thinkpads,
  • Freescale Neptune, as found in Motorola EZX phones.

  Support for the SIEMENS / Cinterion MC75i as well as for the Qualcomm-based HTC devices is on our list next.

• Resource Control for peripheral subsystems, such as GSM, GPS, Bluetooth, Wifi, etc. This provides you with reference counted resource management allowing for a maximum of user level power management (kernel level power management is not covered here).
• (A)GPS support covering NMEA and UBX devices with downloadable ephemeris and almanac for greatly improved warm- and coldstart performance.
• Preferences, Events, and Rules. This triade supports a simple way of configuring application preferences as well as defining system behaviour (display dimming, ringtones, sms notifications, battery notifications, and much more) using a set of extendable and customizable rules.

The two major things missing until we officially declare a 0.9 release are PIM and Networking. For the former, we're attempting to integrate the results of a Google Summer of Code project (opim API), for the latter, we're (still) evaluating whether NetworkManager, Moblin Connman, or Exalt can fit our usecases and needs - plus a very limited set of convenient calls on top.

All of the above is of course complementing the freedesktop.org initiative and should serve as a natural addition in order to help standardizing important Linux-based embedded APIs, as found in Maemo, Openmoko, LiMo, Moblin, OpenEZX, etc. We are commited to cooperate with said platforms to help defragmenting the mobile device world so that application programmers have it easier to target multiple platforms.

Along this line, the recently posted weekly Openmoko engineering newsletter adressed the issue of Openmoko and its relationship to freesmartphone.org. The bottom line is that Openmoko is funding the freesmartphone.org initiative to help fighting fragmentation. Previously Openmoko's strategy was breadth-first to show the amazing versatility of open devices. Their next strike is going deep in one direction to create something that is both attracting developers (thanks to the dbus service level framework) as well as users (thanks to a pleasingly simple, extensible, phone application). We will see both of this in the forthcoming Openmoko 2009 distribution which is going to be the first FSO-compliant distribution ever - with more (e.g. Debian with pkg-fso, SHR and Rasterman's work) being underway. Lots of them built out of OpenEmbedded, of course. (Speaking of OpenEmbedded - the long awaited switch to git is happening this week. Open the flood gates and embrace our new revision control system )

Last but not least some personal remarks. With me being part of the Openmoko family for more than two years now, it was time to reevaluate and redefine our relationship. I'm really glad to announce that Openmoko supports my direction of stepping a bit back from being overall Openmoko platform architect, allowing me to concentrate on the freesmartphone.org framework - making this part of the Openmoko platform as strong as possible.

As said, the three weeks passed too quickly and we found out we need to synchronize more often - hence I'm looking forward to increase the frequency a bit and next year stay more often at the Openmoko headquarters. 乾杯!

14 Oct 2008 1:35pm GMT

Over the last week, directly after LinuxTag, I was in Vachdorf. If you like to know more about this small village take a look at OSM. Of course we mapped the whole village while being there.

The reason for being there was the TechWeek from Pengutronix, a company from my area doing a lot linux embedded projects for the industry. I already known some of the people working there privately. While being there I got known to the other ones. I must admit that it is a nice bunch of smart people loving what they are doing. What I actually appreciate a lot is their work to get their patches into mainline, even if it costs a lot of time and money. This is a not-so-common practice in the industry linux embedded world.

While hanging out there and having good talks about git, patch handling and submission workflows I spend most of my time working on geting some of the EZX patches mainline ready. We now have a svn branch that contains patches sitting directly on top of the arm git tree pxa branch. While working on this I also started to submit three one-line fixes upstream to get used to the arm-linux workflow. 2 Are already in the git tree, one is acked and waiting in incoming.

I enjoyed the week. Smart people, good food and hacking on stuff you like. Life could be that easy...

12 Jun 2008 3:28pm GMT

Next tuesday I'll be on my way to Berlin for the LinuxTag. It will be some busy days between giving a talk, an interview for Radio Tux and hanging out at the booth of my ex-employer.

Still I'm looking forward to it. This time I hopefully have some time to attend the technically talks. I look at you kernel track. And let Harald de-mystify the security of the micro waves around us.

22 May 2008 10:37pm GMT

Over the last days I did some changes to the SCMs for my private projects. Some got migrated from svn to git. Also some git repos changed the location. Please refer to the overview websites if you run into trouble:

http://svn.datenfreihafen.org/$PROJECT_NAME

http://git.datenfreihafen.org/

09 May 2008 2:24pm GMT

Since I left OpenMoko I have found some time to work on OpenEZX again. There are two nice things that happened since then.

The first one was that I got an 18bpp patch for all the second generation devices working. At least pxafb and fbcon are working fine now. I still need to test X more. :) The patch was from the gumstix patchset. Thank you guys.

The second was the boot_usb 0.2.0 release. We use this little tool a lot and SVN is stable most of the time. Especially after Daniel Ribeiro added support for initrd, commandline and setting the machine ID a release was needed.

08 May 2008 11:27pm GMT

Mickey already blogged about it. This is something we talked about a lot lately. Sometimes frustrated sometimes with hope. It is something we never got right since the beginning.

Ease the development of new applications and services. Build your kick ass stuff on top of a good fundament. And if it does not give you what you need, extend it. It's not like other commercial frameworks where you have to deal with what you get. It's open, take it, extend it, send patches. :)

Let's hope the framework team get the resources they need for getting it done. I also have some private ideas how to contribute here. Once I have something ready I let you know.

As code is better then words, take a look at their git repos.

08 May 2008 10:40pm GMT

Dear Lazyweb,

I'm interested in SDIO wifi cards that could be supported within a 2.6 linux kernel. Using them to add wifi connectivity to my EZX devices would be nice. EZX devices are based on PXA270 with full SD or microSD slots.

It would now be interesting to know if the Spectec SDIO cards are based on the Atheros 6000 SDIO chip. OpenMoko is working on a GPL driver for this chip. That would hopefully reduce the amount of work to get it running on other devices.

So anybody knows more about the chip Spectec use?

regards

Stefan Schmidt

10 Dec 2007 4:28pm GMT