>> In this particular case I know that VirtualBox isn't to blame, because if I
>> plug in the real hardware device then it works perfectly (this is how I was
>> able to initially reverse engineer the communication protocol.) It's only my
>> gadgetfs device that isn't communicating properly.
>
> It may be that the Windows app behaves differently because of the
> differences between your gadget and the real thing. Have you compared
> usbmon traces for the two cases?
Okay, I've been through the whole HID initialisation sequence (which resulted
in some new dissector code for Wireshark) and here are the only differences I
can see:
- In the device descriptor:
- Hardware is USB1.1, gadgetfs is USB2.0
- Hardware bcdDevice is 0x101, gadgetfs overrides this as 0x100
- 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.
- 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.)
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. I'm not sure
why the host is trying to write zero bytes to the read-only interrupt
endpoint, but my gadgetfs code gets an error if I try to read from the
interrupt endpoint (which is normally used for writing data out to the host.)
> "arrives on an interrupt endpoint" is a little misleading. The data
> may be sitting in the device's buffer for that endpoint, but it won't
> arrive at the host until the host asks for it.
So in the case of a keyboard sending keypresses over an interrupt endpoint,
how does the host know when keys are pressed? Does it need to poll the
interrupt endpoint just in case some data arrives? Why not then use a bulk
endpoint? I always assumed the host would be notified when there is data to
read from an interrupt endpoint.
> Comparison of the usbmon logs should show the important differences.
> In fact, you've got four cases to look at, by varying the application
> (Windows app vs. your test program) and the device (real thing vs. your
> gadget).
Well apart from the minor issues listed above, the usbmon traces look
identical for all four cases, with one of them (Windows to gadgetfs) having no
interrupt messages. The HID initialisation code (which tells the host there
is an interrupt endpoint and where it is) is identical.
Any other ideas? I'm happy to post my code if it would help.
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
