19 Oct 2011

feedPlanet OpenEZX

Antonio Ospite: Gnome 3: go to Shell? Not just yet, thanks.

In Debian Unstable the transition to Gnome 3 is taking place; when Gnome 3.0 firstly came out some unnamed geeky users complained loudly about the design decisions of the development team to push strongly towards gnome-shell as a new default UI; gnome-shell was designed focusing on usability (usability is a metric relative to a certain target audience BTW) and simplicity, hiding a lot of details from the users. Obviously you can never make everyone happy so some of us simply happened to be "out of target": you know us computer people (*cough cough*), we like to be in charge and control The Machine... I must admit I still don't have a definitive opinion about the gnome-shell concept, for now I just know that it does not suit me; I am going to try it eventually, maybe I'll get used to it, but in the mean time I need my desktop back just like I shaped it through the years; can this be done without loosing all the good Gnome technologies (Empathy over all of them)?

To be completely fair I have to say that there is little to complain about with Gnome developers, we can still get our good old GNOME desktop fully back by using the fall-back mode based on gnome-panel and live happily ever after, let's take a look at how this can be accomplished.

NOTE: GNOME people state that the fall-back mode is meant for systems with older graphic cards which cannot run gnome-shell, however it can very well be seen as a good opportunity for those who do not want to run gnome-shell just yet.

Getting back to the topic: some minor touches are needed to make the panel look more like what we are used to, maybe some of these settings could even become default for fall-back mode, we'll see.

First, enable fall-back mode (on Debian there is a dedicated session you can choose from the Log-in Manager for that) and change some desktop settings, in a terminal type:

$ gsettings set org.gnome.desktop.session session-name 'gnome-fallback'
$ gsettings set org.gnome.desktop.interface 'menus-have-icons' true
$ gsettings set org.gnome.desktop.interface 'buttons-have-icons' true
$ gsettings set org.gnome.desktop.background 'show-desktop-icons' true

gnome-tweak-tool can be used for some of these settings like shown in the attached images.

Then rearrange the applets on the panel as you please (use Alt-RightClick to access the panel properties), and fix the theming using this patch to have a light panel again (against gnome-themes-standard=3.0.2-1):

$ mkdir $HOME/.themes
$ cd $HOME/.themes
$ cp -r /usr/share/themes/Adwaita Adwaita-fallback
$ cd Adwaita-fallback
$ patch -p1 < $HOME/adwaita-fallback-panel-theme.patch
$ gsettings set org.gnome.desktop.interface 'gtk-theme' 'Adwaita-fallback'

Some final touches for the Metacity window manager and to the clock applet, and we are all set:

$ gconftool-2 --type string --set /apps/metacity/general/focus_mode mouse
$ gconftool-2 --type boolean --set /apps/metacity/general/compositing_manager true
$ gconftool-2 --type string --set /apps/panel3-applets/clock/custom_format '<span color="#333">%a %d %b</span> <b>%H:%M</b>'
$ gconftool-2 --type string --set /apps/panel3-applets/clock/format custom

Ah, in the new gnome-panel based on Gtk3 there are still some details to take care of, I hope issues like that will be addressed and that the panel will be supported for quite some time.

Attached images:
Gnome Shell default look on Debian
gnome-tweak-tool show desktop icons
Gnome 3 fall-back mode default look on Debian
Gnome 3 fall-back mode applets rearranged
Gnome 3 fall-back mode rethemed to have a light panel
Attached files:
text/x-diff iconAdwaita theme patch for fall-back mode

19 Oct 2011 9:37pm GMT

09 Jun 2011

feedPlanet OpenEZX

Michael Lauer: The Eagle Has Landed!

After letting us wait for a bit longer than scheduled (13 days), the hospital initiated the contractions. For the first couple of hours, everything went just perfect, but then the little one got stuck on the way and we had to resort to a cesarean section. Lara Marie Lauer was born 8th of June at 04:41 (AM) with 3460 gramms and 49 cm.

Mummy was still on intensive care and so they gave her to me. I can't express the feelings I had in this very moment. I'm still kind of overwhelmed every time I see her. Thanks for all of you who waited anxiously with me and those who prayed for us. The most important tasks for the near future is getting Mummy to recover and Lara Marie to become accustomed to us and the rest of the outside world.

Please bear with me if in the next time I'm not as responsive as usually :)

Lara Marie Lauer

09 Jun 2011 4:06pm GMT

30 May 2011

feedPlanet OpenEZX

Michael Lauer: German Post on time!

And now for something completely different… while we are all waiting for my baby to arrive (who was scheduled for 25th of May), she just received her first greeting card - together with a personalized bib and a towel (with integrated hood - pretty fancy!) from my good friends at #openmoko-cdevel.

Guys, seeing this card was very heartwarming - it means a lot to me that you share my anticipation, thanks a lot! And I'm 100% sure she will appreciate her gifts… now let's cross fingers it won't take much longer… waiting is the hardest part of it :)

Yours,

Mickey.

30 May 2011 8:54am GMT

06 May 2011

feedPlanet OpenEZX

Antonio Ospite: On git clone failing and tweaking object repack

I had been experiencing errors when cloning the OpenEZX kernel with git and I was finally able to solve the issue on the server, I am putting some notes here to save some time to someone else. Here's how the story started:

ao2@jcn:~$ git clone git://git.openezx.org/openezx.git
Cloning into openezx...
remote: Counting objects: 1954118, done.
remote: fatal: unable to create thread: Resource temporarily unavailable
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

Looking at the server statistics with htop confirmed this was happening because git was running out of memory on the server; it is worth noticing that the issue was not present when cloning other projects from the same server (Linux kernel projects as well, hence with a comparable size in principle).

With the following points in mind:

my thoughts went like:

  1. during a clone operation some compression of git objects occurs;
  2. because of the lack of swap space the compression operation must fit in memory;
  3. because of TopGit the compression operation on this repository was more onerous than on the other projects, causing the memory outage.

So some optimization on the repository about objects compression was needed.

The first thing that came to mind was git-gc but that was failing as well:

openezx:~# cd /home/git/repositories/openezx.git
openezx:/home/git/repositories/openezx.git# git gc --aggressive
Counting objects: 1954118, done.
Delta compression using up to 2 threads.
warning: suboptimal pack - out of memory02)   
fatal: Out of memory, malloc failed (tried to allocate 602234 bytes)
error: failed to run repack

The repack operation is performed by git-pack-objects, so after Reading The Fine Manual I was able to make git-gc run successfully using these steps:

openezx:/home/git/repositories/openezx.git# git config pack.thread 1
openezx:/home/git/repositories/openezx.git# git gc --aggressive
Counting objects: 1954118, done.
Compressing objects: 100% (1936802/1936802), done.
Writing objects: 100% (1954118/1954118), done.
Total 1954118 (delta 1618716), reused 0 (delta 0)

note that using only one thread makes the process quite slow.

In some other cases it could be useful to change also the pack.windowMemory config option, but a relation involving the address space, the available memory and the number of threads has to be found, so since just using one thread worked fine for me, I took that as the minimal fix for my problem.

Bottom line: cloning the repository is now back working:

ao2@jcn:~$ git clone git://git.openezx.org/openezx.git
Cloning into openezx...
remote: Counting objects: 1954118, done.
remote: Compressing objects: 100% (318086/318086), done.
remote: Total 1954118 (delta 1618716), reused 1954118 (delta 1618716)
Receiving objects: 100% (1954118/1954118), 377.38 MiB | 738 KiB/s, done.
Resolving deltas: 100% (1618716/1618716), done.

Side note: the more attentive reader would have noticed a cosmetic defect in the output when git-gc fails (more precisely from git-pack-objects: warning: suboptimal pack - out of memory02)), well don't loose any sleep over it :) it has been reported and there is a workaround for that already.

06 May 2011 10:41am GMT

06 Dec 2010

feedPlanet OpenEZX

Antonio Ospite: Kinect linux kernel driver

It looks like Santa came early this year.

KernelLabs sponsored me for a Kinect sensor device unit so I can experiment writing a Linux kernel driver for it.

So in the next weeks I'll be working on a gspca driver for this device. For now the code is going to be hosted in the gspca_kinect repository, as an out of kernel module, this will ease compile/test cycle; if it comes out that changes are needed to gspca itself, then I'll decide whether hosting these changes as patches, or switching to a kernel clone repository; suggestions will be welcome. The driver is working already, but currently you can just use the sensor as a normal WebCam.

About the Kinect

The Kinect sensor is a device used by Microsoft for its Kinect project, which is a system for controller-less Human-Computer interaction firstly targeted for Xbox 360, but rumors say MS could be integrating this technology into its future operating systems; the hardware is only part of the system of course, the software does most of the interpretation work figuring out how many users there are and assigning a meaning to their actions.

Great part of the Kinect communication protocol has been already figured out, thanks to the adafruit people who dumped the communication stream with the Xbox using an usb bus analyzer, and to Héctor Martín Cantero (marcan) who started analyzing the trace for the libfreenect driver. Marcan is also the guy who won the adafruit bounty for a kinect opensource driver, and the one behind AsbestOS. All these efforts have flowed into the OpenKinect project, wisely guided by Joshua Blake.

For an overview about the hardware you can see the IFixit teardown, the part I am interested in for now is the integration of the video capturing sub-device which provides what is usually called RGBD data (Red, Green, Blue, Depth), the Depth component gives spatial information about the captured scene, easing out the process of image segmentation. Just to give an idea, background subtraction is one step of the segmentation process, and can be achieved quite robustly with techniques like Depth keying (the spatial version of Chroma keying). But I am really not an expert in this area.

In the Kinect device, RGBD data is captured from two distinct sensors: a regular RGB sensor and a monochrome sensor which, with the aid of a IR structured light, captures what is finally exposed as a depth map; so what we have is basically a Structured-light 3D scanner.

Kernel driver development

I don't know yet if the gspca driver is going to define two video devices, one for each sensor, or if a combined format would be preferred, I am asking for advice from others more expert in this field.

This is the plan:

Follow the discussion on the OpenKinect mailing list or on linux-media.

Thinking outside the (X)box

Ah, don't forget to check out all the fancy stuff people are doing with this toy.

06 Dec 2010 9:12pm GMT

02 Nov 2010

feedPlanet OpenEZX

Antonio Ospite: Bug hunting in Linux kernel land: an unpretentious primer

Lately I've been fixing some defects in the hidraw interface in the Linux kernel (commits d20d5ff and e42dee9), simple issues like these NULL pointer dereference are a good example to show how to analyze a Linux bug trace in order to spot the defective code. So let's take a look. The steps to fix any defect are basically:

  1. reproduce the problem (a quick introduction to the concept of "Observability" of software faults is in: Dissecting The Bug)
  2. find the offending code/policy
  3. elaborate a solution
  4. implement and test the solution is working

Reproducing the problem

If the problem is in some userspace/kernelspace interface then writing a test program which triggers the bug may be the quickest way to reproduce it. The test program should be as simple as possible, doing the minimum required to expose the defect, as it will be used also as a proof that the bug has been solved in the right way; just like when proving a theorem we don't want to have more hypotheses than are necessary. The test program for one of the issues above looks like this:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

#include <linux/hidraw.h>

int main(int argc, char *argv[])
{
        int fd = -1;
        unsigned char report[2] = {0x01, 0x00};
        int ret;

        if (argc != 2) {
                fprintf(stderr, "usage: %s </dev/hidrawX>\n", argv[0]);
                exit(1);
        }

        fd = open(argv[1], O_RDWR);
        if (fd < 0) {
                perror("hidraw open");
                exit(1);
        }

        while (1) {
                ret = write(fd, report, sizeof(report));
                printf("ret: %d\n", ret);
        }

        close(fd);
        exit(0);
}

That gives me the occasion for an observation about one aspect of testing procedures: as you can see the test program above uses deliberately some bad practice, namely it does not check the return value of the write() call in order to exit the while loop; we know this is generally bad from a programming point of view, however it turns out to be good from another point of view: bad programs can spot cases we didn't think of in our code paths; it goes without saying that this is no excuse for "uncontrolled" bad practices, nor for the bug we had in the first place :).

Anyhow, the code above exposes the defect on kernels up to 2.6.35, just run the program and unplug the (USB) device (a Sony Sixaxis in my case):

BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
IP: [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]
PGD 37082067 PUD 3701f067 PMD 0 
Oops: 0000 [#1] SMP 
last sysfs file: /sys/devices/pci0000:00/0000:00:04.0/usb4/idVendor
CPU 0 
Modules linked in: hid_sony usbhid hid kvm_amd kvm powernow_k8 mperf cpufreq_powersave cpufreq_conservative cpufreq_stats cpufreq_userspace ipt_MASQUERADE lirc_serial(C) lirc_dev bridge stp ppdev lp sco bnep rfcomm l2cap crc16 tun sit tunnel4 binfmt_misc uinput fuse ip6table_raw ip6table_mangle ip6t_REJECT ip6t_LOG nf_conntrack_ipv6 ip6table_filter ip6_tables xt_tcpudp ipt_REJECT ipt_ULOG xt_limit xt_state xt_multiport iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_raw ip_tables x_tables nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc hwmon_vid loop snd_hda_codec_nvhdmi snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi nvidia(P) snd_seq_midi_event snd_seq snd_timer snd_seq_device btusb bluetooth joydev snd edac_core shpchp video tpm_tis tpm evdev rfkill parport_pc parport tpm_bios pcspkr asus_atk0110 processor output edac_mce_amd soundcore snd_page_alloc i2c_nforce2 pci_hotplug k8temp wmi i2c_core button ext3 jbd mbcache dm_mod sg sd_mod sr_mod cdrom crc_t10dif ata_generic usb_storage ahci libahci pata_amd ohci_hcd libata ehci_hcd scsi_mod usbcore forcedeth floppy nls_base thermal thermal_sys [last unloaded: hid]

Pid: 4818, comm: test_hidraw_wri Tainted: P         C  2.6.35-ao2 #2 M3N78-VM/System Product Name
RIP: 0010:[<ffffffffa0f0a625>]  [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]
RSP: 0018:ffff880037081ee8  EFLAGS: 00010202
RAX: 0000000000000000 RBX: 0000000000000002 RCX: ffff880037081f58
RDX: 0000000100000000 RSI: 0000000000000008 RDI: ffffffffa0f128b0
RBP: 0000000000000001 R08: ffffffffa0f0a5ea R09: 000000000040087a
R10: 0000000000000000 R11: ffffffff81150c83 R12: ffff880037081f58
R13: 00007fff1b34cab0 R14: 00000000ffffffed R15: 0000000000000000
FS:  00007fa946870700(0000) GS:ffff880001a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000028 CR3: 000000005ad24000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process test_hidraw_wri (pid: 4818, threadinfo ffff880037080000, task ffff88006003e630)
Stack:
 ffff88005ad95000 00007fff1b34cab0 ffff880037081f58 00007fff1b34cba0
<0> 0000000000000000 ffffffff810ea46f 0000000000000003 0000000000000008
<0> ffff88005ad95000 00007fff1b34cab0 00000000004005c0 ffffffff810ea57e
Call Trace:
 [<ffffffff810ea46f>] ? vfs_write+0xa4/0x100
 [<ffffffff810ea57e>] ? sys_write+0x45/0x6b
 [<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
Code: 53 48 8b 47 18 48 c7 c7 b0 28 f1 a0 48 89 d3 48 8b 40 10 8b 68 58 e8 07 9a 3f e0 81 e5 ff ff 0f 00 89 ed 48 8b 04 ed c0 2b f1 a0 <4c> 8b 60 28 49 83 bc 24 50 1c 00 00 00 0f 84 af 00 00 00 48 81 
RIP  [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]
 RSP <ffff880037081ee8>
CR2: 0000000000000028
---[ end trace 06cb2d01ded47cc4 ]---

The most important info in this message is highlighted above in line two, that is:

IP: [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]

This tells us the last instruction executed, the one triggering the bug; the format is symbol_name+offset/symbol_size [module_name] as can be seen in mm/slab.c.

Finding the offending code

To find where the offending instruction is, we can disassemble the object code with objdump, here's the interesting function:

00000000000008e5 <hidraw_write>:
 8e5:   41 56                   push   %r14
 8e7:   41 be ed ff ff ff       mov    $0xffffffed,%r14d
 8ed:   41 55                   push   %r13
 8ef:   49 89 f5                mov    %rsi,%r13
 8f2:   41 54                   push   %r12
 8f4:   55                      push   %rbp
 8f5:   53                      push   %rbx
 8f6:   48 8b 47 18             mov    0x18(%rdi),%rax
 8fa:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi
 901:   48 89 d3                mov    %rdx,%rbx
 904:   48 8b 40 10             mov    0x10(%rax),%rax
 908:   8b 68 58                mov    0x58(%rax),%ebp
 90b:   e8 00 00 00 00          callq  910 <hidraw_write+0x2b>
 910:   81 e5 ff ff 0f 00       and    $0xfffff,%ebp
 916:   89 ed                   mov    %ebp,%ebp
 918:   48 8b 04 ed 00 00 00    mov    0x0(,%rbp,8),%rax
 91f:   00 
 920:   4c 8b 60 28             mov    0x28(%rax),%r12
 924:   49 83 bc 24 30 1c 00    cmpq   $0x0,0x1c30(%r12)
 92b:   00 00 
 92d:   0f 84 af 00 00 00       je     9e2 <hidraw_write+0xfd>
 933:   48 81 fb 00 10 00 00    cmp    $0x1000,%rbx
 93a:   76 25                   jbe    961 <hidraw_write+0x7c>
 93c:   65 48 8b 04 25 00 00    mov    %gs:0x0,%rax
 943:   00 00 
 945:   8b b0 c8 01 00 00       mov    0x1c8(%rax),%esi
 94b:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi
 952:   31 c0                   xor    %eax,%eax
 954:   41 b6 ea                mov    $0xea,%r14b
 957:   e8 00 00 00 00          callq  95c <hidraw_write+0x77>
 95c:   e9 81 00 00 00          jmpq   9e2 <hidraw_write+0xfd>
 961:   48 83 fb 01             cmp    $0x1,%rbx
 965:   77 25                   ja     98c <hidraw_write+0xa7>
 967:   65 48 8b 04 25 00 00    mov    %gs:0x0,%rax
 96e:   00 00 
 970:   8b b0 c8 01 00 00       mov    0x1c8(%rax),%esi
 976:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi
 97d:   31 c0                   xor    %eax,%eax
 97f:   41 be ea ff ff ff       mov    $0xffffffea,%r14d
 985:   e8 00 00 00 00          callq  98a <hidraw_write+0xa5>
 98a:   eb 56                   jmp    9e2 <hidraw_write+0xfd>
 98c:   be d0 00 00 00          mov    $0xd0,%esi
 991:   48 89 df                mov    %rbx,%rdi
 994:   41 be f4 ff ff ff       mov    $0xfffffff4,%r14d
 99a:   e8 00 00 00 00          callq  99f <hidraw_write+0xba>
 99f:   48 85 c0                test   %rax,%rax
 9a2:   48 89 c5                mov    %rax,%rbp
 9a5:   74 3b                   je     9e2 <hidraw_write+0xfd>
 9a7:   e8 00 00 00 00          callq  9ac <hidraw_write+0xc7>
 9ac:   89 da                   mov    %ebx,%edx
 9ae:   4c 89 ee                mov    %r13,%rsi
 9b1:   48 89 ef                mov    %rbp,%rdi
 9b4:   e8 00 00 00 00          callq  9b9 <hidraw_write+0xd4>
 9b9:   48 85 c0                test   %rax,%rax
 9bc:   41 b6 f2                mov    $0xf2,%r14b
 9bf:   75 19                   jne    9da <hidraw_write+0xf5>
 9c1:   b9 01 00 00 00          mov    $0x1,%ecx
 9c6:   48 89 da                mov    %rbx,%rdx
 9c9:   48 89 ee                mov    %rbp,%rsi
 9cc:   4c 89 e7                mov    %r12,%rdi
 9cf:   41 ff 94 24 30 1c 00    callq  *0x1c30(%r12)
 9d6:   00 
 9d7:   41 89 c6                mov    %eax,%r14d
 9da:   48 89 ef                mov    %rbp,%rdi
 9dd:   e8 00 00 00 00          callq  9e2 <hidraw_write+0xfd>
 9e2:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi
 9e9:   e8 00 00 00 00          callq  9ee <hidraw_write+0x109>
 9ee:   5b                      pop    %rbx
 9ef:   5d                      pop    %rbp
 9f0:   41 5c                   pop    %r12
 9f2:   41 5d                   pop    %r13
 9f4:   49 63 c6                movslq %r14d,%rax
 9f7:   41 5e                   pop    %r14
 9f9:   c3                      retq

The instruction we are interested in is at hidraw_write+0x3b which is at address 0x8e5+0x3b that is 0x920:

 918:   48 8b 04 ed 00 00 00    mov    0x0(,%rbp,8),%rax
 91f:   00
 920:   4c 8b 60 28             mov    0x28(%rax),%r12
 924:   49 83 bc 24 30 1c 00    cmpq   $0x0,0x1c30(%r12)
 92b:   

Now, how do we find the correspondent instruction in the source code? If we don't want to do that the hard way we can use the -S option of objdump like mentioned also in Documentation/BUG-HUNTING in the kernel tree, which interleaves source code with the disassembled listing, here's the excerpt we need:

        dev = hidraw_table[minor]->hid;
 916:   89 ed                   mov    %ebp,%ebp
 918:   48 8b 04 ed 00 00 00    mov    0x0(,%rbp,8),%rax
 91f:   00 
 920:   4c 8b 60 28             mov    0x28(%rax),%r12

So in this case the problem is that the code is trying to dereference hidraw_table[minor], but this entry could be NULL if we disconnect the device while performing the write() in a loop without checking return values.

Finding out the exact line could be a little harder when macros and inlined functions are used, but once we know how to deal with a simple scenario like the one proposed the complicated cases become someway doable too.

Elaborating a solution

The fix is trivial is this case: check the pointer is not NULL before dereferencing it, bail out otherwise.

Implementing and testing the solution

This is the actual patch which solves the issue:

diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
index 9eaf6ae..a3866b5 100644
--- a/drivers/hid/hidraw.c
+++ b/drivers/hid/hidraw.c
@@ -109,6 +109,12 @@ static ssize_t hidraw_write(struct file *file, const char __user *buffer, size_t
        int ret = 0;
 
        mutex_lock(&minors_lock);
+
+       if (!hidraw_table[minor]) {
+               ret = -ENODEV;
+               goto out;
+       }
+
        dev = hidraw_table[minor]->hid;
 
        if (!dev->hid_output_raw_report) {

Now, using the fixed hid module, if we run the test program again and disconnect the device we won't hurt the kernel anymore.

02 Nov 2010 9:18pm GMT

16 Oct 2010

feedPlanet OpenEZX

Michael Lauer: Towards the end of 2010

Howdy, dear reader!

It's been a while on this blog, mainly due to the fact that many short status updates are better twittered than blogged. Then again, as promised / threatened in last year's installment of this column, I had to spend most of the time this year with iOS development, rather than with FOSS - and it doesn't look like this will change much (you know, food and things…). Still I do care a lot about projects like OpenEmbedded, Vala, freesmartphone.org, and the like, so here's what has been going on this year:

OpenEmbedded (www.openembedded.org)

OE moved along quite well this year. I did not have much time for it - other than taking care about a couple of Vala and FSO recipes - but I'm especially pleased that the community finally embraced major clean up. Thanks to Frans, Richard, and all others involved, OE is improving heavily - although it wasn't easy: Over the last couple of years, the OE core contributors developed a resistance against any changes affecting more than a handfull of recipes, however in order to make OE handle even more contributors and various use cases, we had to do some substantial cleanups. This will reduce maintenance and improve the overall quality of recipes in OE, which is the #1 complaint I hear.

Vala (www.vala-project.org)

During the first half of the year, Vala went through some extremely tiring phases of non-activity, which improved vastly when its main developers opened up a bit, i.e. giving more developers access to the tree, adding branches, etc. There have been many changes in the Dova profile, but also the GLib profile has seen an incredible amount of work, bugfixes, some new features, and more.

The pace of changes that affect basic things had also impact on my vala-book plans; apart from a severe lack of time on my side, I think it's better to wait until Vala is closer to 1.0. Otherwise I risk describing a moving target, which - considering the time I have to work on that project - would effectively kill it. That said, it's great to see that Vala is getting better every day and gains more and more popularity from all kinds of developers.

FSO (freesmartphone.org)

The progress on freesmartphone.org is two-fold; on one hand, we have seen quite a nice amount of work to support more devices. On the other hand though, in contrast to all the work I did in 2009, there has been a severe lack of development of the core in 2010. This I plan to change as soon as possible. For 2011, I see myself continuing to develop FSO in the following three dimensions; internal, external, and integration.

  1. Internal | FSO is a heavy DBus consumer. I think by now we are one of the largest projects using DBus, at least considering the amount of API and running processes that communicate with each other via DBus. We always had our share of problems with DBus, especially some concurrency problems and race conditions are still haunting us. Both libdbus and dbus-glib exhibit their own share of problems, obviously this is not much of an issue on the desktop, but it turns out to be a major PITA on embedded systems, such as a phone. That's why I have been excited since I heard that the glib team planned to write their own DBus backend and put it right into the glib. This work has now been released as of glib 2.26. Over the next weeks, I will port FSO to using gdbus in a branch.
  2. External | DBus-signals have some problems. That's why some big projects (BlueZ and ConnMan, to name two of them) adopted an agent-style of API, where the clients have to implement a server API which is being called by the actual servers. While this means some more work for client developers, it has major benefits. I'm going to change some of our APIs to adopt this style.
  3. Integration | To deliver an integrated solution for today's mobile phones, FSO needs to add more glue to work with existing services, such as BlueZ (bluetooth connectivity), Connman (ethernet and wifi connectivity), and some VoIP services. While these services work fine on their own, FSO lacks an API that uses these individual services in combination to achieve higher level tasks.

All this means that I will not be working much on the actual ports, but rather use my - very limited, did I say that yet? - time to drive the core forwards. I still believe that we will have full FOSS phones - other than the Openmoko devices - soon. Please help to make this dream a reality. (And no, please don't talk to me about Android…)

Cheers,

:M:

16 Oct 2010 4:34pm GMT

21 Sep 2010

feedPlanet OpenEZX

Antonio Ospite: User-aware scheduling

Recently both OSnews and Slashdot pointed out some experiments about context-aware UIs done by Christian Giordano at Canonical (the company behind Ubuntu GNU/Linux), and the first results are somewhat interesting. As you can see in the good video demo from the original article the effects are nothing mind blowing, but they serve greatly to illustrate the concept, and by building on that something more useful would come out eventually.

That reminds me of another (never realized) old idea of mine from when I was attending the Operating System course at the university, I wanted to bind system responsiveness -at a lower level- to user presence, by tuning scheduler parameters according to the user being at his/her computer or not. Imagine a desktop computer which is encoding a video in background, when the user is interacting with the system then the interactive tasks must be more important, but when he/she leaves, then the system could assign to the background job all the resources it needs to run "at its best".

The parameters to change system responsiveness could be, just for instance, process niceness, swappiness (some report that less swapping results in more responsiveness, but I don't have numbers either to agree or disagree on that), or the whole scheduler could be changed on the fly if there is any system allowing that.

The mechanisms to detect user presence could be the usual: proximity sensors, video from a webcam or audio form a mic (humor alert), some measure of mouse and keyboard activity, a pillow/button on the seat (that would tell butt-on / butt-off... ehm).

In my original thoughts I wanted to detect when the monitor was manually switched off, that's because I usually switch it off when I leave the computer in order to save some power; on a laptop we have the lid button which could be abused, but I couldn't find a way to detect when an external monitor is turned off, anyone?

21 Sep 2010 8:01pm GMT

20 Jul 2010

feedPlanet OpenEZX

Antonio Ospite: Supercool Linux

We all know linux is cool, don't we? However these people at SuperFreddo make it supercool (freddo is the Italian word for cool/cold).

SuperFreddo logo

SuperFreddo is a frozen food chain here in Naples Italy, and the penguin in their logo has an interesting resemblance to Tux, the linux kernel mascot: the contour is not exact and it is wearing a hat and a scarf, but you just look at the feet -at their inclination- and you have no more doubts.

I am not on Facebook, so maybe some of you could point out to them where the designer of their logo could have taken inspiration from.
Could there be also a legal case here? I don't know.

I attach a couple of pictures of their shopping bags, just for the records, and to remind people that from 2011 plastic bags are banned in Italy.

Attached images:
SuperFreddo plastic bag
SuperFreddo plastic bag - detail

20 Jul 2010 9:42am GMT

04 Jun 2010

feedPlanet OpenEZX

Antonio Ospite: Write access to OpenEmbedded

Since late May 2010 I've been given write access to the OpenEmbedded repository.

Thanks to the OE devs who supported me.

04 Jun 2010 3:02pm GMT

27 May 2010

feedPlanet OpenEZX

Antonio Ospite: Neat compile/run cycle with git and OpenEmbedded

No matter how much careful we are when writing code, whatever changes we are making to a piece of software we must test them before production, even Donald Knuth once said: Beware of bugs in the above code; I have only proved it correct, not tried it. :).

Moreover, if the software we are working on is targeting an embedded system and needs cross-compilation and depends on other software, then testing can be more tedious: we have to prepare patches/archives and instruct the target SDK to pick our latest code, or we could code directly in the SDK working tree, but that would not be very clean. If you use git and OpenEmbedded there is a very neat way to build directly from our own working directory on the filesystem. By developing with git from the start, your changes are ready to be sent upstream as soon as they are proven to be OK.

Git cloning from filesystem

I am not going to repeat how nice, sleek and whatnot git is, just let me show you again how flexible it is: you can easily "re-clone" from a git clone on the filesystem, no need to have any servers around:

$ cd /tmp
$ git clone file:///home/ao2/Proj/EZX/OE/framework

See? By only using the file:// URI scheme we fetch from a git (working) directory: a git directory is a valid git repository, there's some beauty in this regularity.

Fetching the latest code from our git working dir with OpenEmbedded

OpenEmbedded uses the bitbake task executor, .bb files (called recipes) are used to describe bitbake tasks, they are generally used to define packages for distributing some software, and the source code of the software can be fetched in many different ways; in this case we are editing a recipe which uses the git fetcher, let's take a look at the original recipes/freesmartphone/frameworkd_git.bb:

DESCRIPTION = "The reference implementation of the freesmartphone.org framework APIs"
HOMEPAGE = "http://www.freesmartphone.org"
AUTHOR = "FreeSmartphone.Org Development Team"
SECTION = "console/network"
DEPENDS = "python-cython-native python-pyrex-native"
LICENSE = "GPL"
SRCREV = "93673aa09cafc8fb5cfc3cb4055a73e25e595b70"
PV = "0.9.5.9+gitr${SRCPV}"
PR = "r3"
PE = "1"

inherit distutils update-rc.d python-dir

INITSCRIPT_NAME = "frameworkd"
INITSCRIPT_PARAMS = "defaults 29"

SRC_URI = "${FREESMARTPHONE_GIT}/framework.git;protocol=git;branch=master \
           file://frameworkd \
           file://frameworkd.conf \
           "
SRC_URI_append_shr = "file://oeventsd-use-opimd-signals.patch;patch=1"

S = "${WORKDIR}/git"
...
...

we can change the path in SRC_URI to a directory on the filesystem, and change the protocol to file so that git uses our working copy to fetch the code for the package, we can also specify our development branch here. Note that we still have to use the git:// scheme, because that's what tells bitbake which fetcher to use.

diff --git a/recipes/freesmartphone/frameworkd_git.bb b/recipes/freesmartphone/frameworkd_git.bb
index dac7fe9..ddae81d 100644
--- a/recipes/freesmartphone/frameworkd_git.bb
+++ b/recipes/freesmartphone/frameworkd_git.bb
@@ -4,9 +4,9 @@ AUTHOR = "FreeSmartphone.Org Development Team"
 SECTION = "console/network"
 DEPENDS = "python-cython-native python-pyrex-native"
 LICENSE = "GPL"
-SRCREV = "93673aa09cafc8fb5cfc3cb4055a73e25e595b70"
+SRCREV = "${AUTOREV}"
 PV = "0.9.5.9+gitr${SRCPV}"
-PR = "r3"
+PR = "r4"
 PE = "1"

 inherit distutils update-rc.d python-dir
@@ -14,7 +14,7 @@ inherit distutils update-rc.d python-dir
 INITSCRIPT_NAME = "frameworkd"
 INITSCRIPT_PARAMS = "defaults 29"

-SRC_URI = "${FREESMARTPHONE_GIT}/framework.git;protocol=git;branch=master \
+SRC_URI = "git:///home/ao2/Proj/EZX/OE/framework;protocol=file;branch=freescale_neptune \
            file://frameworkd \
            file://frameworkd.conf \
           "          

Now we are set, we can build packages as usual and test our local changes on the target system:

$ bitbake -c clean recipes/freesmartphone/frameworkd_git.bb
$ bitbake recipes/freesmartphone/frameworkd_git.bb

27 May 2010 8:46am GMT

04 Apr 2010

feedPlanet OpenEZX

Michael Lauer: Joining twitter

I'm now on twitter. I'll use that for small status updates on the various open source related work I'm doing, e.g. FSO, OpenEmbedded, Vala, and the like.

Follow me, if you can :)

04 Apr 2010 2:59pm GMT

27 Feb 2010

feedPlanet OpenEZX

Michael Lauer: Qt suddenly got interesting again

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

08 Feb 2010

feedPlanet OpenEZX

Michael Lauer: F(SO|OS)DEM 2010

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.

Openmoko Devroom @ FOSDEM 2010

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

Openmoko Devroom @ FOSDEM 2010

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.

Openmoko Devroom @ FOSDEM 2010

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

03 Feb 2010

feedPlanet OpenEZX

Michael Lauer: FOSDEM 2010

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

01 Feb 2010

feedPlanet OpenEZX

Michael Lauer: fso-boot

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:

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