On Sun, 12 Jul 2009, Adam Nielsen wrote: > Here are the traces: http://www.shikadi.net/files/odin/ > > I began the capture with no device connected, then connected the device (or > ran the gadgetfs app.) After the OS finished detecting the device, I waited > for 10 or so seconds and ran the application (to make this clear when looking > at the timestamps in the files.) For filenames with "win32" in them this was > the manufacturer's application, for filenames with "linux" in them this was my > own userspace app. My userspace app only sends one control message and reads > one interrupt response. > > To reiterate: > > hardware-linux: Host receives interrupt messages successfully > hardware-win32: Host receives interrupt messages successfully > gadgetfs-linux: Host receives interrupt messages successfully > gadgetfs-win32: Interrupt message data is never sent to host, the last message > is the control one telling the device to make the data available on the > interrupt endpoint. Since the userspace program works okay, I'll concentrate on the *win32 files. Right away I see three significant differences in behavior between the hardware device and your gadget. In order of occurrence, they are: The real device accepts a "Set Idle" command. The gadget rejects it with a STALL. The real device returns a zero-length packet in response to the "Get Input Report 0" request. (This seems unusual and is probably invalid -- it should send a genuine report.) The gadget gets a "Babble" error. The real device sets up ep1in as Interrupt with period 10. The gadget sets the period to 512. This is probably because you're using a full-speed encoding of the period instead of a proper high-speed encoding. The first difference appears to be harmless, but you might want to fix it anyway. The third difference is a real error and it needs to be fixed. But it doesn't account for the odd behavior you're seeing. The second different is the key. I believe it is responsible for your problems. You claim above that the in the gadgetfs-win32 file, the host never asks for the interrupt data. This is wrong; the host _does_ ask for it. But it asks at the wrong time, just after receiving the "Babble" error -- probably as a result of the "Babble". You can see this in the log at timestamps 0.791117 and 0.795590. The reason for this "Babble" is a bug in the dummy-hcd driver. The patch below fixes the bug, and it may solve your problems. Alan Stern P.S.: I still don't know what you're referring to when you talk about host-to-device transfers on the IN endpoint. The logs don't show anything of the sort. Index: usb-2.6/drivers/usb/gadget/dummy_hcd.c =================================================================== --- usb-2.6.orig/drivers/usb/gadget/dummy_hcd.c +++ usb-2.6/drivers/usb/gadget/dummy_hcd.c @@ -1306,11 +1306,6 @@ restart: setup = *(struct usb_ctrlrequest*) urb->setup_packet; w_index = le16_to_cpu(setup.wIndex); w_value = le16_to_cpu(setup.wValue); - if (le16_to_cpu(setup.wLength) != - urb->transfer_buffer_length) { - status = -EOVERFLOW; - goto return_urb; - } /* paranoia, in case of stale queued data */ list_for_each_entry (req, &ep->queue, queue) { -- 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
