Blog

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 timeframe. 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 programm 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.

Marc

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

Marc

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.

Facebook experiment

On a completely unrelated topic, hell froze over an I created a facebook profile. I am in the process of sending friend request to my old classmates who I had no contact with for about 4 years. Let's see how many still know who I am and confirm my request.

Marc

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 tab 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) {
--->--->long_function_name(first_argument,
--->--->...................second_argument);
--->}

This way everyone can set the tabwidth to whatever he likes 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 config.mk 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 make file 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 make files as build system when ever possible because it should be simple, get the job done without to 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 pluggable 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.

Marc

read more comments

ciopfs - case insensitive on purpose file system

01.05.2008 at 23:42

Some time ago i saw Wine's Google Summer of Code ideas as i know nearly nothing about the Windows pre .NET core APIs and have _zero_ interest in learning it most projects weren't of interest for me. However one idea about a case insensitive filesystem seamed like it would be fun to hack on.

The problem that wine has is that the file system on windows is case insensitive while most POSIX file systems are case sensitive. In order to find a given file by a case insensitive file name wine does currently scan directories a lot and this is actually quite slow. So the idea is to let the file system deal with the whole mess. This would also solve the problem where a user extracts a zip archive over an already existing directory tree and expects that the files will be replaced instead of created with different case.

So i wrote a FUSE based case insensitive file system: ciopfs was born. Unfortunately the wine developers don't seem to be too interested and so it probably won't go anywhere in the near future but it was nonetheless fun to play with FUSE and maybe it will be useful for someone out there.

Marc

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 23 >>