[sane-devel] Problems with libusb and Snapscan 1236U (maybe similar to others): USB dump

[Henning Meier-Geinitz]

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