[fprint] Startek FM200U driver

[Daniel Drake]

Philip Nelson wrote:
> Thanks for your suggestions. I've managed to send the first few packets and the
> light even turns on as if it's ready to scan, hoorah. I'm at the next hurdle now
> though - I've used usb_bulk_write() so far, but it seems the actual scanning of
> the finger transmissions are done isochronously, which as far as I can tell,
> libusb doesn't support (yet)?

Interesting! This is the first time I have personally encountered a USB 
device that does isochronous transfer.

> It seems odd, since I know that the binary application I have uses libusb - I
> even compiled my own libusb with some extra output and made it use that so I
> could see exactly what it was doing for the initialisation stuff - so I'm
> guessing it does something else for the isochronous transfers to get the finger
> image.

It probably uses usbfs directly. Run the binary program and while it is 
running, use lsof to list the open files belonging to that process - 
does it have 2 open file handles on /dev/bus/usb/X/Y (or 
/proc/bus/usb/X/Y)? One of them will belong to libusb.. if there is a 
2nd, it should confirm my suspicion that the app has explicitly opened 
the usbfs file directly for the isochronous I/O part.

> Not really sure where to go from here - perhaps I'm wrong and it's doing
> something totally different - here are the first few lines of output from usbmon
> straight after clicking capture in the binary app in case it helps:

First thing to check is that it really is an isochronous endpoint. Does 
"lsusb -v" confirm this? Also, do the URB completion messages in the 
usbmon logs still indicate isochronous transmission? i.e. are there 
messages that start with

	<address> <time> C Zi:3:

I'm fairly sure it will be (probably would fail otherwise, I just 
suggest trying this as it is legal to submit bulk I/O on interrupt 
endpoints). So, our options from here:

1. Mimic the binary app: add a function inside libfprint to explicitly 
open a file handle on the USB device node and do isochronous I/O.
e.g. fpi_usb_iso_open() and fpi_usb_iso_xfer()

This is not very nice and I'm slightly worried about any adverse effects 
that would happen from operating the device via 2 different file handles 
simultaneously. In fact, I'm surprised it is even possible (but the lsof 
experiment will confirm whether my guesswork is correct)

2. Right now the library assumes that all supported devices are USB 
devices accessible over libusb. I know this will change in future, 
because one device I want to support is behind a usb-serial adapter, so 
we will have to make it possible for drivers to be able to drive serial 
devices that libusb cannot claim. So, at some point we'll have to add a 
"bus type" abstraction (USB, serial) and we could possibly add a usb_raw 
bus type which uses usbfs directly rather than usb (in order to provide 
isochronous I/O access).

This isn't very nice either.

3. Switch to a new USB I/O library. This is actually something I started 
on last night, before you sent your email. The reason for changing is 
that libusb does not support asynchronous I/O, which means that we are 
unable to provide a nonblocking interface to libfprint users. Also, many 
features are significantly easier/cleaner to implement when the driver 
can asynchronously drive the library.

So, I'm looking into switching to OpenUSB. It's a young unreleased 
project (and the homepage is out of date) but it does support 
asynchronous I/O and isochronous endpoints, potentially solving both of 
these problems. As I said, I only started looking at this last night, so 
I'm not 100% sure of its suitability but it's something I'll be working 
on over the next few days.

Daniel