Re: hid drivers

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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel