Hi,

I haven't been publishing much activity lately. I've had a busy xmas, a 
horrible exam period, and a few other life things have been keeping me 
occupied. But I have been doing some work behind the scenes.

I recently described my intentions to move to a purely asynchronous 
model internally, and then to offer both a synchronous and async API to 
library users. This allows us to fit into a wider range of application 
structures, has some efficiency bonuses, and makes implementation of 
more advanced features significantly easier.

Unfortunately libusb only provides us with a synchronous API, so the 
first problem to tackle was finding a new USB access library that also 
provides async USB I/O access... Couldn't find one that did what I 
wanted, so I wrote my own prototype (fpusb). I then contacted the libusb 
author who liked my ideas and fpusb has now become the next version of 
libusb, named libusb-1.0. http://libusb.wiki.sourceforge.net/Libusb1.0

While producing the fpusb prototype was quick, finalization and refining 
is slow. Especially now that it's become libusb and has direction for a 
fleshed out 1.0 API, that adds extra work. Can't rush the API design.

Additionally, porting libfprint to an asynchronous model with libusb-1.0 
is proving more work than I expected. I still believe that it's the 
right way to go though, and despite the added work it's still a 
realistic goal.

All drivers need converting to an async model too, and unfortunately 
driver complexity is slightly higher as a result. I am putting 
mechanisms in place to try and retain some of the linearity that you get 
from synchronous I/O though.

Right now I have ported the primitive driver layer (i.e. init, deinit, 
enroll, verify, identify) to an asynchronous model and I have ported the 
upekts driver. This seems to be working. I am now about to start work on 
the imaging layer and the imaging drivers. The final stage will be 
exposing the async API to library users alongside the existing 
synchronous one (which has not changed, at least up until this point).

This can all be found in the libusb-1.0 branch of the libfprint git tree.

On the academic side of things I am under pressure as I have to 
demonstrate my project in about 3 weeks time. I really need to have the 
async conversion completed by then, plus hopefully a prototype of a 
dbus-based authentication daemon.

This timeframe isn't ideal, because it means that I don't have enough 
time in the short term to get things to a point where I can do releases 
again. For example, I want to get the libusb-1.0 API to a point that I'm 
relatively happy with before I do any libusb-1.0 alpha/beta releases, 
but my priority is getting the software ready for the demo and I don't 
think I will have time to do much more work on libusb-1.0 within that 
time. I cannot do any libfprint-0.1.x releases until there is a 
libusb-1.0 release. I cannot do any libfprint dbus daemon releases until 
there is a libfprint-0.1.x release, and so on.

So, it might be a few more weeks before any of my recent work is 
formally released. In the mean time it is all available from git 
repositories on projects.reactivated.net

I haven't forgot about the pending patches that have been submitted. 
Sorry for the delay in handling these. In addition to the time I need to 
spend getting things ready for the demo, having to maintain two branches 
of libfprint is a further drain on my time... Things should be better 
when I've finished the asynchronous stuff.

Daniel
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint

Reply via email to