[sane-devel] Canon FS4000

eric@b.org eric.bachard at free.fr
Sat Sep 20 14:05:46 BST 2003


abel deuring a écrit:
> [cc-ed to new mailing list]
> sane-find-scanner detects the Canon scanner by sending a ACAI INQUIRY 
> command to each SG device. The INQUIRY commands returns the data you 
> also see from "rescan scsi bus" output: Things like device type and 
> vendor/device name.

rescan-scsi-bus.sh ask to the SG devices (through sg module I think) , 
and this one can answer something correct, because the question is very 
"basic" (I mean it's not a (e.g.) Canon-specific command).
Is this correct ?

What I thought is something else :

eric at tomate:/usr/src/linux/drivers/usb$ egrep -H FS4000 ./* 2>/dev/null
./scanner.h:	{ USB_DEVICE(0x04a9, 0x3042) }, /* FS4000US */

So the name of the FS4000 from Canon is officialy in the kernel 
(2.4.23pre4 for me)...
It 's only a declaration, with good ids. But is it usable anyway ?

> scanimage -L loads all installed backends and asks each of them, if it 
> detected any _supported_ scanner. The backends for SCSI scanners send an 
> INQUIRY command to the device, and compare vendor name, device name etc. 
> with a backend specific list of supported devices.
> Assuming that the command set of the FS4000 is similar to that of the 
> Canon FS2700, which is supported by Sane, you could try to modify the 

Hummmm, yes I've found something interessant in the VueScan Doc :

./vuescan.htm-What's new in version 7.6.30
./vuescan.htm:<LI>Fixed problem with Canon FS4000 infrared cleaning
./vuescan.htm-<LI>Fixed problem with ScanWit 2740S infrared cleaning

Interessant, a bug corrected twice :-)

Same chipset ?

> Canon backend so that it will detect your scanner. It is not likely that 

I'll take this way : look at the FS2700 backend for write the FS4000.

> this will be the only required patch, but it might be a start to get the 
> FS4000 running with Sane -- at least via a SCSI adapter.

Ok : scanimage loads a backend, and sane-find-scanner/rescan-scsi-bus.sh 
use generic commands directly.

> I think that I've heard somewhere that vuescan is able to print the SCSI 
> commands sent to a scanner. If this is true, you can compare the 
> commands sent by vuescan and by the Canon backend. This may give you 
> some idea, how you must patch the Canon backend to get the FS4000 running.

It is a very, very important information for me. Thank you. I'll search 
immediatly other informations.

Above, result of :

strings /usr/local/vuescan/vuescan...



sanei_scsi.issue: %p
cat /proc/scsi/sg/debug 1>&2
j < 2
scsi_req_enter: entered %p
src_size == cmd_size
src_size >= cmd_size
get_max_buffer_size for %s: %i
sanei_scsi_open: timeout value must be between 1 and 1200 seconds
sanei_scsi_open: sanei_scsi_max_request_size=%d bytes
sanei_scsi_open: open of `%s' failed: %s
sanei_scsi_open: SG driver version: %i
sanei_scsi_open: The file %s is not an SG device file
sanei_scsi_open: The device found for %s does not look like a scanner
sanei_scsi_open: cannot read SG buffer size - %s
sanei_scsi_open_extended: using %i bytes as SCSI buffer
trying to enable low level command queueing
sanei_scsi_open: Host adapter queue depth: %i
sanei_scsi_open: using old SG driver logic
sanei_scsi_open: SG driver can change buffer size at run time
sanei_scsi_open: low level command queueing enabled
sanei_scsi_open: using new SG header structure
sanei_scsi_open: could not allocate SG buffer memory wanted: %i got: %i
sanei_scsi.issue: bad write (errno=%i) %s %i
sanei_scsi.issue: SG_BIG_BUF inconsistency? Check file PROBLEMS.
issue: ENOMEM - cannot queue SCSI command. Trying again later.
issue: EAGAIN - cannot queue SCSI command. Trying again later.
sanei_scsi_req_enter: failed to malloc %lu bytes
sanei_scsi_req_enter2: ioctl to set command length failed
sanei_scsi_req_enter2 warning: truncating write data from requested %i 
bytes to allowed %i bytes
scsi_req_enter: queue_used: %i, queue_max: %i
req == ((fdparms*)fd_info[req->fd].pdata)->sane_qhead
sanei_scsi_req_wait: waiting for %p
sanei_scsi_req_wait: read %ld bytes
sanei_scsi_req_wait: read returned %ld (errno=%d)
sanei_scsi_req_wait: SCSI command complained: %s
sense buffer: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x 
%02x %02x %02x %02x %02x
target status: %02x host status: %02x driver status: %02x
target status: %02x host status: %04x driver status: %04x
sanei_scsi_req_wait: SG driver returned resid %i
                      NOTE: This value may be bogus
lx_chk_id: %d,%d  %d,%d  %d,%d  %d,%d
lx_scan_sg: k=%d, exclude=%d, missed=%d
lx_chk_devicename: matched device(devfs): %s
lx_chk_devicename: matched device(direct): %s
lx_chk_devicename: matched device(scan): %s
could not open %s for reading
sanei_scsi_find_devices: vendor=%s model=%s type=%s
	bus=%d chan=%d id=%d lun=%d  num=%d
sanei_config_open: attempting to open `%s'
sanei_config_open: using file `%s'
sanei_config_open: could not find config file `%s'
[%s] %s
Setting debug level of %s to %d.
[sanei_debug] malloc() failed


I don't understand why the sane API seems to be used. Can someone help me ?

BTW : is it possible to give any option with VueScan ? I'll read again 
the doc too...

>> modinfo say me to load the scsi_debug module with :
>> modprobe scsi_debug scsi_debug_opts 4
> I think that the scsi_debug kernel module installs a virtual SCSI disk. 
> That can be handy for debugging the kernel's SCSI system and perhaps for 
> file system debugging, but such a device will not help you very much 
> with tracing the SCSI commands and associated data.

Bad way again for me... :-(

Thank you very much for all the tips you've given to me...


eric bachard


More information about the sane-devel mailing list