dsd’s weblog

Lorin Olivier has created a kernel driver for his GL860 webcam. Lorin’s device is the 05e3:f191 variant, whereas mine is the more common 05e3:0503. There are differences between the devices that we don’t have much of a grasp on. The code we’ve written for each device is incompatible with the other, even though there are some protocol similarities.

Lorin reports that his driver works reasonably well with his device - it works with camorama, xawtv, ekiga, amsn, mplayer and xsane. He has also determined how to adjust various camera settings (luminosity, saturation, hue, sharpness, retrolighting, mirror effects, light source, AC power frequency).

Although Lorin doesn’t actually own an 0503 device, he’s attempted to implement support for it based on my earlier efforts. Given that I didn’t get very far, it probably doesn’t work that well. I haven’t had a chance to try it, but there’s no point me sitting on this any longer.

It’s in my git repository in the nvgl subdirectory:
git://projects.reactivated.net/~dsd/gl860.git (gitweb).

All credit goes to Lorin here - thanks! He’s done a great job, but do remember that its experimental code based on a reverse-engineered protocol, so don’t expect it to be flawless.

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.

I’m going to be spending this summer working in Boston (well, Cambridge). I need somewhere to live from early June to late September.

I am looking to rent a furnished bedroom in a location with access to public transport (I’ll need to get to and from Kendall/MIT each day).

If anyone knows of anything, please let me know.

The Pavão Quartet have released their fourth album today, “Dreaming.” The lead violinist, Kerenza, is a relative of mine.

Dreaming is similar to their 2006 debut album Someone to watch over me - a mix of well-known songs with some classical tracks too, all uniquely arranged for the quartet.

Buy it from HMV or Amazon.

Track list

1. Grieg’s Nocturne
2. Moon River
3. Dream a Little Dream
4. Somewhere Over the Rainbow
5. When You Wish Upon a Star
6. Schumann’s Traumerei
7. Gershwin’s Lullaby
8. Elgar’s Lullaby
9. Moonlight Sonata
10. Forgotten Dreams
11. Fly Me To the Moon
12. Clair de Lune
13. New World Symphony

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?

Although I’m not really working on the “old” code any more, I released libfprint v0.0.6 today. It fixes compatibility with newer DigitalPersona scanners including the ones in Covadis products (who kindly donated hardware to allow for this development). It also adds Gustavo Chain’s driver for the SecuGen Hamster III.

Gavin Smalley donated a Veridicom 5thSense scanner, which I reverse engineered and produced a driver for. This driver is only available from the highly volatile libfprint development repository. It works well.

System76 generously donated a laptop with one of the dreaded 147e:2016 UPEK scanners so that I can work on getting it supported in fprint. It’s too early to discuss driver practicalities, but I have almost figured out the image format.

The laptop also includes an integrated Genesys Logic GL860 USB webcam (05e3:0503), not standards compliant and not usable under Linux. I’ll probably also be working on a driver for this device. Again, I have already almost determined the image format, but have not looked at the rest of the traffic.

I’ve been a bit quiet on on the fingerprint scanning front recently, but I’ve been doing a lot of work behind the scenes.

Adopted the libusb project

libfprint has had a design flaw from early on: it only provides a synchronous interface. The technical minded will understand this better in terms that each function call to scan a fingerprint blocks for the duration it takes the user to scan their finger. The library could force its users to do fingerprint scanning in a dedicated thread, but that’s not very nice. It could also create threads internally to avoid this problem, but I don’t agree with that either. I know that things can be done properly by providing an asynchronous interface and not requiring any threads.

The biggest roadblock in offering an asynchronous interface from libfprint (and the reason this was not offered from the start) was due to libfprint’s reliance on libusb and the fact that libusb does not offer asynchronous I/O. The result of this is that it is impossible to offer true asynchronous functionality in anything built on top of libusb.

libusb development had unfortunately stalled, and I could not find any alternatives that I was in agreement with. I started writing my own libusb replacement. The original libusb author, Johannes Erdfelt, liked my ideas and this lead to him handing off the libusb project to me. My new USB library will be released as libusb-1.0 when completed.

Making fprint asynchronous

After producing a working prototype of an asynchronous USB library, I converted most fprint drivers to an asynchronous model and exposed an asynchronous API to library users.

I then ported fprint_demo to use the new asynchronous API, which is working well. Another big plus of an asynchronous model is the opportunity to implement cancellation. fprint_demo now has a working “cancel” button which cancels any ongoing fingerprint scan request.

Exposing fprint over D-Bus

Next task on the table was to work towards handling the complicated scenario of when multiple users and/or applications want to be fingerprint scanning simultaneously. Some kind of central entity is needed to coordinate access.

Enter fprintd, my initial step in this direction. fprintd is a D-Bus daemon which exposes fprint functionality over the D-Bus message bus. There are no fprintd users yet, but this will be the approach we take for desktop integration in future.

Assessed project demo

As I mentioned previously, fprint is actually my final year university project and after reaching the stages described above it was time for an assessed demonstration of my project.

The demonstration went extremely well, and I was impressed with the marker who asked exactly the same kinds of questions that I would have done in that situation - which of course I knew the answers to. He also understood the asynchronous issues perfectly despite me not explaining them in detail due to time constraints.

What next?

The above development work was all a little rushed in order to have things to show in time for the project demonstration. Now that the demo is over, I am left with an incomplete libusb-1.0 implementation, an unstable libfprint asynchronous API, a new fprint_demo version relying on the unstable API, and an unstable/incomplete D-Bus daemon. All of these are not released (but code is available from public development repositories) so I have some work to do!

I am going to focus now on stabilising from the ground up, starting with the most low-level component - libusb. I’m working through the TODO list and hope to have an alpha or beta release ready within the next few weeks.