dsd’s weblog

Since starting at One Laptop per Child I have been doing some distro work on the OS platform for the XO laptop. The platform is based on Fedora 7 and I have been working on rebasing us onto Fedora 9 for the next release.

Having very little distribution experience outside of developing Gentoo for the last few years, I’ve found some aspects of Fedora’s binary package (RPM) workflow particularly interesting:

1. Automatically detected dependencies: In Gentoo ebuilds, we have to state that package A depends on library B. In Fedora, when building the binary package, the build tools determine many runtime dependencies automatically so there is no need for developers to manually list all dependencies in spec files.
2. Chroot build environments: All packages are built in an otherwise-empty chroot. The build system creates a chroot, quickly installs all of the base binary packages and the build dependencies, then builds/installs a package, produces a package, and throws the chroot away. This allows for predictable build environments and is good for QA.
3. Community access to the build box: All packages are built by Koji. Koji has a nice “scratch-build” system where you can throw a source RPM at it, and it will build it and serve it back to you on a webpage a few minutes later. Great for build testing and handy if you don’t have a complete build environment locally. The scratch-build service is open to non-developers assuming they have been through the click-through contributor agreement.
4. Subpackages: It’s pretty neat how one spec file (equivalent to an ebuild in some ways - textual build scripts) can actually produce several packages. Your spec file takes one upstream tarball, unpacks/compiles/installs it, and then specifies which of the installed files belong to which subpackage.

Naturally, there are some drawbacks too:

1. Build dependencies: Even though many runtime dependencies are automatically detected, you still need to specify the components required for compilation. Remember, each package is built in a clean chroot. You end up having to specify most of the dependencies anyway (although it is still convenient in that you do not have to specify which subpackage has which dependencies - that is determined automatically).
2. No build customisation: OLPC have to fork a few packages which have wacky dependency chains, just to disable support for a certain feature or whatever. Forking away from upstream is undesirable but sometimes necessary. For example, we had to disable libgnome support in GNOME’s Python bindings to avoid libgnome being pulled into the build. libgnome was pulling in the following packages: audiofile bluecurve-icon-theme control-center-filesystem esound-libs fedora-gnome-theme fedora-icon-theme fedora-logos gail gnome-icon-theme gnome-keyring gnome-themes gtk-nodoka-engine libart_lgpl libbonoboui libgnomecanvas libgnomeui libutempter metacity nodoka-metacity-theme pyorbit. Ouch.
3. Convolution/confusion of build tools: To build a package, you can use rpmbuild to do it on your live system, or you can use mock to do the clean chroot thing I described above. Or you can use koji’s command-line client to upload it to koji. Not everything can be done through koji/mock, e.g. you still need to use rpmbuild to build OLPC’s kernel. Also, rpmbuild is the only tool that can build a source RPM, I think.

I’ve also been impressed by the Fedora development community. The community recently made the realisation that OLPC is Fedora’s biggest deployment (over 400,000 XO laptops worldwide, 55,000 more built and distributed each month, 100% of them running Fedora). Greg Dekoenigsberg recently announced the Fedora OLPC special interest group which sounds promising.

As part of my fprint fingerprint scanning on Linux efforts, I have completed a new driver for a popular bit of hardware that has been unsupported on Linux until now: the UPEK TouchStrip sensor-only variant with USB ID 147e:2016.

We have already supported another variant including a biometric co-processor for some time now, but in the absence of the co-processor, the sensor-only variant required a completely different driver. Support for the sensor-only devices is a significant step forward as this hardware can be found in a lot of laptops. I’ve already received some success reports - thanks!

The driver is only available in libfprint development repositories (not any released versions). System76 have created an installation guide which may be useful for keen users.

I’ve just released a new development version of libusb-1.0. It incorporates all the feedback I’ve received from the v0.9.0 release, and includes some API changes, so be sure to update and recompile your apps if you were previously using v0.9.0.

Download links:

• libusb-0.9.1
• libusb-compat-0.1.0-beta2

Last week, I took my final exam for my BSc Computer Science degree at The University of Manchester, results pending. I was originally planning to graduate with a masters degree a year from now, but because of some political brain-damage at university, I ended up switching to the shorter degree so that I can take up a great opportunity this summer:

Today was my first day of a 14 week internship at One Laptop per Child, an exciting company producing cool laptops to distribute to children in developing nations with the aim of improving education. I’m going to be working on aspects of the XO software, starting by helping the efforts to upgrade to Fedora 9 for the v8.2.0 August release.

OLPC is based in Cambridge, MA, USA, and this is my 2nd time in this area. I’m living in Brookline until September, and then will need to find somewhere else to live for a month.

My plans for after the summer are uncertain. I’m thinking about hunting for some work in Europe somewhere, I might write more about that nearer the time.

I’m looking to find someone to take over some part-time contract work that I’ve been doing. I’m only stopping as I am about to start some full-time summer work.

The project is Linux driver development for a PCI frame grabber. Kernel experience is essential, and the important areas of knowledge are PCI and DMA. Location does not matter, this is a remote development project.

If you’re interested, or know anyone that might be, please drop me an email.

I’ve been making good progress on libusb-1.0, which has now entered beta. Features over libusb-0.1 include:

1. Asynchronous transfer capabilities (in addition to the synchronous style presented by v0.1)
2. Support for transfers to isochronous endpoints
3. Significantly faster bulk transfer performance for large transfers (several kilobytes or more)
4. Detailed API documentation
5. Power saving: on systems running recent Linux kernels, libusb-1.0 does not wake up all the USB devices plugged into the system during device enumeration
6. Greatly reduced CPU usage while waiting for results of bulk/interrupt transfers (libusb-0.1 was waking up every 1ms)
7. Thread safety

Backwards compatibility

As noted on the homepage, libusb-1.0 is entirely incompatible with libusb-0.1. However, it is designed to install in parallel, in the same way that you can have GTK+ 1.2 and GTK+ 2.x installed on the same system and in use at the same time.

I have also produced a compatibility layer which replaces libusb-0.1. libusb-compat-0.1 looks and smells exactly the same as libusb-0.1 (same library name, API, header file, etc) but internally it just converts libusb-0.1 calls to libusb-1.0.

This means that existing libusb-0.1 applications can take advantage of some of the new libusb-1.0 hotness mentioned above: improved bulk I/O performance, decreased CPU usage, power saving. These improvements appear without any modification to the original application, provided that the user has uninstalled libusb-0.1, and installed libusb-1.0 plus libusb-compat-0.1.

Status

I’m hoping this release will result in:

• More testing and adoption
• API review and feedback
• Ports to other operating systems. Only Linux is supported at the moment, but the library is structured internally for other ports to be written, and the internal API is documented in the source.

Further API changes may happen as a result of the above. This is not a finished product.

Source download

• libusb-0.9.0
• libusb-compat-0.1.0-beta1

My fprint fingerprint scanning efforts formed my final year Computer Science project at The University of Manchester.

The source code for this project has been available on SourceForge from early on (GPL-2/LGPL-2 licenses). I’ve now completed and submitted a comprehensive project report (similar to a dissertation) for academic assessment, and I’m making this available under a Creative Commons license. You can find the report here.

The report is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.0 UK: England & Wales License.

The academic project is now complete, but I plan to continue development as time permits. There is a lot to be done, and I have already made some good progress on moving libusb-1.0 closer to release.

Lorin Olivier also has a GL860 with a different USB ID (05e3:f191) in an Asus F5RL laptop. He had some success with my code but the images look to be in a different format when running my software. He’s contributed traffic logs from windows which I’ve put alongside mine in the git repository.

Simon (Sur3) also tried it with his 05e3:0503 device and got a seemingly different image format as well. He also took an image that came back from mine and decoded the Bayer colour space, so I can now get images back in colour!

It’s great to see other people getting involved in these efforts, as I will probably not be able to put much time towards this for a while.

More webcam hacking. I can get proper images now, minus colour. I’ve published my code: git://projects.reactivated.net/~dsd/gl860.git (gitweb interface). Nightly snapshots will be generated here.

So far it just includes my experimental programs to try and make sense of the protocol and capture images. It works, sort of, but there’s a lot to be done. It also requires libusb-1.0 due to the isochronous endpoint. Only try it if you’re interested in development or are just very keen and curious.

I’ve been hacking on the webcam in my System76 laptop. Here’s what I can get under Linux:

There seems to be an element of software-handled synchronization I have yet to understand. And who needs colour anyway?