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

[m. allan noah]

yes, this is what i see the fujitsu windows driver do. however, i have had 
some trouble getting this to work reliably, i dont know if kernel keeps 
toggle at 0 for some reason?

i will try again.

allan

On Tue, 24 May 2005, Bertrik Sikken wrote:

> 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. :-)
>>>
>>>
>>
>
>
>

-- 
"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