On Thu, 9 Apr 2009, Aniruddha Marathe wrote: > Hi All, > > I am trying to understand how usb.c, the only working user mode driver > example that I found on the net that uses gadgetfs. Using that code as > the base I am trying to write a HID keyboard driver (user mode) with > Net2280 peripheral device controller to simulate working of a > keyboard. I referred to the following discussion that happened almost > half a decade ago but didn't lead to any useful conclusions (but did > help me find answers to some of my questions): > > http://www.mail-archive.com/linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx/msg20380.html > > I am running Wireshark with USB support on the host to see what's > going on. I've attached the traces of real keyboard and my simulation > keyboard with this email. My copy of Wireshark doesn't display the contents of the URBs correctly. Can you provide output from usbmon instead? > Based on that I have the following (newbie) > questions: > > 1. After the response to 'GET DEVICE DESCRIPTOR' request, the trace of > simulation driver shows that the host sends a 'GET DESCRIPTOR DEVICE > QUALIFIER' request. I do not see such request in the trace for the > real keyboard. Get-Device-Qualifier is sent only to USB-2.0 devices. No doubt your real keyboard is USB-1.1. > What is the meaning of this request? It is documented in the USB 2.0 specification (which you should be familiar with if you are going to write a USB driver). It asks for a device descriptor appropriate to the "other" speed: If the connection is running at full speed then it asks the device to send its high-speed device descriptor, and vice versa. > Was the response > to the earlier 'GET DEVICE DESCRIPTOR' request malformed (the sniffer > doesn't indicate that, however)? I can't tell since Wireshark doesn't display the response data properly. > Simulation keyboard trace: > > -------------------------------------------------------------------------------------------------- > Source Destination Protocol Info > -------------------------------------------------------------------------------------------------- > host 23.0 USB GET DESCRIPTOR Request > DEVICE QUALIFIER > > > 2. My simulation keyboard driver stops responding after the following request: > > ------------------------------------------------------------------------------- > Source Destination Protocol Info > ------------------------------------------------------------------------------- > host 3.0 USB SET CONFIGURATION Request > > What should my driver send as a response back to the host? Set-Configuration doesn't have a response, only an acknowledgement. You really should read through the descriptions of the standard requests in Chapter 9 of the USB 2.0 specification; if you don't understand them then you can't possibly write a USB driver. > I saw that > the real keyboard just sends a response with 0's filled in it. No it doesn't. You're probably seeing an artifact introduced by Wireshark. There's no response, only an acknowledgement. > Is this > what it is supposed to send? Keyboard simulator creates a new thread > for 'ep-a' management and writes the endpoint descriptor into ep-a's > file descriptor. But the host doesn't seem to get it (can't see it > on Wireshark). What I see is a (probable) timeout after 5 sec and 0's > filled in 'SET CONFIGURATION' response. Also after this, the host > doesn't send a request for reports, like it does in case of the real > keyboard. Why does this happen? Probably because your program isn't sending the acknowledgement. You should do more or less the same thing as the usb.c demo program. > 3. The real keyboard has an IN endpoint of type interrupt. As far as I > understand, this is the endpoint that should be sending the report > descriptors to the host. No. The interrupt-IN endpoint is used for sending the reports themselves; the report _descriptor_ is sent via endpoint 0. > However, in Wireshark I see that when the > host sends a 'GET DESCRIPTOR RPIPE' request the ep0 of the real > keyboard sends the report instead of ep1. Here is the trace (I assume > '3.0' means ep0): > > ------------------------------------------------------------------------------------- > Source Destination Protocol Info > ------------------------------------------------------------------------------------- > host 3.0 USB GET DESCRIPTOR Request RPIPE What do you think "RPIPE" means? Some sort of shorthand for "Report"? Wireshark is weird... > Since ep1 is interrupt type, shouldn't it send the report when the > host sends an 'IN' token packet to ep0 instead of ep0 sending it when > the host sends 'GET DESCRIPTOR RPIPE' to ep0? Endpoints don't respond to packets sent to other endpoints. So if the host sends a token packet to ep0, there won't be a response from ep1. If the host had sent a token packet to _ep1_ then you would expect to see a report sent back from ep1. Furthermore, "GET DESCRIPTOR RPIPE" (whatever else it is) clearly is a control transfer, not an interrupt transaction. As such it has to use ep0, not ep1. > 4. Is there any other documentation available on gadgetfs and usb.c > apart from the source code itself? No, not really. 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
