Comment 33 for bug 790183

(In reply to comment #2)
> > Why threshold is so low?
>
> I wrote an e-mail to the mailing list explaining the situation in detail
> back in December:
> http://lists.freedesktop.org/archives/fprint/2012-December/000376.html

OK

> > No synchronous transfers are allowed in driver
>
> The fact that you didn't tell this before is a bit surprising given that the
> code has been available for more than a month now.

You didn't ask for assistance in driver development, and I didn't pay enough attention to maillist for last months.

> Switching to asynchronous transfers is a major change that would require
> some effort. And let me put it frankly: your reply does not exactly motivate
> me to do that.

Well, I'll try to explain you why it's an requirement:
see libfprint/libfprint/poll.c quote:

 * libfprint does not create internal library threads and hence can only
 * execute when your application is calling a libfprint function. However,
 * libfprint often has work to be do, such as handling of completed USB
 * transfers, and processing of timeouts required in order for the library
 * to function. Therefore it is essential that your own application must
 * regularly "phone into" libfprint so that libfprint can handle any pending
 * events.
 *
 * The function you must call is fp_handle_events() or a variant of it. This
 * function will handle any pending events, and it is from this context that
 * all asynchronous event callbacks from the library will occur. You can view
 * this function as a kind of iteration function.

Usually application adds libfprint FDs to its poll/select call and calls fp_handle_events_timeout() on any event for those FDs. That basically means that libfprint runs in main loop, same loop in which UI runs. So it's not a good idea to use synchronous libusb calls, because they can take >1s to complete, so it can "freeze" UI for 1s.

Anyway, it's not complicated to convert your driver to asynchronous model. Join #<email address hidden> IRC channel and I'll try to help you