[sane-devel] libusb - problems with open/close of device in backend?

[m. allan noah]

On Tue, 24 May 2005, Olaf Meeuwissen wrote:

> "m. allan noah" <anoah@pfeiffer.edu> writes:
>
>> steven, i see this exact problem with certain fujitsu scanners.
>
> It also manifests itself with several EPSON scanners as described in
>
>  http://lists.alioth.debian.org/pipermail/sane-devel/2004-June/011233.html
>  http://alioth.debian.org/tracker/index.php?func=detail&aid=300830&group_id=30186&atid=410366.
>
>> you have three options that i see:
>>
>> 1. count the number of data packets you are sending to scanner, and
>> always send an even number. remember that just cause you sent or read
>> 16 k of data, does not matter, it was busted up by lower layers. you
>> need this larger number of smaller packets.
>>
>> 2. get kernel/libusb to keep current toggle instead of trashing it.
>>
>> 3. call usb_reset(device) as the very last step before you exit. this
>> will cause the device to re-enumerate, and reset all of its internal
>> data. while ugly, this works for me everytime. there are other
>> functions like usb_clearhalt and usb_resetep, but those dont seem to
>> fix my problem.
>
> For the record, apart from blithely ignoring the libusb spec, this
> will break on RH9 (at least).  Calling usb_reset() results in a new
> entry below /proc/ with a different device number :-(

so what. if the device does not follow the spec, why should we? you know 
as well as i do that users just want it to work. if we can really point 
the finger at the device and say that it is not linux kernel/libusb that 
causes this problem, then we have no other choice. smack the scanner with 
a stick cause it's stupid. if it is the kernel that is the problem, or if 
we can get the kernel extended with an option that causes it to save the 
value of the toggle across close(), then is that any more or less a 
violation of the spec? i dont know.

allan

>
>> my advice? write a little prog that uses libusb directly, and try to
>> do simple things outside the confines of sane.
>>
>> allan
>>
>> On Mon, 23 May 2005, Steven Palm wrote:
>>
>>> Still working on the microtek2 backend stuff for libusb...
>>>
>>> It seems that the odd issues I'm encountering will go away if I
>>> don't ever close the USB device. If I leave it open for the duration
>>> of the backend lifetime, scanimage -L will properly identify it. If
>>> I open and close it for each operation, I get timeouts trying to
>>> read responses, and if I increase the response size the scanner will
>>> send back a larger packet which seems to show that I miss the first
>>> block of data (32-bytes for this scanner).
>>>
>>> Is this a problem anywhere else with the libusb stuff?
>>>
>>> Is there harm in leaving the scanner open until sane_exit ?
>>>
>>> At least for now doing this allows scanimage -L to find the scanner.
>>> That is good.  However, another glitch is cropping up when I try to
>>> send the system_status block back to the scanner... The USB log
>>> shows the transmission is without error, but after that point I get
>>> no more response from the scanner to the remaining commands. The odd
>>> thing is, I've not changed anything about the logic of what is being
>>> sent to the scanner, just sending it via libusb instead of writing
>>> to the fd of the linux kernel scanner driver. Oh well. :-)
>>>
>>>
>>
>> --
>> "so don't tell us it can't be done, putting down what you don't know.
>> money isn't our god, integrity will free our souls" - Max Cavalera
>>
>> --
>> sane-devel mailing list: sane-devel@lists.alioth.debian.org
>> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
>> Unsubscribe: Send mail with subject "unsubscribe your_password"
>>              to sane-devel-request@lists.alioth.debian.org
>>
>
>

-- 
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera