> Okay, I think I found the trouble (without even looking at your source > code!). The problem is not in gadgetfs; it is in your program. Have > you searched your code for occurrences of "bcdDevice"? I bet you'll > find that the value gets changed, probably in the autoconfig() routine. Aah! You're right! How could I have missed that :-$ Well at least that explains that problem - thanks for pointing that out. > Before you said the missing interrupt transfers were going from the > host to the gadget. Now you say they're supposed to be going from the > gadget to the host. This suggests you have a bug in your gadget > driver, like you're trying to write to the wrong endpoint or the > endpoint is configured for the wrong direction. To clarify, the *important* interrupt transfers (the ones carrying actual data) go from the device to the host. These are the ones I'm most interested in, and they only get lost when the application requesting the data is running under WinXP through VirtualBox. If the application requesting the data is running directly under Linux then the interrupt transfers work fine. The *other* interrupt transfer (from host to device, on the IN endpoint, apparently in the wrong direction) appears shortly after running the gadgetfs program, as the device is being detected by the OS. If Linux is doing the detecting then this backwards-interrupt transfer appears, if WinXP inside VirtualBox is doing the detecting, then the backwards-interrupt does not appear. I do not understand where this backwards-interrupt is coming from, but since it also appears when the physical device is plugged in (regardless of the OS doing the detecting) it does not appear to originate from the gadgetfs code. In this context, "detecting" means retrieving the device's HID information. I can't be sure, but I think Linux always handles things like assigning a new device an address. I'm not so worried about the backwards-interrupt (for want of a better term), but I thought it was worth noting that when there are troubles with the interrupt messages making it through, it doesn't seem to matter which direction they go in - either all interrupt messages are transferred, or none of them are. It's not restricted to a particular subset of interrupt messages. I hope this explains it a bit better. As far as I can tell I have coded everything correctly (writing to the right endpoints, etc.) and this seems to be true since my Linux application can read data successfully from both the physical device and the gadgetfs device. I am still not 100% sure how the dummy_udc driver knows that I want "ep-a" to be an interrupt in device, but I assume gadgetfs gleans this information from the USB descriptors sent to it during initialisation. Cheers, Adam. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
