Re: gadgetfs isn't sending interrupt messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 25 Jul 2009, Adam Nielsen wrote:

> 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.)

Yes, that's right.

> > 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 have no idea why Windows would ask for the interrupt data at
different times for your gadget and for the hardware device.  But it 
looks like things would work if not for that -ESHUTDOWN error.

> I'm not familiar enough with the dummy_hcd code to understand what could cause
> the -ESHUTDOWN error.  Any hints would be much appreciated.

dummy-hcd doesn't return -ESHUTDOWN for host requests ever.  That code
must be coming from somewhere else.  You can get more information by 
building a kernel with CONFIG_USB_DEBUG enabled and by turning on the 
usbfs_snoop module parameter for usbcore.

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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux