Hi, On Thu, Nov 13, 2003 at 12:48:45PM -0500, m. allan noah wrote: > I think i might have found something that could fix the timeout issues, > though i am hard-pressed to believe it is the best solution. It seems that > the USB Fujitsu models we support will fail to function on subsequent > requests, if the current scan does not use an EVEN number of commands > before sane_close().
I have seen a similar bug with the mustek_usb backend. I'll try to describe what's happening there: What you see is that everytime a reset is sent to the USB device, they should reset their toggle (=DATA0). The Linux (and other OS) drivers set their toggle to DATA0 also. Well, those devices (e.g. Mustek SCanEpxress 600 CU) don't do that. So if the toggle is not already on data0, the device just times out. With the kernel scanner driver a reset is only sent when the device is plugged in (or the driver is loaded). So it ususally doesn't occur in normal use. Only if you unload the scanner module and reload it it happens. With libusb the reset is done after every open (?), so you can only open the scanner once and then have to replug it. That's a hardware bug in the Mustek chipset (in my opinion). It also happens on Windows when the device is (by software) "replugged". I'm not sure if it's the same problem. Counting the packets sounds like a cool hack. I'll check if that's possible for the mustek_pp backend, too. However, at least the scanner module splits bigger packets into smaller ones, so the count may not be correct in that case. Bye, Henning
