[fprint] vfs5011 support

[Vasily Khoruzhick]

On Thu, Jan 15, 2015 at 10:22 AM, Per-Ola Gustavsson
<pellesmek+fprint at gmail.com> wrote:
> vfs5011 is now really smooth and reliable. I have not looked at the
> image processing for possible improvements, it is swipe speed
> sensitive in my opinion. It would be nice to unlock more of the
> functionality of this device, unfortunately it cannot dance but it can
> flash red at failure! The driver is a crude hack at the moment. And
> some cleanup would be nice.

With or without your threading changes?

> I reverted some changes and the old driver aes2501 seem to be happy too.
>
>> Not true. Did you hear anything about multiplexing and
>> select/poll/epoll syscalls?
>
> Do not hear any of it in this case, libfprint is "asynchronous" and
> don't utilize those
> techniques for device communication. While there is great usage scenarios for
> select/poll/epoll it is very much blocking and synchronous. Simple and reliable.
> Let's use it!

Actually, it does. Take a look at libfprint/poll.c

>> As far as I remember, Daniel is an original author of libusb. But
>> maybe things changed since he stepped out from libusb development.
>
> Yes, I see his name in libusb.h. I dug though some of the code of
> libusb, I now see that i missed a part in the reference manual, my
> bad. Didn't realize it used the same weird "asynchronous" methods as
> libfprint. It's more non-blocking than asynchronous. Making these
> things cross platform is a challenge, I know, but this is plain weird
> coding. It's time for change!

Heh, asynchronous != multithreading. libfprint provides asynchronous
API which isn't weird. It's called multiplexing.
Usually main loop is organized via
poll/epoll/select/WaitForMultipleObjects (in Windows case), and
libfprint has a way to provide FDs to
intergrate into main loop and function to handle events when there're
events on those FDs.

Anyway, I'd like to highlight once again that you're trying to solve
issues of vfs5011 driver which isn't a masterpiece of code
by reworking whole library and breaking other drivers. Do you realise
that other users won't be happy if with new libfprint release their
devices
stop to work?

So in pseudocode it looks like this:

mainloop() {
  r = poll(fds, fds_cnt);
  if (r > 0) {
    if (fds[libfprint_fd_1].revents & SOME_EVENT)
      fprint_handle_events();
  }
}

fprint_handle_events calls libusb_handle_events(), and libusb callback
aren't supposed to be called after libusb_submit_transfer() in the
same iteration of mainloop.
If callback is called from another thread it looks like a potential
bug to me, since libfprint doesn't expect it.

Regards,
Vasily