[sane-devel] SniffUSB: URB direction and TransferFlags IN/OUT confusion

[Gernot Hassenpflug]

On Fri, Feb 26, 2010 at 12:38 AM, m. allan noah <kitno455 at gmail.com> wrote:
> Do you find that the machine actually makes any control packets once
> it starts scanning? Many scanners only use those at initial
> configuration, which is taken care of by the host OS, and calls to set
> interface, etc. I have found that I generally only use bulk packets
> with most scanners...

Hello,

Yes, so it would appear, also in this case. Attached is the gzipped
usbsnoop output of a 75-dpi B/W (or greyscale, not sure) scan of 2
inches wide by 1 inches high sheet of white paper, after passing log
output through spike4. The configuration was done before that, and
there do not appear to be any other control packets since then.

I imagine that is good news.

I haven't analysed the spiked output yet to see what is sent and what
is received (Stef recommended checking for possible firmware sending
but there did not seem to be anything sent during the initial
configuration when scanner is attached to the host).

Two questions, from reading the USB specs so far:

1) in usbsnoop endpoint numbers show up as 0, 7 (bulk OUT), 88 (bulk
IN), and 89 (interrupt IN). But there are only 4 bits for endpoint
numbers (maximum of 15 extra endpoints for IN and another 15 for OUT).
So do the endpoint numbers include some other bits also to give such
high numbers?

2) I'm confused what the order of bits is in usbsnoop output. I
understand a display in LSB order means LSB is Bit0, and is given on
the leftmost side, as in Bit0, Bit1, Bit2... and Bit0 is transferred
out first in the serial protocol.
So if I have usbsnoop data like the Vid, Pid, Rev: 12 01 00 02 00 00
00 40 a9 04 01 19 01 01 02
the order of bytes received is from left to right (I assume!) but for
each byte, is the LSB representation for (e.g., a9) like this (0=LSB,
7=MSB):
0 1 2 3 4 5 6 7
1 0 0 1 0 1 0 1
or like this:
0 1 2 3 4 5 6 7
0 1 0 1 1 0 0 1
I assume the latter, if the data are visually a string of 0 and 1
conveniently grouped in hex representation.

Best regards,
Gernot Hassenpflug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usbsnoop-scan.txt.gz
Type: application/x-gzip
Size: 33256 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100226/9b6850b4/attachment-0001.bin>