Hi Alan, Sorry about the delay getting back to you on this, your patch does seem to have worked in so far as I can match the hardware device's behaviour more accurately now, but unfortunately the gadgetfs driver is still not behaving the same as the physical device. > 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. I think I've fixed these three issues now. I've uploaded a new packet capture at http://www.shikadi.net/files/odin/ (the new file is called usbmon-gadgetfs-win32-v2.txt) Not being 100% sure what the interrupt periods should be, I set it to 7 which, if I'm reading the docs correctly, should give me an 8ms period under USB2.0 (compared to the USB1.1 hardware's value of 10, which I take to mean 10ms.) > The second different is the key. I believe it is responsible for your > problems. Unfortunately fixing that (assuming I have done so correctly) hasn't fixed the gadgetfs device's behaviour. From my understanding of the HID spec, the host sends a control transfer, the device acknowledges it (with the zero-length packet) then makes the response data available on the interrupt endpoint. Now that my device is correctly acknowledging the control transfer, I do not know why the host does not seem to request data from the interrupt endpoint. About half way through the initialisation sequence the host seems to request data from the interrupt endpoint, and shortly thereafter it receives an -ESHUTDOWN error (108), and the host never seems to request interrupt data again after that. With the hardware device the host does not request any interrupt data this early in the initialisation sequence (only right at the end of the init sequence, which is fine.) I'm not familiar enough with the dummy_hcd code to understand what could cause the -ESHUTDOWN error. Any hints would be much appreciated. Many thanks, 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
