On Thu, Oct 22, 2015 at 05:15:50PM +0100, John Tapsell wrote: > On 15 October 2015 at 15:37, Alan Stern <st...@rowland.harvard.edu> wrote: > > On Thu, 15 Oct 2015, John Tapsell wrote: > > > >> I did have one wacky idea. I'm sure it's stupid, but here it is: Is > >> it at all possible that there's a bug in the linux usb code where a > >> bInterval value of 1ms is being converted into microframes (8 > >> microframes) but then because it's a full speed device it's then > >> incorrectly read as an 8ms delay? I did have a look into the code, > >> but got thoroughly lost. Any pointers on how I could check my wacky > >> theory? > > > > There is no such bug. Such a thing would have been spotted long, long > > ago. > > > >> I'm just wondering where this 8ms delay comes from. > > > > Multiple places: time to submit the request, time to reserve > > bandwidth for the previously unused interrupt endpoint, time to > > complete the transfer, all multiplied by 2. > > > > You can get more information from usbmon (see > > Documentation/usb/usbmon.txt in the kernel source). But Greg is right; > > the protocol you described is terrible. There's no need for a multiple > > ping-pong interchange like that; all you should need to do is wait for > > the device to send the next bit (or whatever) of data as soon as it > > becomes available. > > > > Alan Stern > > > I had a look at the windows driver, and found that it is implemented > in pretty much exactly the same way as the linux driver, but it > operates at twice the speed. And that's for a user-space USB driver. > > Any ideas why?
"pretty much"? What exactly is the difference? And you should be able to try out a userspace driver in Linux as well, libusb works on Windows and Linux so you can do a good comparison. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
