I bought the HTC Touch Pro some months ago in order to port the freesmartphone.org middleware to it and help to raise an end-user distro. While things began very optimistic (i.e. the modem support was completed after just a few weeks), it came to a relative halt pretty soonish afterwards — because of missing kernel support. Google releasing the kernel source code for the HTC Dream has enabled the HTClinux folks to quickly come up with some very impressive results, but due to the heavy differences in the baseband firmware it did not spare them from carrying out an amazing pile of reverse engineeering — just like every other anti-vendor-port.

While these guys truly have done great work, I personally think it’s not going anywhere soon — at least not to a point where we have an open GNU/Linux on competitive hardware fully supporting all peripherals of the device. Showstoppers are always Bluetooth, Wifi, Sound, Suspend/Resume, and all the other things where Google didn’t care about standard mainline interfaces, but rather decided to put the meat into userland — stowed away behind a “safe” closed source license.

Anyways, this hope/dream/experiment has ended, hence I’m offering to donate my HTC Touch Pro (raph100) to one of the HTClinux kernel hackers as a last act of supporting this anti-vendor-port. If you think you are qualified, drop me a mail. Meanwhile, I’ll continue supporting the Openmoko devices and concentrate on the Palm Pre.

I just came back from the annual OpenEmbedded Developer Meeting (OEDEM) which happened to be in Cambridge, UK. It was a very productive meeting and we agreed on some important things to move OpenEmbedded forward as a whole. Please see the mailing lists for meeting minutes and summaries. We also elected a new board for the e.V. and despite the grief that led to me leaving the OE core team (which subsequently lead to the dissolving of it), I have volunteered (and been reelected) to serve a 2nd year as board member.

As written in a previous installment of this column, I have dedicated the lion’s share of 2009 to the reimplementation of the freesmartphone.org APIs in Vala. Please see the wiki for architectural details, as I don’t want to repeat this here. This is an overview of the current status:

fsousaged

fsousaged has been fully completed and is being used for quite a while now in distributions. All of the plugins are working:

• dbus_service: Implementation of resource handling as per org.freesmartphone.Usage.
• lowlevel_kernel26: Low level suspend/resume handling for Linux 2.6.
• lowlevel_openmoko: Low level suspend/resume handling for Openmoko Smartphones GTA01/GTA02.

fsodeviced

fsodeviced has been fully completed, but is not yet being used in any distributions. All of the plugins are working:

• accelerometer: generic accelerometer handling, needs one of the device-specific accelerometer plugins.
• accelerometer_lis302: lis 302 accelerometer support.
• alsa_audio: alsa audio PCM output and routing (scenario) support.
• kernel_idle: system idle notifications.
• kernel_input: system input handling.
• kernel_info: kernel information.
• kernel26_display: display class-device based brightness control.
• kernel26_rtc: realtime clock, wakeup alarm.
• kernel26_leds: LED class-device based brightness control.
• kernel26_powersupply: peripheral power supply control.
• openmoko_powercontrol: device-specific power supply controls for Openmoko devices.
• thinkpad_powercontrol: device-specific power supply controls for IBM Thinkpad devices.

fsotimed

fsotimed is about half-way complete compared to frameworkd. The working plugin is:

• alarm: DBus alarm service as per org.freesmartphone.Time.Alarm.

fsonetworkd

fsonetwork is done with the same level of functionality as in frameworkd. The working plugin is:

• sharing: internet connection sharing.

fsogsmd

fsogsmd has been on hold since end of April due to waiting for more Vala language features. When they finally appeared in September, I picked up where I left and furiosly worked on what i perceive as the prime subsystem of FSO

The basic infrastructure is more or less complete now and we cover about 50% of the DBus API as per org.freesmartphone.GSM.*, i.e. device info, sim access, network registration, sms, and call handling is working. All work has been done in a generic way, i.e. without taking any care of modem specifics yet — which is what will be my next task before I go on covering the missing API.

fsogpsd

I have added a skeleton of that to the repository and adapted some lower-level classes in libfsotransport to work both for fsogsmd and fsogpsd. I would have done more work, but I’m not keen on implementing the Gypsy API, since I think it’s not a particular good DBus API

fsopreferencesd / fsopimd / fsoeventsd

All these have not been started, not even been thinking much about ‘em. fsopreferencesd will probably have to wait until dconf / gvariant / gsettings have finally landed in glib. fsopimd is waiting for a redesign of the opimd API. fsoeventsd needs a new architecture, but I have to discuss this with the others before we can start cranking.

2010

will be a very interesting year for Linux on mobile devices, even more so for freesmartphone.org. Due to the lack of someone funding FSO, I will probably not find much time to work on FSO in 2010 — that’s why I’m so furiously working on getting most of it to a state where others can jump in before the end of this year.

Apart from that, I hope we can get FSOSHRCON’10 happening very early in 2010 and uplevel kernel support for some of the more interesting semi-open devices such as the Palm Pre, Nokia N900, and the HTC family. FSO would be more than happy to add device-specific support for this hardware once the kernel is up to par.

Cheers!

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.

We just released the following statement to various mailing lists:

Braunschweig, Germany, 2009-07-29. For immediate release.

The freesmartphone.org core-team founds a BGB company to facilitate the further development of free and open source middleware for Linux-based mobile systems: “Lauer, Lübbe, Schmidt, Willmann, freesmartphone.org GbR”.

The core-team members of the freesmartphone.org project today announced the founding of a legal entity offering consulting, training, and implementation services around the freesmartphone.org middleware platform, also known as FSO.

“We now have a single point of contact for both commercial and non-commercial parties who want to use our services to create compelling solutions. This is of interest for groups or individuals creating new devices or freeing existing devices (”anti-vendor-ports”) and who decided to incorporate the FSO middleware”, says Dr. Michael Lauer, founder of the FSO project. “If you care about the further development of this platform or if you need guidance for tailoring or customizing the FSO middleware, contact us via E-Mail at coreteam@freesmartphone.org”.

With todays’ smartphones evolving into ubiquituous companions, a gap has emerged between widely used FOSS components like the Linux kernel and core system libraries on one side, and end-user applications on the other side. The lack of a complete free mobile software stack hinders innovation and leads to reinventing proprietary solutions for services middleware.

FSO’s mission is to close this gap by designing and developing solid middleware for mobile systems in an open fashion; this refers to not only publishing source code under open source licenses, but also to sharing the whole design and development process with the community and giving both commercial and non-commercial entities a way to co-drive and steer the process.

Built on top of the Linux kernel, FSO implements high level services for mobile application development, accessible via the DBus interprocess communication standard. Leveraging the FSO APIs allows the developer to concentrate on solving application domain problems, such as business logic and presentation of data, without having to worry about the device specifics and low level details, such as how to access resources, telephony, location awareness, data storage, etc.

About freesmartphone.org: Previously funded by Openmoko Inc, freesmartphone.org is a collaboration platform for open source and open discussion software projects working on interoperability and shared technology for Linux-based smartphones. freesmartphone.org operates on the services layer (middleware) and offers APIs and reference implementations that support modern interconnected mobile devices. To provide reference solutions, freesmartphone.org works closely together with various device-specific communities such as the Openmoko, OpenEZX, and HTC-Linux groups. The FSO team honours and bases on specifications and software created by the freedesktop.org community.

This means you can hire us (or donate money), if you want to support the FSO middleware development.

After the sudden death of my Dreambox 7025, the new OE-based device in the living room is a Dreambox 8000 — simply the best set top box money can buy these days. Yes, it’s quite expensive, but the hardware is fully loaded (heck, there’s even WiFi) and the freedom to install what you want is invaluable.

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.

I have just sent a mail to the OE core team that I’m resigning as a member of said “core team”. I will also give up administration of mailing lists, my position as OpenEmbedded e.V. board member, and taking care about the git/web/etc. services machine.

I have been with OpenEmbedded since the beginning, together with Chris and Holger I founded it in 2002/2003, and although we had our ups and downs, over the years we always managed to keep the spirit of openness and friendlyness alive. However — over the last 12 months, I have experienced some very unpleasant incidents in how certain members are treating other contributors, scaring them away, coldheartedly enforcing policies that are meant to be bendable guidelines, etc.

This is no longer a project where I feel my contributions are welcome. The core team failed to do its job as a moderate and balanced steering committee — it is apathetic and just bows down to the will of the most vocal single indviduals. I’m utterly disappointed by the amount of carelessness.

Whether I will fork OE as a whole or maintain my own branch on the main server or somewhere else I have not decided yet.

Just returned from FOSS.Aalborg ‘09 where I held a talk about OpenEmbedded. It’s been my second time in Aalborg (first time was Mobile Developer Days ‘07) and it’s been a nice and informative experience. Met some folks doing amazing things with embedded. Everything was organized very professional and the presentations were interesting — particularly the talk about security which was held by two guys from the OpenBSD project. OpenBSD has never really been on my radar, although according to what I’ve seen in the presentations it seems to be of really high quality. I guess I’ll give it a look soon.

Next week I’ll be in Bern for OpenExpo ‘09. In May, the first FSOSHRCON and in June LinuxTag’09 are planned and perhaps FrOSCon again in August, but other than that, I pretty much try to stay at home for the remainder of this year.

Btw., there’s free WiFi on Aalborg Airport — that’s the spirit!

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!

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.