[sane-devel] Problems with libusb and Snapscan 1236U (maybe similar to others): USB dump
Fri, 5 Mar 2004 17:07:27 +0100
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
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
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.