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

[Bertrik Sikken]

What about exchanging some dummy packets after an open to get back
in sync w.r.t. the toggle bit? (for example some simple commands
that are normally used to get status info)

I've seen the toggle problem for a device connected to windows.
Sending the first packet twice from the device to the PC fixed
the toggle problem.

Kind regards,
Bertrik Sikken

m. allan noah wrote:
> steven, i see this exact problem with certain fujitsu scanners. the
> difficulty is that USB uses a 0/1 toggling bit during the data transmit
> phase. when libusb closes the device, the device should reset the toggle
> back to 0, the kernel does. subsequent transmissions should start with
> toggle set to 0, but if device thinks it should be 1, then device
> ignores packets. windows never closes the device (the driver loads at
> bootup) so the fujitsu engineers had no idea what i was talking about
> (though i note that later usb2.0 fujitsu scanners do not have this problem)
> 
> 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.
> 
> 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. :-)
>>
>>
>