On Wed, 5 Jan 2005, David Brownell wrote:
> > Incidentally, if anyone can suggest why some devices like this one fail
> > with the new initialization scheme while (presumably) working correctly
> > with Windows, I would like to here it. The intent of the new scheme was
> > to duplicate exactly the sequence of transfers that Windows uses.
>
> Windows has many different versions ... they don't all act the same.
That's true, of course. But as far as initial device setup is concerned,
I think all versions later than Windows ME (including NT4, 2000, and XP)
do behave the same.
> I'd be interested in knowing if the following patch makes much
> of a difference ... I suspect it'd help other cases a bit better,
> where the "-EPROTO" error suggests that the oversized read had a
> somewhat impolite failure mode. Though this case ("-ETIMEDOUT")
> might be affected too; who knows.
Your patch changes the initial descriptor read from 64 bytes to 18 bytes,
right? I'm almost certain that will break with some devices (although it
may help others). Anyway, the intent of the scheme was to duplicate the
Windows packet sequence, which always requests 64 bytes. The real
question is: If a device works under Windows, why doesn't it work under
Linux with the same sequence of packets?
> It may also be worth noting that usb_control_msg() has a rather
> atypical failure status. Normally one expects that when software
> reads N bytes successfully then gets an error, the return from
> the read is N not an error code ... usb_control_msg() returns
> the error code instead. I've seen some devices that act a lot
> happier if that's changed to return N, like any normal read;
> so usb_internal_control_msg() would
>
> return length ? length : retv;
>
> I forget why I never submitted a patch to do that.
Are there are drivers that actually care about this? What about the usbfs
API? The initial descriptor read in the hub driver is very careful to
ignore the return code and only pay attention to the data buffer.
Alan Stern
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
