sane-st400 man page
sane-st400 — SANE backend for Siemens ST/Highscan flatbed scanners
The sane-st400 library implements a SANE (Scanner Access Now Easy) backend that provides access to Siemens ST400 flatbed scanners and compatibles. At present, the following scanners are supported by this backend:
Siemens ST400 (6 bit gray scale)
Siemens ST800 (6 bit gray scale)
The driver supports line art and gray scans up to 8bpp.
The Siemens ST/Highscan series includes several more models, e.g. the ST300 and ST600. If you own one of these scanners, or a scanner other than the ones listed above that works with this backend, please let us know by sending the scanner's model name, SCSI ID, and firmware revision to email@example.com. Have a look at http://www.sane-project.org/mailing-lists.html concerning subscription to sane-devel.
This backend expects device names of the form:
Where special is either the path-name for the special device that corresponds to a SCSI scanner. For SCSI scanners, the special device name must be a generic SCSI device or a symlink to such a device. Under Linux, such a device name could be /dev/sga or /dev/sge, for example. See sane-scsi(5) for details.
The contents of the st400.conf file is a list of device names that correspond to Siemens scanners. Empty lines and lines starting with a hash mark (#) are ignored. A sample configuration file is shown below:
# this is a comment
The default configuration file that is distributed with SANE looks like this:
scsi SIEMENS "ST 400" Scanner * * 3 0
In this configuration, the driver can only access the ST400 model at SCSI ID 3 LUN 0 (see section "Bugs" below for the reason). To use the driver with other scanner models, add an appropriate line to the configuration file. For example, to use it with an ST800 at SCSI ID 3 LUN 0, add the line:
scsi SIEMENS "ST 800" Scanner * * 3 0
The backend configuration file (see also description of SANE_CONFIG_DIR below).
The static library implementing this backend.
The shared library implementing this backend (present on systems that support dynamic loading).
This environment variable specifies the list of directories that may contain the configuration file. Under UNIX, the directories are separated by a colon (`:'), under OS/2, they are separated by a semi-colon (`;'). If this variable is not set, the configuration file is searched in two default directories: first, the current working directory (".") and then in /etc/sane.d. If the value of the environment variable ends with the directory separator character, then the default directories are searched after the explicitly specified directories. For example, setting SANE_CONFIG_DIR to "/tmp/config:" would result in directories "tmp/config", ".", and "/etc/sane.d" being searched (in this order).
If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. E.g., a value of 128 requests all debug output to be printed. Smaller levels reduce verbosity.
Everything but the most basic stuff.
Currently, the backend does not check if the attached device really is a ST400. It will happily accept everything that matches the configuration entries. This makes it easy to test the backend with other scanners: Just add an appropriate line to the configuration file. The configuration file as distributed (see above) only works with the ST400. Be careful: If there is no config file at all, the backend defaults to /dev/scanner.
The ST400 answers on all eight SCSI LUNs. Normally this is not a problem, as LUN support is usually disabled in SCSI drivers, but if you are seeing multiple instances of the scanner in a device list, either disable LUNs in your SCSI setup or change the entry in the configuration file to match LUN 0 only.
If you encounter a bug please set the environment variable SANE_DEBUG_ST400 to 128 and try to regenerate the problem. Then send me a report with the log attached.
If you encounter a SCSI bus error or trimmed and/or displaced images please also set the environment variable SANE_DEBUG_SANEI_SCSI to 128 before sending me the report.
Ingo Wilken <Ingo.Wilken@informatik.uni-oldenburg.de>