On Thu, 2007-11-22 at 11:34 +0000, Daniel Drake wrote:
> 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
> _______________________________________________
> fprint mailing list
> [email protected]
> http://lists.reactivated.net/mailman/listinfo/fprint

See this page for a libusb isochronous mode patch
http://web.archive.org/web/20070217173339/protu.it.helsinki.fi/~lindi/usb/

or 
http://protu.it.helsinki.fi/~lindi/usb/stv680/

See the 
[TXT]  libusb_augment.c  11-May-2006 00:14   8.2K
[TXT]  libusb_augment.h  06-May-2006 22:25   1.2K

files

-- 
--------
m.vr.gr.
Gerard Klaver


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

Reply via email to