[sane-devel] Canon FS4000

[abel deuring]

[cc-ed to new mailing list]

eric at b.org wr6te:

> First rescan the scsi bus :
> 
> Host adapter 2 (scsi_debug) found.
> Scanning for device 1 0 1 0 ...
> OLD: Host: scsi1 Channel: 00 Id: 01 Lun: 00
>       Vendor: CANON    Model: IX-40015G        Rev: 1.07
>       Type:   Scanner                          ANSI SCSI revision: 02
> Scanning for device 1 0 6 0 ...
> OLD: Host: scsi1 Channel: 00 Id: 06 Lun: 00
>       Vendor:          Model: Scanner          Rev: 1.60
>       Type:   Scanner                          ANSI SCSI revision: 04
> 
> Sane-find-scanner can see the FS4000 too !  :

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.

> 
>  tomate:/home/eric# sane-find-scanner
> # Note that sane-find-scanner will find any scanner that is connected
> # to a SCSI bus and some scanners that are connected to the Universal
> # Serial Bus (USB) depending on your OS. It will even find scanners
> # that are not supported at all by SANE. It won't find a scanner that
> # is connected to a parallel or proprietary port.
> 
> sane-find-scanner: found SCSI scanner "CANON IX-40015G 1.07" at device 
> /dev/sg2
> 
> But (?)
> 
> tomate:/home/eric# scanimage -L
> device `microtek:/dev/sg10' is a Microtek ScanMaker E3 flatbed scanner
> 
> And there is no FS4000 more...

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 
Canon backend so that it will detect your scanner. It is not likely that 
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.

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.

> tomate:/home/eric# tail -f /var/log/kern.log
> Sep 19 21:32:01 tomate kernel: scsi singledevice 0 0 6 0
> Sep 19 21:32:01 tomate kernel: scsi singledevice 0 0 7 0
> Sep 19 21:32:59 tomate kernel: scsi2 : scsi_debug, Version: 0.61 
> (20020815), num_devs=1, dev_size_mb=8, opts=0x0
> Sep 19 21:32:59 tomate kernel:   Vendor: Linux     Model: scsi_debug     
> Rev: 0004
> Sep 19 21:32:59 tomate kernel:   Type:   Direct-Access     ANSI SCSI 
> revision: 03
> Sep 19 21:33:51 tomate kernel: (scsi1:1:0) parity error
> Sep 19 21:33:55 tomate kernel: scsi : 2 hosts left.
> Sep 19 21:33:59 tomate kernel: scsi2 : scsi_debug, Version: 0.61 
> (20020815), num_devs=1, dev_size_mb=8, opts=0x0
> Sep 19 21:33:59 tomate kernel:   Vendor: Linux     Model: scsi_debug     
> Rev: 0004
> Sep 19 21:33:59 tomate kernel:   Type:   Direct-Access     ANSI SCSI 
> revision: 03
> Sep 19 21:36:20 tomate kernel: (scsi1:1:0) datai sempty 
> timeout<3>(scsi1:1:0) fifos should be empty and phase should have changed
> Sep 19 21:36:20 tomate kernel: (scsi1:1:0) manual transfer count differs 
> from automatic 
> (count=56320;stcnt=56460;diff=140;fifostat=132)<3>(scsi1:1:0) parity error
> 
> 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.

Abel