[sane-devel] fujitsu duplex scan with usb
m. allan noah wrote: > most scsi commands that use a data block after the command block (mode > select, set window, scan) are formatted differently when sent via usb. the > command block is sent first, in a single urb, padded to 31 bytes with null > bytes. then the data block(s) are sent in another urb, not padded. > > the existing fujitsu code is very scsi specific, and only uses one buffer > for scsi cmd/data to the do_cmd() function. this means that the caller has > to either pad the single buffer with just the right number of 0's in the > middle of the buffer, or the do_usb_cmd() function will have to break the > buffer inhalf, and pad the data itself. It's perhaps reasonable to call sanei_scsi_cmd2 instead of sanei_scsi_cmd. The former function needs/wants different buffers for the CDB and the write data. All OS specific SCSI interfaces (except the old Linux SG interface) use different buffers anyway, and in many cases the backends have also different buffers for CDB and data, so I expect that you can also avoid a few memcpy calls. And inside sanei_scsi, the function sanei_scsi_cmd tries to guess the CDB size and then calls sanei_scsi_cmd2 anyway. Abel
[sane-devel] fujitsu duplex scan with usb
Hi, On Tue, Apr 06, 2004 at 09:06:12AM -0400, m. allan noah wrote: > agreed, just committed an updated version. please check. but i get this > error: henning? > > Checking in doc/descriptions/fujitsu.desc; > /cvsroot/sane/sane-backends/doc/descriptions/fujitsu.desc,v <-- > fujitsu.desc > new revision: 1.13; previous revision: 1.12 > done > U descriptions/fujitsu.desc > /bin/sh: sane-backends.html: Permission denied > make: *** [sane-backends.html] Error 1 That should be fixed now. After the alioth move I accidently did a "make" without setting umask accordingly. Bye, Henning
[sane-devel] fujitsu duplex scan with usb
Thanks, I think the status of the fujitsu scanners with USB interface should not be reported 'good'. Oliver Am Montag 05 April 2004 22:23 schrieb m. allan noah: > so, i tracked it down using usb snoopy in windows. the problem is simple > to explain, but harder to fix: > > most scsi commands that use a data block after the command block (mode > select, set window, scan) are formatted differently when sent via usb. the > command block is sent first, in a single urb, padded to 31 bytes with null > bytes. then the data block(s) are sent in another urb, not padded. > > the existing fujitsu code is very scsi specific, and only uses one buffer > for scsi cmd/data to the do_cmd() function. this means that the caller has > to either pad the single buffer with just the right number of 0's in the > middle of the buffer, or the do_usb_cmd() function will have to break the > buffer inhalf, and pad the data itself. > > for an example, see fujitsu_set_sleep_mode(). > > you see this problem only with scanning duplex or back side because the > code at line 3112 (talks about opcode==SCAN) is wrong. it should take the > last one or two bytes and send as adifferent urb, rather than assuming 00. > > i have started a new version of the fujitsu backend, which uses a command > and a data buffer to do_cmd() but have been far too busy to make much > headway. take a shot if you would like.
[sane-devel] fujitsu duplex scan with usb
agreed, just committed an updated version. please check. but i get this error: henning? Checking in doc/descriptions/fujitsu.desc; /cvsroot/sane/sane-backends/doc/descriptions/fujitsu.desc,v <-- fujitsu.desc new revision: 1.13; previous revision: 1.12 done U descriptions/fujitsu.desc /bin/sh: sane-backends.html: Permission denied make: *** [sane-backends.html] Error 1 allan On Tue, 6 Apr 2004, Oliver Schirrmeister wrote: > > Thanks, > I think the status of the fujitsu scanners with USB interface should not > be reported 'good'. > > Oliver > > Am Montag 05 April 2004 22:23 schrieb m. allan noah: > > > so, i tracked it down using usb snoopy in windows. the problem is simple > > to explain, but harder to fix: > > > > most scsi commands that use a data block after the command block (mode > > select, set window, scan) are formatted differently when sent via usb. the > > command block is sent first, in a single urb, padded to 31 bytes with null > > bytes. then the data block(s) are sent in another urb, not padded. > > > > the existing fujitsu code is very scsi specific, and only uses one buffer > > for scsi cmd/data to the do_cmd() function. this means that the caller has > > to either pad the single buffer with just the right number of 0's in the > > middle of the buffer, or the do_usb_cmd() function will have to break the > > buffer inhalf, and pad the data itself. > > > > for an example, see fujitsu_set_sleep_mode(). > > > > you see this problem only with scanning duplex or back side because the > > code at line 3112 (talks about opcode==SCAN) is wrong. it should take the > > last one or two bytes and send as adifferent urb, rather than assuming 00. > > > > i have started a new version of the fujitsu backend, which uses a command > > and a data buffer to do_cmd() but have been far too busy to make much > > headway. take a shot if you would like. > > > -- "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] fujitsu duplex scan with usb
yes, i have the oem manual, i will send in a separate email. however, it will not fix the problem, as the usb-specific documentation is about 1 page long, and completely useless. i have spoken with several people at fujitsu, but they insist there is no other documentation. so, i tracked it down using usb snoopy in windows. the problem is simple to explain, but harder to fix: most scsi commands that use a data block after the command block (mode select, set window, scan) are formatted differently when sent via usb. the command block is sent first, in a single urb, padded to 31 bytes with null bytes. then the data block(s) are sent in another urb, not padded. the existing fujitsu code is very scsi specific, and only uses one buffer for scsi cmd/data to the do_cmd() function. this means that the caller has to either pad the single buffer with just the right number of 0's in the middle of the buffer, or the do_usb_cmd() function will have to break the buffer inhalf, and pad the data itself. for an example, see fujitsu_set_sleep_mode(). you see this problem only with scanning duplex or back side because the code at line 3112 (talks about opcode==SCAN) is wrong. it should take the last one or two bytes and send as adifferent urb, rather than assuming 00. i have started a new version of the fujitsu backend, which uses a command and a data buffer to do_cmd() but have been far too busy to make much headway. take a shot if you would like. allan On Fri, 26 Mar 2004, Oliver Schirrmeister wrote: > Hi, > > has anybody tried to do a duplex scan with a fujitsu fi-4x20 > and USB interface? > > I've tried > scanimage --duplex both >/tmp/out > > and the scanner returns and error in the start_scan command > block. I can't see what's wrong. The same block with SCSI > works fine. Siplex scanning with USB works as well. > > Any ideas? > > Alan, don't you have the oem manual of that scanner? Can > you mail that to me? > > Thanks > > Oliver > > > -- "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] fujitsu duplex scan with usb
Hi, has anybody tried to do a duplex scan with a fujitsu fi-4x20 and USB interface? I've tried scanimage --duplex both >/tmp/out and the scanner returns and error in the start_scan command block. I can't see what's wrong. The same block with SCSI works fine. Siplex scanning with USB works as well. Any ideas? Alan, don't you have the oem manual of that scanner? Can you mail that to me? Thanks Oliver