>> - In the device descriptor:
>> - Hardware is USB1.1, gadgetfs is USB2.0
>> - Hardware bcdDevice is 0x101, gadgetfs overrides this as 0x100
>
> I don't see anything in the gadgetfs source code to override bcdDevice.
> Are you sure it happens?
My code:
static struct usb_device_descriptor device_desc = {
.bLength = sizeof device_desc,
.bDescriptorType = USB_DT_DEVICE,
...
.bcdUSB = __constant_cpu_to_le16 (0x0110),
...
.idVendor = __constant_cpu_to_le16 (DRIVER_VENDOR_NUM),
.idProduct = __constant_cpu_to_le16 (DRIVER_PRODUCT_NUM),
.bcdDevice = __constant_cpu_to_le16(0x0101),
...
lsusb output:
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
...
idVendor 0x1044 Chu Yuen Enterprise Co., Ltd
idProduct 0x4001
bcdDevice 1.00
>> - Hardware bMaxPacketSize0 is 8, gadgetfs overrides this as 64
>> - In the config descriptor:
>> - Hardware bmAttributes is bus powered, remote wakeup. Gadgetfs device
>> won't be detected under Linux unless it's listed as self-powered, no remote
>> wakeup.
>
> I don't understand that. What do you mean, it won't be detected? What
> will happen?
Sorry, I was thinking of another issue with the detection - if I set
bmAttributes to USB_CONFIG_ATT_ONE | USB_CONFIG_ATT_WAKEUP then the write()
call to write the device descriptors to gadgetfs fails with "Invalid
argument", so my program is forced to abort.
>> - After returning the HID descriptor, the host sends the hardware an empty
>> write on its interrupt output endpoint. This message never appears in the
>> usbmon trace for the gadgetfs driver. (But only under win32, the interrupt
>> does appear when Linux is accessing the device.)
>
> This is probably the result of a bug in usbfs (and possibly a bug in
> libusb as well); 0-length transfers aren't accepted.
Is this unrelated to a 'stall' then? Gadgetfs seems to use a 0-length
read/write (in the opposite direction) to indicate a stall condition. Is this
just specific to gadgetfs?
>> I think the last point is the most significant - interrupt messages don't seem
>> to be passed through regardless of which direction they're in.
>
> Are you sure the problem is interrupt transfers and not 0-length
> transfers?
I think so - this 0-length interrupt always appears under Linux, and appears
under Win32 when accessing the real hardware device. Likewise the actual
interrupt messages carrying response data always appear under Linux, and only
under Win32 with real hardware. With the gadgetfs driver under Win32, both
the 0-length interrupt and the legitimate response data (in the form of
interrupt messages) are never read (they don't show up in the usbmon capture,
in either direction.)
> Above you wrote that the host sends a 0-length transfer to the
> "interrupt output endpoint". Here you say the "read-only interrupt
> endpoint". Clearly "output" != "read-only". Which is it?
Sorry, I'm not familiar enough with the USB terminology. After checking the
spec, it's the interrupt IN endpoint (where data is sent to the host.) The
host is sending a 0-length interrupt message to the device on the IN endpoint,
which I assumed was some kind of stall message, but perhaps not.
>> Why not then use a bulk
>> endpoint?
>
> Three reasons. First, interrupt endpoints have guaranteed maximum
> latency (important for real-time response to input events) and bulk
> endpoints don't. Second, polling bulk endpoints uses up a lot more
> bandwidth than polling interrupt endpoints. Third, low-speed devices
> (which includes the majority of USB mice) aren't allowed to have bulk
> endpoints.
Ah ok, I didn't realise it was more about priority than function.
>> I always assumed the host would be notified when there is data to
>> read from an interrupt endpoint.
>
> Your assumption was wrong. This is all explained in the USB 2.0
> specification, freely available from www.usb.org. Much of it is quite
> readable.
You're right, thanks for that. I'll take a closer look at the spec next time.
> Here is a patch to make usbfs accept 0-length transfers. You may need
> to tweak it somewhat to make it apply to your kernel. And you should
> check libusb to see if it rejects 0-length transfers as well.
Will do. What should I see once I am running with the patch? More 0-length
transfers? At the moment libusb is only involved in my Linux client
application, which works fine either way (real device or gadgetfs.)
Thanks for your help!
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
