Hi,
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@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-<UL>
./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...
##########################
<..cut...>
sanei_scsi
SANE_SG_BUFFERSIZE
/proc/sys/kernel/sg-big-buff
SANE_SCSICMD_TIMEOUT
Processor
sanei_scsi.issue: %p
cat /proc/scsi/sg/debug 1>&2
sanei_scsi_req_flush_all
sanei_scsi.c
j < 2
scsi_req_enter: entered %p
sanei_scsi_req_wait
/dev/gsc
/dev/uk
/dev/sg
%s%c
Vendor:
Model:
Type:
Rev:
Channel:
Lun:
/proc/scsi/scsi
sanei_scsi_req_enter
src_size == cmd_size
src_size >= cmd_size
sanei_scsi_cmd
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
/dev/scsi/host%d/bus%d/target%d/lun%d/generic
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
SANE_CONFIG_DIR
.:/usr/local/etc/sane.d
%s%c%s
sanei_config_open: attempting to open `%s'
sanei_config_open: using file `%s'
sanei_config_open: could not find config file `%s'
sanei_debug
SANE_DEBUG_
[%s] %s
[%s]
Setting debug level of %s to %d.
[sanei_debug] malloc() failed
<...cut...>
######################################
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...
Cheers
eric bachard
--
NO ePATENTS NON AUX BREVETS SUR LES LOGICIELS. Voir / See
http://swpat.ffii.org/
