On Tue, 7 Jul 2009, Adam Nielsen wrote: > 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. Don't say they "get lost" unless you really mean it. "Get lost" implies that the packets were sent by the device but not received by the host (or vice versa). However it's not clear that these packets were sent in the first place. If they were sent by the host, they definitely would show up in the usbmon trace. > The *other* interrupt transfer (from host to device, on the IN endpoint, > apparently in the wrong direction) I'll repeat: This is impossible. You should post a usbmon trace to illustrate what you mean, together with the "lsusb -v" information for your device and gadget. > 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. Post usbmon traces for both cases. > 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. If it comes from your gadget then it comes from your gadgetfs code. The kernel part of gadgetfs doesn't automatically send data on any endpoint other than ep0 -- and not much on ep0. > 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. Yes, it does. > 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. How do you know that these interrupt messages aren't getting through when you don't even know if they are being sent in the first place? > I hope this explains it a bit better. A little, but not enough. Seeing the data will make things a lot clearer. > 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. Yes. Alan Stern -- 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
