On Mon, Jun 05, 2000, Mark Douglas Corner <[EMAIL PROTECTED]> wrote:
>
> Also after further study this is what I have found: The camera doesn't
> work for what appears to be a DIFFERENT reason. In that case the zero
> length data packet is never sent after the set_address. We can deal with
> this later. (BTW, there are several different Intel USB cameras. Some may
> work) Right now let's focus on my_dev.
There shouldn't be a zero length data packet for set_address. Does
Windows do that?
Or are you talking about the status phase for control messages?
> It seems that windows fails on the first round as well, but it tries again
> and succeeds. Perhaps the stack should start over on the enumeration from
> the beginning? Also windows sends most commands in sperate frames, rather
> than using the same frame. This may be the cause of the NAKs. I realize
> that we are probably within spec and the devices suck and windows
> compensates. However, it looks like we will have to fix this or risk
> being incompatible.
Yeah, it's called Full Speed Bandwidth Reclamation. It just keeps trying
to send packets till the frame is over. If the device doesn't like this,
then it's out of spec.
> Here are the summaries.
>
> I use 'show USB transactions' for clarity. Each time index is the closest
> frame number. I haven't figured out all the triggering stuff yet.
>
> linux_mydev.usb
> 260 RESET
> 490 Initial GET_DESCRIPTOR, ACK
> Several IN commands followed by NAKs
> Device sends DESCRIPTOR
> host sends OUT.
> 492 SET_ADDRESS, ACK
> HOST sends IN, several NAKs
> Device sends 0 length data packet on addr 0 (this is required by
> spec)
> 510 GET_DESCRIPTOR, no response or NAK (5*3 times)
>
> win_mydev.usb
> 160 RESET
> 231 Initial GET_DESCRIPTOR, ACK
> 232 IN followed by device descriptor
> 234 host sends OUT
> 235 RESET (why?)
> 336 SET_ADDRESS, ack
> 337 HOST sends IN, gets 0 length data packet on addr0
> 351 GET_DESCRIPTOR, no response or NAK (3 times)
> 930 RESET
> 1071 Initial GET_DESCRIPTOR, ACK
> 1072 IN followed by device descriptor
> 1074 host sends OUT
> 1075 RESET (again, this strange reset)
> 1176 SET_ADRESS, ACK
> 1177 IN followed by 0 length data
> 1191 GET_DESCRIPTOR, ACKed!
> proceeds normally from here....
How odd. I guess we can do something similar with our code as well.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
