Hi, On Fri, Mar 05, 2004 at 12:31:17AM +0100, Oliver Schwartz wrote: > I have to admit this is a bit above my head. How do I know how many > urbs are sent / received if I do a bulk transfer? It seems you're > using an estimate in mustek_usb, but how do you know how many bytes > you're transferring in one urb?
With the Mustek MA1017 chip there are only three kind of transfers: 1) Write two bytes of data (to write to a register or to set the register that should be read). I assumed that these two bytes are always in one packet. 2) Read one byte of data (to read a register). Also in one packet obviously. 3) Read bigger chunks of data (calibration, scan data). In this case I assumed that the data is splitted in packets of the maximum transfer size for this scanner which is 64 bytes for the bulk read endpoint: E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I don't know if that could be a wrong assumption e.g. when the transfer of a packet fails. I haven't checked the code of libusb or the kernel but dividing the data into chunks of MaxPacketSize looks reasonable for me. First I tried to split the data myself. That also works but is much slower as libusb uses blocking I/O. I can only submit one packet and have to wait until it's sent. > Even if I find out this number for my scanner model, how would I know > if it is correct for all other scanner modules the backend supports? Do you need this ugly hack at all? I'd be surprised if this MA1017 chipset bug was that common. To repeat: It's a bug in the Mustek MA1017 chip, not the kernel nor the USB host controller. None of the other USB scanners I have shows this behaviour. If you don't have trouble with libusb on 2.4 or the kernel scanner driver on 2.4.25 it's a different problem. > I must say I quite dislike the whole idea of making an estimate on the > number of urbs in the backend. Shouldn't this be handled in libusb > directly? Or in the kernel. But It's really chipset-specific so I don't think it should be handled anywhere but in applications that use that chipset. Another work-around would be to not reset the USB device when closing it. But this may be bad for other USB devices. Bye, Henning
