On Mon, Jun 05, 2000, Mark Douglas Corner <[EMAIL PROTECTED]> wrote:
> > > This basically tries to enumerate the device twice from SCRATCH, rather
> > > than attempting it 15 times in the middle. Let me know what you think, I
> > > can change it to a configurable number of times or something like that.
> > > Both the Intel USB camera and my other device enumerate fine now.
> >
> > Whoa. If that's true, then it lied to us. usb_new_device assumes the
> > device is responding at device id 0. If it acks the set_address and
> > still responds to 0, then it should be shot!
>
> Exactly! Wierd, huh?
>
> The device sets it's address acks it etc, but never responds to the
> get_descriptor sent to the new address. It is hard to say from just the
> USB trace, but I believe that the device has reset ITSELF to the address 0
> for some unknown reason, or it never set it's address and it lied to us.
> Evil device!
>
> The windows stack resets and tries again when there is no response on the
> new address. The linux stack doesn't do the reset, but just tries again
> on address 0 and gets a response. For some reason the set address "takes"
> on the second try.
I hate broken devices, but I think we can easily workaround this
problem.
> Don't get me wrong, I am not saying that the stack has a bug in it, just
> that the device may have a bug and here is a fix. I am guessing that you
> haven't seen this before :)
Don't worry. I was pretty convinced that the device was at question, not
the stack :)
> Thanks for your help. I guess we will leave it at that and if it comes up
> again in another device then we can reconsider.
Like I said in a previous email, we can probably do the same thing
Windows does. I'll work on a patch sometime this week.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
