On Mon, 6 Jul 2009, Adam Nielsen wrote:
> >> - 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
Sorry, I still don't see it. I'll have to do some testing of my own.
BTW, which kernel version are you using? (Sorry if you already
mentioned it; I don't have the old emails handy at the moment.)
> >> - 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.
Yes, that's right. The gadgetfs driver insists that the WAKEUP bit
be turned off.
> >> - 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?
It is unrelated. Gadgetfs uses any read/write in the "wrong" direction
to indicate a stall -- the length doesn't have to be 0. (Yes, this is
specific to gadgetfs. With other USB drivers there's no way to
read/write in the "wrong" direction.)
> > 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.)
You're not expressing yourself logically. Don't use phrases like
"under Linux", because when you're running Windows as a guest OS it's
still under Linux. And don't say "the gadgetfs driver under Win32";
that makes no sense since gadgetfs is a Linux driver and cannot run
under Windows.
So let's just consider the case where Windows is running as a virtual
guest. Do the 0-length interrupt transfers appear in the usbmon log
when you attach to the real device? Do they appear when you attach to
your gadgetfs driver?
> > 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.
Indeed not -- in fact, it's impossible. The host cannot send any data
to an IN endpoint. As you mentioned, IN endpoints are used for sending
data from the device to the host, not from the host to the device.
Better recheck your records.
> > 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?
I hope so!
> At the moment libusb is only involved in my Linux client
> application, which works fine either way (real device or gadgetfs.)
How do you know it isn't also involved in your virtualization
environment? It seems not unlikely that VirtualBox (or whatever system
you're using) sends the guest's USB I/O to the physical devices via
libusb.
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
