> >> That's the thing. On Windows, the hardware bug simply isn't triggered. > >> The timing of the USB packets is slightly different on Linux and > >> Windows and apparently that's enough to trigger the problem. > > > > Is this something that should be addressed in the USB subsystem? Is > > either the Linux or Windows way right or wrong, or just different? > > Just different, unfortunately. The error is clearly in the hardware and > there isn't much the USB subsystem can do about it since the EHCI driver > just programs the controller and the actual timing depends on the > controller. At which point the difference springs into existence is > something I haven't understood yet and nobody was able to tell me.
A control request is made of a SETUP transaction (setup stage), zero, one or more DATA transactions (data stage) and a last DATA transaction (status stage). The EHCI driver splits the request into at least 2 transactions (when there is no data stage), and queues all the transactions to the hardware. Individual packets timing in a single transaction is up to the controller, but it should be possible to delay submission of transactions instead of queuing them ASAP. Knowledge of the EHCI driver internals is needed here. Anyone wanna give this a try ? Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
