Provided by: libsane_1.0.19-6ubuntu1_i386
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
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 firstname.lastname@example.org. Have a look at
http://www.sane-project.org/mailing-lists.html concerning subscription
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
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
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>