On Mon, 14 Nov 2005, Daniel Drake wrote: > I'm sorry to throw a mass of sniffed data and early driver code at the list, > but I've been working on this problem for a few days now, with no success. > I'm > hoping that someone might be able to spot an obvious mistake or offer > suggestions on things to try :)
... > My driver clones the sequence 1-6 just fine, but I don't get the response > from > either bulk command. I've noticed that despite this, the callback functions > *do* get executed when I unplug the device - is this normal? Yes. If an URB submission succeeds then the callback routine is guaranteed to be called eventually. > The control commands work fine, I get the desired responses and the device > even visibly reacts to some commands (e.g. turning the light on). I'm > wondering if it's just something I'm doing wrong with bulk transfers, but > I've > looked over it a good few times now... One bulk and one interrupt transfer, not two bulk. > I'm attaching the UsbSnoop logs on the fingerprint interface, semi-annotated > Linux usbmon logs on the port when HID support is disabled (i.e. a sniff of > my > own driver), and the driver code so-far. I'm also attaching the "lsusb -v" > output for the device. In answer to some of the things you mentioned in the usbmon log... The initial portion is indeed irrelevant. It shows the device detection and address setup. UsbSnoop might show you some of that stuff if you traced the root hub. The URB you labelled with just a '?' corresponds to URB 2 and the one before it corresponds to URB 1 (read the entire configuration descriptor and read just the first 9 bytes, respectively). The three preceding URBs have no equivalent in Windows; they are meant to check for a high-speed capable device using only a full-speed connection. But the data shown by usbmon is different from the data shown by UsbSnoop! The Linux data indicates the presence of 3 interfaces whereas the Windows data indicates just 1. Maybe Windows has filtered the data for you. The Set-Configuration call isn't done that much later in Linux than in Windows. The only difference is that Windows reads the string descriptors after Set-Config whereas Linux reads them before. I didn't go through the details of the firmware transfer, but everything else looked correct. It's not obvious why the device doesn't respond to your program. The URB at the end was sent after your driver's probe routine returned. It was in response to the URB that completed way back at timestamp 2984128892. > I haven't focused much on what the other interfaces are doing, as they are > HID-compliant I don't think they are doing anything special, and I doubt (in > terms of implementing the components in the hardware) that sending commands > to > another interface would affect the fingerprint reader... I guess this is the > next thing to check, if nothing emerges at this point. I would certainly be suspicious about the other interfaces. Note that HID-compliant interfaces can receive reports as well as send them. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
