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
