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.

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.

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.

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.

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.

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.

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.