On Sun, Oct 16, 2011 at 7:18 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 16 Oct 2011, Johannes Stezenbach wrote: > >> On Sat, Oct 15, 2011 at 03:04:28PM -0400, Alan Stern wrote: >> > On Sat, 15 Oct 2011, Johannes Stezenbach wrote: >> > >> > > What I meant to say is Markus' statement that the device only >> > > works at a certain transfer size cannot be true since >> > > this size is not visible to the device via the USB bus. >> > >> > That's what I would expect, too. But did you take a look at the usbmon >> > traces Markus acquired? >> > >> > http://marc.info/?l=linux-usb&m=131845614819045&w=2 >> >> I glanced at them for 3 seconds, but I cannot be bothered >> to analyze them in detail. The ASCII usbmon traces don't >> show full USB packet contents anyway so you can't see if >> partial MPEG TS packets are missing. > >> The device transfers data in the "not working" case, it's just that >> the MPEG TS sync byte is not where Markus expects it, which could >> be explained by a partial MPEG TS packet left in the device's FIFO >> from previous interaction. > > But why does this happen only when the transfer size is different from > 24064? Why doesn't it also happen when the transfer size _is_ 24064? > > Alan Stern > Hi Johannes, Alan, My $.02. The problem is bulk packet size is 512 bytes. The moronic device wants packets of 188 bytes. The least common divisor of those two numbers is 24064. Somewhere way back in this thread, I think it said this device sent data to the host via IN packets. So if you asked for anything less than 24062 bytes, say 188*2=376, because the moronic device has to send its 188 packets in 512 byte usb packets, it would do a data overrun, because it would send 512 bytes (device does not know the urb size). Asking for two urbs one of 376 and the other 24064-376 would not work because the first urb would get a transfer error. The solution for this kind of broken device is either, change limits in the usbdevfs (which of course will only fix this one particular weirdo - what if the next weird device chose 187 or even 511?), or make the vendor/community come up with a kernel driver for the bad device. The kernel driver, is of course what they must have used in windows. I would really like to know what virtual machine writers do for guest hosts on this device, I suspect problems. I suspect it would not work with vmware even for a windows guest on a windows host. Maybe it would work if windows allow really big (24064 byte) transfers. In any case, the ability of a windows driver (written of course by the vendor) to work around really broken devices is no help in getting rational, useful devices into the world. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
