On Tue, 17 Apr 2007, John Wojnaroski wrote: > Hmm, now I'm puzzled. Does the byte order actually depict the sequence > of the bits sent by the OS?
Yes, although the way in which the order depicts the sequence depends on the formatting of the particular message in question. > Is this a difference in > bigendian/littleendian digits? If so, I goofed, so on to the fix and > next step. > > Excerpt from the usbmon.txt in ../Linux/Documentaton/usb > <<<<<<<<<<<<<<<<, > - Setup packet, if present, consists of 5 words: one of each for > bmRequestType, > bRequest, wValue, wIndex, wLength, as specified by the USB > Specification 2.0. > These words are safe to decode if Setup Tag was 's'. Otherwise, the setup > packet was present, but not captured, and the fields contain filler. > >>>>>>>>>>>>>>>>. > Here is the usbmon report when I set the wValue to 0x0200 > > df99e540 2476601557 S Co:002:00 s 21 09 0200 0000 0003 3 = 020202 > df99e540 2476606432 C Co:002:00 0 3 > > > so, that now matches the URB #9 from the SNoopyPro report under windows; > > bmRequestType = 21 > bRequest = 09; > wValue = 0x0200 > wIndex = 0x0000 > wLength = 0x0003 As it shoud. Note that the three word-sized quantities are transmitted in little-endian byte order on the USB bus. That shouldn't matter as far as you are concerned, however. > according to the description cited above. And with the "s" that would > indicate the packet was captured, but still not getting a response from > the device..... What makes you think you should get a response from the device? Your usbmon trace doesn't show that you asked for one. You sent a control-OUT message with the three bytes 0x02 0x02 0x02, but you didn't submit any IN transfers. > Just for completness, here is a series of four frames for each call to > the control msg. > > df99e540 2476601557 S Co:002:00 s 21 09 0200 0000 0003 3 = 020202 > df99e540 2476606432 C Co:002:00 0 3 > That's your control-OUT. > df99e540 2476606551 S Co:002:00 s 01 0b 0000 0000 0000 0 > df99e540 2476609431 C Co:002:00 0 0 That's the kernel restoring altsetting 0 after your program ended. > df99e540 2478577426 S Co:002:00 s 00 09 0001 0000 0000 0 > df99e540 2478580115 C Co:002:00 0 0 > df99e540 2478580265 S Co:002:00 s 01 0b 0000 0000 0000 0 > df99e540 2478583113 C Co:002:00 0 0 > df99e540 2478583236 S Co:002:00 s 21 09 0200 0000 0003 3 = 020202 This looks like your program running again, doing a Set-Config and a Set-Interface and then sending the control-OUT message. If the device ever did want to send any data back, your program didn't give it a chance. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
