[cc-ed to new mailing list] [email protected] 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
