> > 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
(In reply to comment #2) lists.freedeskt op.org/ archives/ fprint/ 2012-December/ 000376. html
> > Why threshold is so low?
>
> I wrote an e-mail to the mailing list explaining the situation in detail
> back in December:
> http://
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: libfprint/ poll.c quote:
see libfprint/
* 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