We have been busy in the past two months, and now it’s time to open up our code. Please keep in mind that most of these projects are not in the release state yet, but subjects of ongoing development.

You can find all of our source code at: http://gitorious.org/+0xlab. Here is a brief introduction of each project:

1. MadButterfly: a git clone of the original project. The real project is hosted at assembla. MadButterfly is very likely to be the base of our 2D UI framework. It’s based on SVG instead of traditional toolkits such as gtk or kde, so it will give the UI designer a lot of space to unleash his/her creativity. The main developer’s (Thinker) blog is here.
2. Android Eee PC: it aims to ease the porting of Android to Eee PC. At the moment the most interesting thing is the 3D acceleration structure on it, which can use the existing hardware driver in Mesa. Check this video to see what it can do. (blog)
3. 0xlab’s Linux Kernel Tree: it contains several branches for different platforms, like Omap3, SMDK6410, and may be more in the future. Also, all of them are intended for being able to boot into Android. We tend to use the Beagle Board (OMAP) as our main development platform because it’s cheap and open.
4. esuit: the Embedded System Unit/Integrated Test cases framework. It aims to provide a unified method to verify the functionalities of a hardware platform. This project is in planning phase, so no source code is available yet.
5. android obex: it provides obex file sharing in Android. (blog)

From now on, we will direct all of our technical discussions to the 0xlab-devel mailing list. Plus, IRC #0xlab is the place we usually hang out. If you want to reach us directly, mail us.

I will join the OESF (open embedded software foundation) progress conference on 6/24. Although the name suggests similarities to OpenEmbedded, this foundation has nothing to do with OE, but focuses on Android development. I’m not sure if it’s a member of OHA since I can’t read Japanese and Google Translate is very vague on this.

It’s a bit old but I’ll share it anyway. The content is in traditional Chinese.

Well, I gave this built-in webcam a try today. `Cheese’ does show the image, but it’s upside-down.

A quick lsusb shows
Bus 002 Device 002: ID 064e:a116 Suyin Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 147e:1000
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

It’s obviously 064e:a116, so I googled it, and this turns out:

This camera module is known to be mounted upside-down in some notebooks. There is currently no documented way to rotate the image at the device level. If you don’t mind holding your computer upside-down, the camera should work fine.

WELL, if I hold my notebook upside-down, my LCD will also be upside-down, so the video I see will still be upside-down, no ?

Android porting development kit could be obtained by

make pdk pdk_all

in your top repo dir. You can find the pdk doc in out/target/common/docs/online-pdk . If you open index.html directly you will find the css is all messed up. The quickest way might be moving the directory to /var/www, install one web server (I use thttpd) then open http://localhost/online-pdk/ .

The document is far from complete but it’s still a good reference to save a lot of time.

I’m quite disappointed about the unicode support of emacs22 so I decided to give emacs23 pretest a try. It turns out to be quite nice but it doesn’t include Debian’s debian-startup.diff patch and I don’t want to add it to the source code. So, I decided to solve it in my .emacs file. Here is the related script:

;; hacks to use debian emacsen in emacs23
(if (not (string-match "^23." emacs-version)) nil
  (setq load-path
;; more paths could be added here
	(append (list "/usr/share/emacs/site-lisp"
                      "/usr/share/emacs/site-lisp/global") load-path)
	)
  (defconst debian-emacs-flavor 'emacs22
    "A symbol representing the particular debian flavor of emacs running.
Something like 'emacs21, 'xemacs21, etc.")
  (load-library "debian-startup")
  (debian-startup debian-emacs-flavor))

And I also realized the GUI version of emacs doesn’t bring me any good then the console version, so I’m running it without X now. Much easier to use.

> /home/john/usr/lib/python2.6/site-packages/planet/feedparser.py(2699)parse()
-> result['feed'] = feedparser.feeddata
(Pdb) p result
{'feed': {}, 'status': 200, 'updated': time.struct_time(tm_year=2009, tm_mon=5, tm_mday=30, tm_hour=18, tm_min=20, tm_sec=46, tm_wday=5, tm_yday=150, tm_isdst=0), 'version': None, 'encoding': 'UTF-8', 'bozo': 0, 'headers': {'x-nananana': 'Batcache', 'transfer-encoding': 'chunked', 'content-encoding': 'gzip', 'vary': 'Cookie, Accept-Encoding', 'server': 'nginx', 'last-modified': 'Sat, 30 May 2009 18:20:46 +0000', 'connection': 'close', 'etag': '"6d6a931c57ea74fb68476ac28bb7a24c"', 'cache-control': 'max-age=300, must-revalidate', 'date': 'Sat, 30 May 2009 18:20:46 GMT', 'x-hacker': "If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.", 'content-type': 'text/xml; charset=UTF-8', 'x-pingback': 'http://asleepfromday.wordpress.com/xmlrpc.php'}, 'etag': '"6d6a931c57ea74fb68476ac28bb7a24c"', 'href': 'http://asleepfromday.wordpress.com/category/0xlab/feed/', 'entries': []}

If you’re reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.
Hey, I was just trying to fix planet feed reader…

We have been receiving a lot of emails asking about what 0xlab is doing now, and exactly how to cooperate with us.

First of all, we have been fairly busy recently. If you have tried to port Android to other platform, then you will know it’s not an easy task. We have some familiar porting issues, such as the documents provided by hardware manufactures are either vague or incomplete, the BSP is outdated (ancient), code is a mess or even completely unusable. And we also have some new issues, such as Android platform’s big code base and lack of proper document (I’m talking about lower level here), or what Goggle said in their presentations is way different then what’s in the code, and I don’t even want to start with many hard-coded assumptions about hardware (G1), etc.

Rant aside. What’s been keeping us busy:

• Port several wireless modules to several popular platforms.
• Graphic acceleration.
• Multimedia enrichment. (Reads: port other open source codes)

I’m not going to dive into details here. We will do a code drop sometime in June, and our members will blog about their work, so the technical details will be revealed then. We will also open up our development mailing list, so people can discuss there.

Next question is: how to join force? The answer is quite simple: just like any open source project. After the code drop, try it out, report bugs, send us patches, join mailing list, talk on the IRC (#0xlab), etc. – all the usual stuffs. That also means we won’t work on any specific product. So, if you’re interested in developing android based product, send your *own* developers to join and grow with us.

Now, advertisement time: join FreedomHEC Taipei, Matt and Jserv will talk about bootloader there.

The guys at Google just created a whole new definition to the term `collaboration’…

It turns out doxygen can be quite handy if you want to read android code. It supports javadoc style, so it could generate documents for the java files. It supports qt style, so the c++ code is also taken care of. Inheritance diagrams, integration with gnu global, etc. are quite useful as well.