Planet OpenEZX
Planet OpenEZX| About Subscriptions Feeds |
January 18, 2012Antonio Ospite: On USB projectors, linux and libam7xxx
I was looking into compact/mini/pico/handheld projectors, and I obviously wanted something I could use under GNU/linux, there were basically two choices:
Since the first choice was more expensive and I verified that writing a driver for the second case wasn't too hard, I picked up an Acer C110, I paid it about 160 €, but you can find it even cheaper somewhere else, grr. AM7X or AM7XXXThe C110 is based on an Actions Micro AM7212P IC and uses USB bulk transfers with a simple packet based protocol on top to exchange data and commands to and from a host system and the AM7XXX chip. Other projectors using the same protocol are:
These projectors use the USB Vendor and Product IDs Some DPFs too (from Hannspree for instance) are known to use these chips but I don't know yet if they can be put in USB display mode. I will refer to these devices as either AM7X or AM7XXX devices. Open Source driver for AM7XXX devicesReto Schneider and I are reverse engineering the USB protocol used by these devices, using USB dumps and disassembling the Windows device driver, and a basic but already usable library to communicate with those AM7x based projectors can be found in libam7xxx. Reto was the first to start working on that, in the form of acerc11xdrv. So you can now get these projectors to work wherever libusb-1.0 works, that means you can use them with your phone if it can run GNU/Linux for instance, or even Android/Linux but I don't have an Android device to verify that. For now all the communication about the development is happening on the Side note: the user manuals of these devices sometimes refer to the functionality of displaying images over USB as Linux running ON other projectorsIncidentally, when I was doing my pre-purchase market research, I ran into several projectors which —unsurprisingly— are running a Linux system themselves (linux kernel, busybox, etc.), here is a summary of what I found out:
Open Projectors?Having the ability of processing an image before projecting it —either on an external system, or on the projector itself— opens up to a lot of possibilities, and I can foresee an increase of AR applications using projectors; so, do you think there is enough interest for an Open Projectors project? A place where we can share the techniques (keystone correction, or some more sophisticate anamorphic transformations by the means of a Camera-Projector system) and the Open Source software implementing them, all in a single place. Get in touch if you have any ideas about that. January 14, 2012Antonio Ospite: AOSP?
Every time I read AOSP in the news I think something is not quite right. Here is a faint attempt to set things straight —with some humor, don't take it too seriously—: here is aosp.it. And I don't even have an Android device... yet. But seriously, if anyone is interested in the aosp.it domain for some Android/Linux, Open Source related community site (maybe the very Italian one?), just let me know, I may be willing to concede it, if I decide not to start one myself. Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License Attached images:
 December 13, 2011Michael Lauer: IT has seen a crazy year
Information Technology has seen a really crazy year. Among all the smaller incidents, the big bangs involved Nokia partnering with Microsoft, abandoning Maemo, HP driving with WebOS against the wall, patent lawsuits everywhere. What that means for FOSS-lovers is clear… you can’t trust any company to continue working on anything. Business demands are what counts in the world of mass markets. If you want longterm support for a platform, your best bet is to build a community around it. But you will also want to work on hardware support otherwise you’ll run into the next dead end. To be honest, right now I don’t see much of a future for any mobile Linux-inspired platform other than the mutation called Android. But that’s not much of a problem per se. The smartphone market is crazy. To compete in that world, you have to give up on freedom. But is the mass market really what we want? Is it what mobile Linux needs? I don’t think so. There are still huge opportunities for using Linux-based mobile software platforms in niches such as machine2machine communication, home automation, research, teaching, and more. That’s where a service-based middleware like FSO comes into the game: for special interests. However, even niche-adoption is hindered without a minimal set of applications. And that is where we still lack: Even special interest people want to use their smartphones to manage contacts, browse the web, send mails, play media, etc. We don’t have an integrated software stack with a complete set of UI applications that would cover these needs. Openmoko worked on one, but failed. Nokia worked on multiple ones, but gave up (multiple times). What else do we have? With HP’s recent announcement about releasing WebOS as open source, the game may have changed. If we could use the WebOS application stack on top of the FSO middleware, we may have a real chance to get something great and usable – and complete – soon. I have always liked the WebOS UI. If it’s a bit slower than other UIs, who cares as long as it is free? December 09, 2011Michael Lauer: Towards the end of 2011
Tempus fugit. I can tell you. Even more so, if you have a baby. I must confess I somewhat underestimated the impact the baby would have on my spare time. In some weird mindset I really thought I could continue working as usual on my open source projects… as we know now I couldn’t. I completely lost track and have to catch up with all changes that happened over the last 6 months. The first bunch of weeks with the baby were really demanding. I mean, really. She screamed a lot and could only sleep in our arms. Boy, were we tired. We carried her around so much we have Schwarzenegger arms now. But it’s great to see her developing, err… growing up, of course. With 6 months now she is a very interested baby, eager to learn new things and always trying to become more mobile. Luckily both my wife and me are self-employed. It so much easier when you can skip some hours at the usual start of the workday and also at the usual end. Of course, the work needs to be done, so we have to compensate when she’s in bed. But still, it’s very satisfying being able to see her twice a day for a couple of hours — not all families have this luxury. Plus the existence of our two invaluable grandmas… it’s great. Company-wise, the Lauer & Teuber GbR had an amazing year with many interesting iOS (and some Android) projects. We have reached the maximum we can do with the two guys we are, so we decided to grow and hire our first regular employee who’s going to start in 2012. We also rented another office and are already moving. I’m slowly getting back into some of my beloved open source projects… it’s great that work on e.g. FSO did not stall at all, but continued while I was “away”. Last week, I attended the 3rd installment of the Open Hard- and Software Workshop in munich, where the latest development of the very promising GTA04 mobile phone was presented. I had a talk about Vala which was well received. By the way, my Vala-book plans are not dead yet… just in parking position Next week I’m attending the FSOSHRCON, a joined conference with the people working on the freesmartphone.org middleware and the SHR software. It’s going to be great seeing all the folks again, concentrating a full weekend to agree on some important issues laying the path forward for the next year. Can’t wait to be there. What’s left is the feeling that an extremely busy year has passed by, spiced with incredibly intense emotions. I’m a happy man and I love my life. I’m given exciting opportunities, but also challenges – and I plan to accept everything All the best to you guys! October 19, 2011Antonio 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 $ 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:
     Attached files:
June 09, 2011Michael 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
 May 30, 2011Michael 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. May 06, 2011Antonio 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:
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 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: December 06, 2010Antonio 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 KinectThe 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 developmentI 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)boxAh, don't forget to check out all the fancy stuff people are doing with this toy. November 02, 2010Antonio 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:
Reproducing the problemIf 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 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 Finding the offending codeTo 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 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 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 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 solutionThe fix is trivial is this case: check the pointer is not NULL before dereferencing it, bail out otherwise. Implementing and testing the solutionThis 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. October 16, 2010Michael 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.
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: September 21, 2010Antonio 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? July 20, 2010Antonio 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 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. 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:
  June 04, 2010Antonio 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. May 27, 2010Antonio 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: 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 filesystemI 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 Fetching the latest code from our git working dir with OpenEmbeddedOpenEmbedded 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
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
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 April 04, 2010Michael 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 February 27, 2010Michael 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! February 08, 2010Michael 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.
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. February 03, 2010Michael 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! February 01, 2010Michael 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:
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. January 05, 2010Antonio Ospite: Branding patches with git and vim
In linux kernel development there are informal, and yet quite solid, conventions which apply when sharing patches and collaborating during the —public and undisclosed— phase of code peer-review. As some of you may know, all the communications about kernel development happen via e-mail, and there are some tools to ease the task of preparing and sending patches; these tools allow some degree of customization, or “branding” like I am calling it in this case. Let's see how to decorate our patches so that their author is more easily recognizable (and acknowledgeable). Obviously all this doesn't apply only to linux, that's just where my experience come from. Let's step back to summarize a common work-flow used when preparing patches with the git SCM: # clone some repository git clone git://git.example.com/repo.git cd repo.git # create a new development branch and work on it git branch new-dev-branch git checkout new-dev-branch # Commit operation is inexpensive in git, use it $EDITOR fileA $EDITOR fileB git commit fileA fileB $EDITOR fileA git commit fileA # Prepare patches to be sent git format-patch -s --cover-letter master..new-dev-branch # Edit patches to: # - add Cc recipients # - add annotations after the '---' separator, # this does not interfere with commit messages $EDITOR *.patch git send-email --to "Some MailingList <some@mailinglist>" *.patch # When the patches are accepted upstream we can delete # our local development branch git checkout master git branch -D new-dev-branch Now, the patches we are producing this way have the author figuring as the sender, and are signed off according to the Developer Certificate of Origin, but we can still make them more “personal”, for instance we can:
Adding custom headersUsing the I am adding an X-Face header (the source image is attached at the end of the post):
X-Face: z*RaLf`X<@C75u6Ig9}{oW$H;1_\2t5)({*|jhM<pyWR#k60!#=#>/Vb;]yA5<GWI5`6u&+
;6b'@y|8w"wB;4/e!7wYYrcqdJFY,~%Gk_4]cq$Ei/7<j&N3ah(m`ku?pX.&+~:_/wC~dwn^)MizBG
!pE^+iDQQ1yC6^,)YDKkxDd!T>\I~93>J<_`<4)A{':UrE
To set this you can do: git config --global --add format.headers '' git config --global --edit and then add the string in double quotes, remembering to escape characters in the X-Face as git-config(1) Manual Page says:
Which in my case gives:
[format]
headers = "X-Face: z*RaLf`X<@C75u6Ig9}{oW$H;1_\\2t5)({*|jhM<pyWR#k60!#=#>/Vb;]yA5<GWI5`6u&+\n ;6b'@y|8w\"wB;4/e!7wYYrcqdJFY,~%Gk_4]cq$Ei/7<j&N3ah(m`ku?pX.&+~:_/wC~dwn^)MizBG\n !pE^+iDQQ1yC6^,)YDKkxDd!T>\\I~93>J<_`<4)A{':UrE\n"
Now the recipients can see my X-Face in my patches, provided that their MUA can decode it... Note: please don't copy and paste this X-Face blindly, this is my X-Face, you want to have your very own. Appending a signature to the cover letterIf you are using the Vim editor to compose the cover letter and annotate patches it is very easy to make it add your signature to the first mail in your patchset. Download my signature_block.vim into
" Append a signature block to cover letters generated with git-format-patch
autocmd BufRead 0000-cover-letter.patch silent call AddSignature('~/.signature') | w
autocmd BufRead 0000-cover-letter.patch autocmd! BufRead 0000-cover-letter.patch
Now the first time you open a file named Attached images:
 September 25, 2009Michael Lauer: GSM Palm Pre on the horizon
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. September 13, 2009Michael Lauer: Vala gains support for server-side async dbus
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! June 24, 2009Michael Lauer: LinuxTag 2009
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 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. February 17, 2009Michael Lauer: Catching up and plans for 2009
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.orgLet’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 DaemonModern 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): Here are examples of how you can use it (demonstrated within a Python shell):
fso-monitordWhile 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:
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. XeTexNext 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! ConferencesAlthough 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 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! December 27, 2008Michael Lauer: Visiting 25c3 for one day
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. June 12, 2008Stefan Schmidt: TechWeek in Vachdorf
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... May 22, 2008Stefan Schmidt: Talk and Radio Interview at the LinuxTag 2008
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. May 09, 2008Stefan Schmidt: SCM changes
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/ May 08, 2008Stefan Schmidt: Recent OpenEZX progress
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. Stefan Schmidt: OpenMoko Framework Initiative goes live
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. December 10, 2007Stefan Schmidt: Which wifi chip drives the Spectec SDW-82{1,2,3} SDIO cards?
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 November 15, 2007Stefan Schmidt: Navilock BT-451 under linux and navit
Bluetooth GPS reciever just rock. Small, easy to use, no cables and useable with different devices. Once my day-by-day gadgets and notebook have all one build-in I can get it of it, but that will take some time. So the toy is called BT-451 and has a u-blox ANTARIS4 SuperSense chip build-in. Getting it to work is easy: hcitool scan rfcomm connect hci0 After this you have a serial port (perhaps /dev/bluetooth/rfcomm/0) where all the NMEA data comes in. Just give this one to gpsd and you can use it in multiple applications. I also heard that this is even easier with gypsy. No more need to deal with rfcomm yourself. That screams for a test once it is in debian. There is some more stuff I like about the BT-451. Once it had a fix I was able to put it in a pocket of my jacket, sit in my car and it still gets the position. Tested with driving home with my notebook on the seat next to be and tracking the drive with navit. Daniel also discovered that the USB plug is not only for charging, but also shows up as ACM modem and spies out the NMEA on /dev/ttyACM0. And once connected via USB it also works without a battery. The above mentioned navit is one of the most promising stuff I like to use regulary with the GPS. It's a navigation system with a routing engine. Not only download maps and show them, but do real routing with vector based maps. As we all know maps are problematic. OpenStreetMap is working on this problem. Until this is useable everywhere I like to have some commercial maps I can route with on my linux system. Don't expect some vendor has got this ready. :( But FOSS has, as almost, an answer for me. Navit support different vector maps for commercial CDs. Just buy such one, copy the files and navit handles the rest. Great. No I just need to test the navit setup on my Neos. :) September 03, 2007Stefan Schmidt: Catching up with OpenEZX again
It's a long time since I really spent some hours on doing OpenEZX only work. A lot great stuff happened since then:
Motivated from all this great work Mickey and me spent more or less a full day with OpenEZX work. Catching up with the newest stuff and getting OpenEmbedded integration into an even better shape as it already was. (Thanks for koen on taking care of this most of the time). Besides this there was some ongoing work to make OpenMoko more useful on devices with QVGA screens. Based on the work Philipp Zabel we started an QVGA theme. Some artwork still needs a bit rework but it looks already pretty good. Mickey made some pictures and will link them from his on blog entry I guess. Once wyrm has merged the outstanding patches into the svn and we have done more work on the QVGA theme we will go for an snapshot release for with kernel and rootfs. Stefan Schmidt: Mobile Developer Days 2007 are over
Currently I'm with Mickey in a train back to Germany from Denmark. The last days I participated the Mobile Developer Days 2007. In contrast to the most other conferences I attend this one was not only about FOSS but more about developing software for mobile devices. Write applications in Python, Java, Open C, examples for location enabled applications, VoIP and rapid prototyping for artist are just a small extract of the program. Mickey and me gave our talks about Open{Moko,EZX} and presented the community view in discussions. Besides the different focus the event was also a lot smaller then the ones I usually attend. Around 40 people. So most of the attendees were speaker as well. Mixed up with the fact that many of the people are doing research in this area gave the conference a academic touch. In the last weeks Mickey and me pondered if we really should attend as our travel and working schedules are pretty full, we did not got plane tickets and had to go two 10 hours train rides, etc. In the end I'm happy we decided to go. Besides the talks especially the small group of people was a good place for interesting and informative discussions. Coming from the FOSS world and doing not much business besides OpenMoko it was quite interesting for me what people with a more commercial background are doing with mobile devices and what benefits and drawbacks they see in using FOSS for example. During the days and nights we had some working session with normal OpenMoko stuff but also some hours on catching up with OpenEZX stuff. But that's another blogpost. July 07, 2007Stefan Schmidt: Conferences ahead. Going to RMLL and GUADEC.
After having a busy time with university, OpenMoko and getting my partime freelance going I now are getting more relaxed and looking forward to the next two weeks which I will spend mostly on two conferences. Next week starts with my flight to France. I'm giving a talk about free software on mobile phones. It covers mostly OpenEZX and OpenMoko, but also tries to give an overview about other projects in this area. As my talk is at the first day I'm looking forward for the other talks, visit Amiens and doing having some time for OpenMoko related work. Coming back from France means having a half day and a night at home and jumping over to England again. GUADEC will be full of meeting people, having fun and making plans for the upcoming month. I'll fly together with Daniel and his girlfriend and meet up Mickey in Birmingham. But besides OpenMoko related discussions I really looking forward to meet people behind Gnome. December 04, 2006Harald Welte: My reason for being away from OpenEZX
This post should have been posted months ago, but only since very recently I'm allowed to talk about the real reason. You might have read about it, if you read my full blog, but I'm posting this again in the 'a780' category to make it appear on planet.openezx.org I've been hired to be key element in the design and implementation of the OpenMoko platform and the first device it supports: The Neo1973 phone. While there is no provision in the contract preventing me from working on the OpenEZX project at all, this assignment has just sucked up all available time like a vacuum cleaner. To OpenEZX developers, users and supporters: Please be assured that most of the work done on OpenMoko will eventually benefit OpenEZX quite a lot. So please stay tuned, and concentrate on the low-leve device-specific issues that need to be resolved with the Motorola EZX hardware :) September 15, 2006Harald Welte: A1200 LSM / SELinux update
James Morris got quite interested when I told him that the A1200 uses SELinux to lock out the users (owners!) from their own phone ;) So we both did some further analysis, and it turned out that Motorola had actually released the source code to their own policy engine (MotoAC) with the A1200 kernel sources on opensource.motorola.com, whcih is good. Still we didn't understand why you would use an unmaintained, at least three years old version of SELinux to base a forked policy engine on it - but obviously this is the world of Free Software and everybody is allowed to make his own decisions. I've also catched up with the A1200 in general and found out that people have already managed to flash their own kernel into it, whcih is great. I wish I had more time to put into OpenEZX at this point, turning it into something that is actually useful. HINT: Skilled volunteers needed. Pavel Machek apparently got one and is annoyed by the restrictive SELinux policies. By now I'm quite sure that it's not all too difficult to get rid of them ;) September 01, 2006Harald Welte: ROKR E2 Linux Phone review
There has been an extensive review of the Linux based Motorola ROKR E2 phone at osnews.com. August 29, 2006Harald Welte: Wanted: Author and/or sources for EZX "qonsole" application
The original author of the KDE "Konsole" program, Lars Doelle, is actively looking for the Author and/or the source code of the "qonsole" program, a terminal program for the Motorola EZX platform that is apparently derived from GPL licensed Konsole. Since the legal status of qonsole never was clear, I always refused to host it on any of the OpenEZX project resources. I didn't really know of any GPL violation going on, but had a somewhat strange feeling. If any of you has information on where the qonsole program originates, please make sure to inform either Lars or me about it. We know by now that it appears to originate from some chinese or singapore mobile phone forums. It's good to see more software authors of GPL licensed programs actually caring about enforcement of their license :) I sincerely hope this can be resolved and qonsole either distributed in gpl-compliant way, or a re-implementation be found/made. July 10, 2006Harald Welte: Motorola ROKR E2
I've found the ROKR E2, which is yet another Motorola Linux GSM/GPRS phone exclusively sold in china so far. Apparently since June 22nd, so it's a quite new thing. It's very different from the A7xx/E680x series in that it doesn't have a touch screen, but many more buttons. Also, it features a full-size SD card slot, which makes it theoretically SDIO compatible (I'm pretty sure they use some SDIO compatible SD host controller in there). Let's see whether I can work with the Chinese language firmware. I already found out how to get it into boot-loader flash mode (by pressing the camera button on the upper right side while powering the device up). It looks completely different than the blob on the A780/E680, but that doesn't really mean anything. As of now, I don't have any technical proof that the device runs Linux. I'll probably not find time to play with this toy before I get back to Germany. But if anyone has hints or further information on how to dig deeper into the ROKR E2, don't hesitate to send me an email about your findings. July 08, 2006Harald Welte: Motorola A728 and A732
Just next to my hotel, there is a book store that also sells mobile phones. Among the Motorola models are the A728 and A732, both Linux based. They're about 160EUR each. I don't yet know whether that is a good price, but now after checking with some online shops I think it is. So I guess I'll get one of each in order to investigate whether we can hack them from an OpenEZX point of view. Also, this finally allows me to obtain proof whether they're still shipping GPL incompliant or not. I'll continue to look for an A768 and E895. Let's see whether I'll find some time to do some more serious 'shop browsing'. June 23, 2006Harald Welte: Some small A780 progress
I've continued my work on porting the ts07.10 from Motorola's mux_cli to 2.6.x. It now compiles, although I have no idea whether it actually works as expected. Since Linux 2.5/2.6 has undergone quite some sophisticated changes in both scheduling/context area (no more struct task_queue) as well as the tty layer (dynamically allocated and managed flip buffers, etc), the task has been a bit more challenging than the usual copy+paste+minor_fixup task. I'll also be releasing the -ezx6 kernel soon (2.6.17 based) in the next couple of days, where I plan to merge mickey's various driver bits (LED, backlight, keypad fixes) and the above-mentioned mux_cli. June 12, 2006Harald Welte: Interview on OpenEZX at LWN.net
For those interested, lwn.net is featuring the first part of an interview withe me on the status of the OpenEZX project. The way longer pert of the interview on gpl-violations.org will be posted within the next two weeks. Now let's hope that I'll be able to fix that nasty netfilter bug that I'm hunting for weeks now and get back to OpenEZX kernel hacking... June 07, 2006Harald Welte: Not working on OpenEZX at the moment
Due to lots of other "real life" and "real work" constraints, I'm not able to work on OpenEZX for at least another week :( May 27, 2006Harald Welte: Porting Motorola's TS07.10 MUX driver to 2.6.x
Since Motorola has finally released the source code for the mux_cli.o and gprsv.o modules of their 2.4.17 kernel on opensource.motorola.com, I've started to clean them up and port them to 2.6.x. Due to the questionable coding style of that original source code, and the many interface changes in the TTY layer between 2.4.x and 2.6.x, this turns out to be a bigger task than expected. With some luck, I'll find some time tomorrow at ph-neutral to finish the initial port. Once that code works on 2.6.x, I already have a quite long list of TODO's. First of all, the lower-layer interface needs to be cleaned up. Ideally, the whole TS 07.10 implementation is a TTY line discipline that can be stacked on top of any UART, together with a virtual/fake UART that makes use of the Motorola specific TS07.10 USB transport. May 19, 2006Harald Welte: Touch-screen driver for A780/E680, lots of other progress
As of today, the OpenEZX project has a working touch screen driver. I've been testing this with the Kdrive X11 server of OpenEmbedded, and it seems to work nicely on my A780 after calibrating with ts_calibrate. This is such a major step forward, since the touch-screen driver requires a functional PCAP2 driver, which in turn comprises working SPI support, as well as some tricky SPI-during-hardirq for interrupt chaining. If you're interested in giving it a try, there's the the -ezx6 quilt patchset including all this work. Also, thanks to the work by Michael 'mickey' Lauer, I've managed to set up an OpenEmbedded environment to build a distribution for OpenEZX. You can find the first bunch of packages as well as a root filesystem that you can put on TransFlash on my OpenEZX developer pages. The availability of a OE based root filesystem, a kernel with keypad, touch-screen, usbnet and framebuffer support actually means that all the [G]UI people can now start to work on making their favourite UI system work on OpenEZX. Given the amount of interest I've seen in this area, I'm confident that I still don't (yet) need to dive into UI development myself but can stay with the more technical low-level stuff. Speaking of which, I've also hacked a nice tool called gpiotool, using which you can read/write GPIO configuration as well as individual GPIO pins from userspace. If I had written this earlier on, it would have saved a lot of time and hassle. But then, it's always hard pushing yourself to develop code that _just_ aids development and doesn't really add any functionality itself. Using this tool I'm now investigating the AP/BP interaction (handshake). Let's hope that we can actually use the phone as a phone really soon. May 15, 2006Harald Welte: Motorola launching opensource.motorola.com
Motorola seems to be making some progress internally. Today they've announced the availability of opensource.motorola.com, a web site dedicated to free and open source software used and developed in/by Motorola. This is apparently also the portal where they are starting to publicize the source code for their Linux based Smartphones. While the source code there is not complete in any way [yet], it actually includes the kernel sources for the A1200 phone, too. After a quick read through it, it seems to be very similar to the A780 code (because of a very similar hardware architecture). Some of the differences are:
May 14, 2006Harald Welte: A full day of EZX driver development
Today wasn't exactly the most efficient day of development I ever had. Basically, the amount of progress made after 13 hours of hacking in the area of EZX device drivers is extremely slow. It didn't even help to not eat, not cook, and not get out of the bed for the whole day. Basically I started with "let's fix this quickly before breakfast", but it wasn't fixed even when I stopped working at 11pm. My new SPI driver seems to be working fine, but I have massive problems with all the PCAP drivers. This is mainly touch-screen, but also ADC for reading battery voltage, etc. Somehow I cannot get it to produce any IRQ's. May 12, 2006Harald Welte: Debian sarge root filesystem image for EZX phones
In order to get other developers going quickly, I have now provided a Debian sarge (arm) root filesystem and a corresponding kernel plus instructions. Anyone who wants to see a stock Debian installation boot on his EZX phone, have a look at the files published here. May 11, 2006Harald Welte: OpenEZX virtual host running
I've finally found the time to configure the OpenEZX virtual host. This means that I now have absolutely no problems to hand out developer accounts on openezx.org. I've also moved the EZX related subversion repository from gnumonks.org to this machine. If you're working on free software for Motorola EZX smartphones, and are interested in getting some account where you can host your project(s) in svn / git, dump some code on http/ftp or just want a openezx.org email address, please let me know. Harald Welte: Working on Bluetooth and GPRS/GSM support
I've been working a bit on getting Bluetooth and GPRS/GSM support into my 2.6.x based kernel for the A780. Both are quite a bit challenging, even more than I initially thought so. As for Bluetooth: In theory there is a bcm2035 chip, compatible to the Bluetooth HCI specification, attached to ttyS1 (BTUART) of the PXA270. However, there are some power management related additional signals hooked up to GPIO signals. I think I'm configuring them right, though. Also, there is some indication that the bcm2035 actually requires a bit of firmware loaded into it. Without a vendor data sheet and with only some stripped proprietary Motorola dload program this will require quite a bit more of investigation. My initial 'demand' for Bluetooth would have been the possibility to use my Apple BT keyboard with the framebuffer console, providing a local console in case telnet dies for some reason. On the GSM/GPRS front (yes, we actually want to use the phone as a phone sometimes), I've been wading through disassembled gprsv.o and mux_cli.o code. Both re-implementations are progressing slowly, but steadily. The easier part seems to be mux_cli.o. I've now started to write some libusb based userspace code to test a ts07.10 implementation in userspace via the USB endpoints to the BP. Once the userspace code seems to be working, I can work on a kernel level implementation. The good thing about this is that there are actually quite a few GSM phones that support this multiplex on their serial port. So the resulting mux/demux driver will actually be useful for more people, not just Motorola Linux smartphone owners. April 29, 2006Harald Welte: A780/E680: SPI driver using hardware SPI controllers working
So apparently there is no obvious reason for Motorola's driver using bit-banging rather than the controllers inside the PXA270. I now have a modified Motorola driver on 2.6.16.5 running that uses the SPI controller for the bus to PCAP2. Getting my own driver running should therefore be quite fast now. I've also hacked a bit on the keyboard side, although it's not working yet. April 27, 2006Harald Welte: Working on new SPI/SSP drivers for OpenEZX kernel
One of the fundamental interfaces on the Motorola EZX phones is SPI, which interconnects (among others) the PCAP2 peripheral with the PXA270. Motorola ships their 2.4.20 kernel with some ugly piece of spaghetti code driver for it. Apparently they've had difficulties driving the PXA27x SPI controller, and in the end decided to just 'bit-bang' the signals over GPIO. Obviously that's inefficient and CPU-intensive. I hope there is no real hardware problem preventing the use of the embedded SPI controllers. First I started writing a driver against arch/arm/mach-pxa/ssp.c, only to discover later that this code actually predates (and therefore doesn't use) the generic drivers/spi/ interface. Since I'm a fan of generic interfaces, I chose to write a PXA generic driver for the drivers/spi interface, plus some EZX specific glue code for it. One of the interesting bits is that the PCAP2 can interrupt the PXA, and it then acts as an external interrupt controller, whose registers you can access over SPI. So a PCAP2 interrupt can mean that some touch-screen event happened, that the headphone, USB or microphone jack state has changed, etc. All those various real interrupt sources need to be fed to individual distinct drivers (audio, touch-screen, USB). The Motorola kernel uses an ugly kludge of callback functions that those drivers can register with the SSP/SPI driver. So in my new driver, I choose to actually model that bit of PCAP2 functionality as an external interrupt controller. This way the actual sound/touch-screen driver can just do request_interrupt() like they usually do. However, this means that I need to access SPI from within hardirq context, which again doesn't mix well with the architecture of the drivers/spi code (which is asynchronous and queues requests). So I need to implement a couple of synchronous SPI functions in addition to that. This is now a lot of code, and I'm about to test and debug it, which is expected to be time-consuming and boring. I'll post a status update as soon as there's more information. April 22, 2006Harald Welte: OpenEZX: USB Ethernet support working
After lots of hacking at FISL 7.0 in Porto Alegre, I've managed to get the PXA27x USB device controller to work in USB Ethernet emulation to work. I can now actually ping and telnet to the 2.6.16.5-running E680, using a debootstrapped Debian/ARM on SD-Card. I'll publish the patches in one or two days, when everything has stabilized a bit, and the debugging code has been removed. Also, at the event here, I've managed to convince quite a number of Free Software people that those Linux smartphones are actually quite interesting toys. Most notably, Keith Packard of Xorg fame has indicated he would probably be getting one and working on a lightweight UI. This motivates me even more to have a stable and fully working kernel environment finished soon. April 17, 2006Harald Welte: State of OpenEZX 2.6.x kernel development
During my two days of EZX phone hacking, I've made significant progress. Probably the most important discovery was how to get a serial console on the USB plug, enabling other people to do further kernel development without physically modifying the phone - but it's still a long way to go. A current list of TODO's:
So why am I stating this here? Because it's up to _you_ to help and take care of one of these tasks if we want to see the dream of having a fully-free software E680/A780 before they get phased out ;) Harald Welte: 2.6.16.5 boots on EZX phones
I've finally managed to get a 2.6.x kernel running on the Motorola A780 and E680. Apparently the problems I encountered are part of 2.6.14 (which was current mainline when I started the port). After merging my patches into 2.6.16.5, everything suddenly worked fine ;) So what I've got now:
The main obstacle now is that TransFlash on the A780 is not working yet. The A780 is actually more important than the E680. For some strange reason, all the response bytes from the TF card appear to be zero (at least that's what the response FIFO of the PXA27x embedded SD/MMC controller reports). I've already tried a lot, but am a bit clueless after many hours of trial and error :( April 16, 2006Harald Welte: Running a serial console on the A780
After about half a day of trial and error (which was related to a totally different problem, as it turned out), I now have a 2.4.20-based kernel with working serial console for my A780. Unfortunately the console requires soldering four wires onto test pads of the PCB - something that I achieved with 0.1mm diameter magnet wire (Kupferlackdraht for you Germans). The magnet wires are thin enough to get them through the TransFlash slot to the outside, without having to modify the case. If you're interested in a bootup log captured from the STUART, check this one. The rest of the day was spent debugging why my (still 2.6.14 based) kernel doesn't want to boot on the machine. As it turns out, booting stops somewhere in the early initialization after head.S has called decompress_kernel(). Debugging this problem has also caused me to actually write some ARM assembly code. For years I'm reading and debugging ARM code, but I've never actually written ARM asm from scratch. So my assembly code now prints one character for every stage of the booting process (ABCDEFGHI) and then stops. At the time the C code should print its first character, the device is already gone. So maybe something with the setup of the registers according to C calling convention, or setup of stack/heap is erroneous. Interestingly, that startup code has not really changed all that much from 2.4.20 (which runs) and my 2.6.14 based kernel. It's not unlikely that I'm [again] hunting a totally different problem. I'll probably merge my patches into 2.6.17-rc1 and see whether that works... April 11, 2006Harald Welte: Obtaining Asian Motorola EZX phones in Europe
A couple of days ago, I was looking for a way to obtain Motorola Linux Smartphones in Europe, i.e. those plenty of models that are not officially sold anywhere but China and other areas of Asia. I've now found a suitable importer specialized in importing Asian phones into the European market. In case you're interested, feel free to contact me for more details. The phones range between EUR 180 and EUR 300, but there's a minimum order of five phones. I'll probably be ordering around early may. April 08, 2006Harald Welte: planet.openezx.org launched
In the tradition of my main project netfilter (which has a planet.netfilter.org, I've now also opened a planet site for the OpenEZX project at planet.openezx.org. This should give users the ability to stay up to date with current developments in the Motorola Linux smartphone hacking community. If you know of any feeds that I should add to this planet, please let me know |
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.