New dvtm and dwm-win32 Releases - Future Openmoko Related Activities

10.07.2009 at 12:15

Long time no blog post, sorry about that but I was again rather busy. Quite a lot actually happened in the meantime. I passed my BMS exams and will now try to successfully take the Passerelle which would allow me to study at an university. Because of this I left my current employer and will focus on school. Most of the preparation for this supplementary exam is actually done in a self-studying manner which means it requires quite a bit of discipline. Well we will see how this works in practice. A possible advantage of this type of learning is that I will be much more flexible in my time planing. I therefore hope that will find a bit more time to spend on my opensource related activities.


dvtm is actually in quite good shape and mostly in maintenance mode. The latest release dates from last week.


dwm-win32 a port of the X window manager dwm to MS Windows which I wrote about in my last blog post. It's basically in a proof of concept stage and I currently don't plan to further develop it. Checkout the project page for further information.


I hope that I can finally start to contribute in one way or another to the openmoko project.

As a first step I would like to implement a minimal boot menu which is based on a small Linux system. It's basically a stripped down kernel with an initramfs which contains a minimal C library like uClibc. The goal is to make this boot as fast as possible and then start a regular user space application which reads all available partitions of the SD card, searches for kernels and finally presents a nice looking boot list. The selected kernel will then be started via kexec.

That's the plan anyway, we will see if and how usable this actually works in practice.

That's all for now. Hope the next blog post won't take another 4 months to get written.


read more comments

Update and Future Plans

06.03.2009 at 10:56

The last few months have been rather busy because of various school and work related reasons. Therefore my free time coding sessions were rather short during this time frame. I hope this will improve in the summer holidays when I leave my current employer.

I would like to play around with Rasters new GUI Library for embedded devices called Elementary and finally get around to program something useful for my Freerunner. I am also thinking about porting dwm to win32 but as I have absolutely no win32-api knowledge it's not yet sure whether it will ever happen. Oh and there were new dvtm releases which should be pretty stable and feature complete.

Stay tuned.


read more comments

Getting the Freedom Universal Keyboard2 to Work Under Linux

25.10.2008 at 15:40

I recently bought a Freedom Universal Keyboard2 for use with my Freerunner. When it finally arrived I found out that it doesn't work by default under Linux although the openmoko wiki stated otherwise. Anyway I started googling around and found a mailing list post on bluez-user which suggested to disable the whole MTU handling. With this information I started looking around in the bluez-utils source and finally came up with a patch for hidd:

--- bluez-utils-3.36/hidd/main.c
+++ bluez-utils-3.36-working/hidd/main.c
@@ -90,12 +90,14 @@
 		return -1;
+#if 0
 	memset(&opts, 0, sizeof(opts));
 	opts.imtu = HIDP_DEFAULT_MTU;
 	opts.omtu = HIDP_DEFAULT_MTU;
 	opts.flush_to = 0xffff;
 	setsockopt(sk, SOL_L2CAP, L2CAP_OPTIONS, &opts, sizeof(opts));
 	memset(&addr, 0, sizeof(addr));
 	addr.l2_family  = AF_BLUETOOTH;
@@ -131,12 +133,14 @@
 	setsockopt(sk, SOL_L2CAP, L2CAP_LM, &lm, sizeof(lm));
+#if 0
 	memset(&opts, 0, sizeof(opts));
 	opts.imtu = HIDP_DEFAULT_MTU;
 	opts.omtu = HIDP_DEFAULT_MTU;
 	opts.flush_to = 0xffff;
 	setsockopt(sk, SOL_L2CAP, L2CAP_OPTIONS, &opts, sizeof(opts));
 	if (listen(sk, backlog) < 0) {

With this patch applied and the steps below I got the keyboard to work both on my desktop (Debian Sid) and Freerunner (Om2008.8). First we check whether our bluetooth controller is operating in HID mode and if so we will switch it to HCI mode. Then we search for new bluetooth devices and the keyboard should be found and connected.

lsusb | grep HID && hid2hci
./hidd --search

So far so good, then I learned that hidd is depreciated and a new dbus based input-service should be used instead. I hope they will at least provide a shell script wrapper with some easy to use command line switches. Haven't yet found the time to actually test this new method, but the keyboard works with hidd which means it should be possible to make it work one way or another.


read more comments

Pong -- Yes I Am Still Alive

24.10.2008 at 21:04

Wow, almost five months passed without a blog entry. But don't worry I am still alive, although life currently sucks big time!

Problem is that I currently don't have enough time to do fun stuff, because of school related things and work where I waste my time on boring things like online shops. For me it's still unclear why exactly the company I work for ended up doing web development based on the .NET platform -- company strategy I guess. Use the right tool for the right job doesn't seem to be popular these days. Anyway management decided to buy a "ready made" shop solution and customize it to connect to our ERP system, so I have to deal with a code base which seems to consist of WTFs. And don't get me started on things like our in house source control management system (VisualSource Safe) it's crap, I have now installed msysgit for my personal use. Once you are familiar with your *nix development tools, going back to Windows hurts extremely. I mean such useful little tools like diff/patch/sed/awk etc are not there by default. Enough ranting for now.

OpenMoko Community Event in Bern

After quite some delay my Freerunner finally arrived a few months ago. Since I am busy with pointless things (see above) I couldn't really contribute anything. I have so far only been playing around with it a bit. However one thing I managed to do was attending an OpenMoko Community Event in Bern. This was really interesting, I learned that Swisscom (the biggest telecommunication enterprise here in Switzerland) is evaluating the Freerunner as a possible platform for future products.

They are paying Raster to do a widget toolkit called Elementary which is suitable for mobile devices. The cool thing is that it's all based on relative coordinates and contains a clever layout algorithm which places the various gui elements as needed and makes the whole thing resolution independent.

They also funded some bug fixing work of Harald Welte. This resulted in massive power savings and performance improvements.

It was really interesting to talk with one of the Swisscom guys about their ideas. One thing they are concerned about is the usage of python in the framework. They worry about the performance and since everything is run in one process (the python interpreter) prioritizing via scheduler settings is not possible.

Anyway it was great fun to meet with other OpenMoko user and developers. Looking forward to future meetings.


read more comments

Source Code Formatting, License Flamewars and Build System Issues

20.05.2008 at 18:05

Tabs vs. Spaces

One of those never ending issues with source code formatting is the use of tabs vs. spaces. People seem to blindly argue for one or the other while not realizing that the best solution is to combine them in a smart way. That is, use tabs for indention and spaces for further alignment:

--->if (some_variable) {

This way everyone can set the tab width to their personal preference and the code will still look decent.

License Flamewars

As soon as I finished reading the mail containing a trivial ~10 line patch which was originally licensed under the GPLv3 for an otherwise MIT/X11 licensed program I knew this would result in a huge license flamewar. My opinion on this is pretty clear: whoever writes most of the code should decide it's license. It could be so fucking simple but it seems like people like to waste their time by arguing over the same things over and over. Oh well.

Build System Issues

It turned out that the new dvtm-0.4.1 release has a problem in it's build system which results in a breakage on the Debian server infrastructure. I changed an assignment in from = to += in order to provide an easier way to add extra flags. But because GNU make has a concept of different flavors of variables this doesn't quite work as expected.

The problem is that the behaviour of += depends on the variable type it's applied to. If it's used on a variable which wasn't previously defined it acts just like normal =: it defines a recursively-expanded variable. This means it's value is referenced and recalculated whenever the variable is accessed. This is most often the case and the world is a happy place. However, on the Debian build infrastructure it seems like the LDFLAGS variable is predefined somewhere as a simply expanded variable which means it's calculated ones upon definition. My Makefile is then called recursively and the value is appended again which results in a binary which is linked against both libncurses and libncursesw which obviously doesn't work.

I actually prefer simple Makefiles as build system when ever possible because it should be simple, get the job done without too many dirty tricks and don't waste valuable developer time. But it seems like you can shoot yourself in the foot pretty easily with Makefiles, Sigh. And no autohell is not the solution, it's the problem ;)

Package management dependency resolution algorithms

I am playing with the idea of writing my own package management tool which could replace opkg on my ordered Freerunner once it arrives here. The last time I looked at opkg (it was actually still called ipkg then) it's code was rather messy and contained things which I actually wouldn't need. I would also like to have plugable backends. This would ease experimentation with something like sqlite. An integration with a SCM to provide rollbacks would probably also be interesting although maybe a bit overkill for a mobile device.

Anyway I am interested in the dependency resolution algorithms of existing package managers like apt, yum or smart. Unfortunately google didn't really help me so far and digging through a pile of C++ code in case of apt doesn't sound like too much fun.

As I won't have that much free time in the near feature it should probably also reconsider helping in cleaning up opkg.

We will see what the future brings.


read more comments

<< 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 >>