SDB:Configuring Scanners from SUSE LINUX 9.2
İçindekiler
Concern
You want to configure your scanner.
Procedure
Basic information is available in the SUSE LINUX 9.2 manuals.
The following paragraphs provide further information regarding the technical background and the manual configuration.
At the end some important differences of SUSE LINUX 9.2 compared to SUSE LINUX 9.1 are listed.
For special notes regarding SUSE LINUX 9.3 see the article: SDB:Configuring Scanners from SUSE LINUX 9.3
To limit the complexity of this article, only USB scanners are focused on.
- Information that does not specifically apply to USB also applies to SCSI and parallel-port scanners.
For SCSI scanners, see "man sane-scsi" and SDB:SCSI Scanner Is Not Detected in SUSE LINUX 9.1. For parallel-port scanners, see the man page for the respective backend (see section "SANE Backends" below) and the information in the manual regarding the setup of the parallel port. Though the file names have changed (e.g., the file /etc/modules.conf has been renamed to /etc/modprobe.conf), the information still applies.
Basics
The "SANE Project" delivers the central software for operating scanners: http://www.sane-project.org/
The software consists of "SANE-backends" and "SANE-frontends". In SUSE LINUX, you can find this software in the "sane" package.
The SANE backends constitute the actual hardware drivers for the various scanner types; see http://www.sane-project.org/sane-backends.html.
A backend can support various models if the various models can be addressed in the same way. Such models are compatible to each other to a certain extend because they understand the same "language". Depending on the backend this language is of different kind:
- It is a primitive kind of language when the backend must directly write specific values into the chip set which controls the actual scan-unit insisde the scanner. The actual values differ from model to model. Wrong values may cause poor scan quality or may even damage the scanner. Examples: The models which are supported by the "plustek" backend.
- Well built scanners have a real "scanner-language" built in. It is much easier and much more secure to drive such a scanner. Examples: The models which are supported by the "epson" backend.
SANE stands for "Scanner Access Now Easy". By way of the "libsane" library, SANE provides a uniform API (application programming interface), enabling applications to have uniform access to various scanner models.
Applications that use a SANE backend to access a scanner are referred to as SANE frontends or simply frontends.
In addition to the SANE frontends (scanimage, xscanimage), the uniform interface enables the use of other front-ends like XSane and the KDE front-end Kooka ("kdegraphics3-scan" package).
Rather than accessing the scanner hardware directly, a backend uses the kernel together with various subsystems for the data transmission to the scanner hardware. For example, the access to a USB scanner involves the following subsystems in addition to to the kernel:
- PAM (pluggable authentication modules)
- resmgr (resource manager)
- libusb (library for the access to USB devices)
- hotplug (automatic activation of hotplug devices)
Thus, a stack consisting of various layers must be functional in its entirety in order to enable users to access a USB scanner from an application:
User | Application (frontend) | SANE backend | libusb | resmgr <-- PAM <-- user login | USB kernel modules <-- hotplug <-- scanner plug-in | USB hardware in the machine | USB cable connection (additional USB hubs if necessary) | Scanner
The operability of all lower layers is a precondition for the operability of a higher layer. Therefore, the individual layers or subsystems are discussed from the bottom up.
Scanner
Check [file:///usr/share/doc/packages/sane/sane-backends/sane-mfgs.html /usr/share/doc/packages/sane/sane-backends/sane-mfgs.html] to see whether a SANE backend is available for your scanner in your installed SANE version. Please note that the accuracy of this information cannot be guaranteed. For example the vendor may use the same model name for various device variants, some of which may not be supported (e.g., see the information on "Artec/Ultima 2000").
Additionaly you may check http://www.sane-project.org/sane-mfgs.html to see whether a SANE backend is available for your scanner. The information at this site represents the latest state of the SANE software. However, please note that the accuracy of this information cannot be guaranteed. Possibly the SANE version included in your SUSE LINUX version does not yet support your scanner.
Which scanner models are supported or not supported to what degree by which backend of your installed SANE version is listed here: [file:///usr/share/doc/packages/sane/sane-backends/sane-backends.html /usr/share/doc/packages/sane/sane-backends/sane-backends.html]
The above HTML files are made from description files for each backend: /usr/share/sane/descriptions/"backend".desc
The format of the entries is as follows:
:mfg "Vendor A" :model "Model 1" :interface "USB" :status :complete :model "Model 2" :interface "SCSI" :status :good :mfg "Vendor B" :model "Model X" :interface "Parport" :status :minimal :model "Model Y" :interface "IEEE-1394" :status :untested :model "Model Z" :interface "Proprietary" :status :unsupported
A considerable number of scanners are supported only by means of a so called "external backend"; see [file:///usr/share/doc/packages/sane/sane-backends/sane-mfgs-external.html /usr/share/doc/packages/sane/sane-backends/sane-mfgs-external.html] and [file:///usr/share/doc/packages/sane/sane-backends/sane-backends-external.html /usr/share/doc/packages/sane/sane-backends/sane-backends-external.html] and for the latest information see http://www.sane-project.org/lists/sane-backends-external.html
- As external backends are not part of the software of the SANE project, they are not included in the "sane" package.
- SUSE LINUX 9.2 includes two packages containing external backends:
The free "HPOJ" driver software from HP in the "hp-officeJet" package. As this is free software, the package is installed by default. This software supports most HP all-in-one devices (printer + scanner) via the PTAL service and the "hpoj" backend. In this case there is one more additional subsystem "PTAL" which must be configured and activated. The configuration can be done with YaST, but may require some manual customizing regarding PTAL - in particular the configuration of the printing-unit may have to be changed from USB to PTAL. For SUSE LINUX 9.2 there is an update "hp-officeJet" package available which fixes a bug regarding the activation of PTAL. For further information see SDB:Set up a HP OfficeJet ("all-in-one" device) (the latter reflects the latest state of the HPOJ software from HP).
- The partly free "Image Scan" driver software from Epson in the "iscan" package which provides the "epkowa" backend. Observe the license terms in the file /usr/share/doc/packages/iscan/COPYING.KOWA (see "rpm -qi iscan"). As this is proprietary software, the package is not installed by default. The configuration must be done manually. Some scanners are supported both by the "epson" backend and the "epkowa" backend. YaST only uses the "epson" backend. During the installation of the "iscan" package, the "epkowa" backend is automatically activated in /etc/sane.d/dll.conf. If necessary, deactivate the undesired back-end in /etc/sane.d/dll.conf (see section "SANE Backends" below). Regarding the configuration, see "man iscan", "man sane-epkowa", /usr/share/doc/packages/iscan/userg_e.pdf, and http://www.epkowa.co.jp/english/linux_e/index.html (the latter reflects the latest state of the Image Scan software from Epson).
For SUSE LINUX 9.3 see SDB:Configuring Scanners from SUSE LINUX 9.3
- For every external backend, the description file /usr/share/sane/descriptions-external/"backend".desc shows which scanner models are supported or not supported to what degree.
Some scanners do not work if no suitable firmware (software in the scanner that controls the device hardware) is loaded into the scanner when it is powered on. For such awkward models, you need to get the suitable firmware (ask the vendor of the scanner) and configure the backend for the firmware upload (see section "SANE Backends" below). As firmware is licensed by the device vendor, we are not allowed to distributed firmware with SUSE LINUX unless the vendor makes the firmware available for distribution and redistribution under a free license. With normal scanners, the firmware is stored permanently in the device. Thus, the scanner is ready to use as soon as it is powered on.
If no SANE backend is available for the scanner (see http://www.sane-project.org/sane-backends.html#S-UNSUPPORTED and /usr/share/sane/descriptions/unsupported.desc), the device cannot be used with one of the common frontends (scanimage, xscanimage, xsane, kooka). Possibly there may be other software (e.g., directly from the vendor - ask the vendor about this). If not, the device cannot be used.
USB Cable Connection and Additional USB Hubs
Maximum length of USB cables:
- Inexpensive low-speed cables (not twisted, not shielded): No more than 3 meters. Not suitable for fast data transfer (USB 2).
- Higher-quality full-speed and high-speed cables (twisted, shielded): No more than 5 meters.
- If a USB hub is interposed, the maximum length may be shorter, depending on the properties of the cable and the hub.
Some scanners do not have a built-in power supply but draw power via USB. If your USB system does not provide enough power, a scanner of this kind will not work. In this case, try if it works with an interposed USB hub with a separate power supply.
USB Hardware + USB Kernel Modules + hotplug
A USB scanner must be displayed by the following commands:
- /sbin/lsusb
- cat /proc/bus/usb/devices
If these commands do not display the scanner model, the data transfer between the machine and the scanner cannot work because the kernel could not recognize the USB device or not all required USB kernel modules were loaded.
To test the system in the event of problems, connect the scanner directly to the machine as the only USB device (apart from the USB keyboard and USB mouse, in case you use such). Then reboot the system while keeping the scanner switched on. Normally, hotplug makes sure that the needed USB kernel modules are loaded automatically. Immediately after the reboot, view the USB kernel messages with "dmesg | grep -i usb" and look for any error messages such as "error" or "fail".
Check if the USB kernel modules needed for the machine's USB hardware are loaded. Check if your machine's USB hardware (i.e., the USB chipset) is supported. The command "lspci | grep -i usb" lists the USB controllers. See http://www.linux-usb.org/.
libusb + resmgr + PAM
Note that the details change from version to version. Additionally there will be further enhancements (e.g. "udev", "HAL", ...). An article regarding scanner setup cannot describe all the details about USB, hotplug, udev, HAL, resmgr, PAM, and so on. Refer to the appropriate specific documentation if there are problems in one of these areas.
A backend accesses a USB scanner via libusb. This takes place via /proc/bus/usb/xxx/yyy (or via /sys/bus/usb/devices/) where xxx (bus ID) and yyy (device ID) are no fixed values. Since kernel 2.6, no static device file (like /dev/usbscanner which was used with kernel 2.4) is used for the access via libusb. Rather, the entries in /proc/bus/usb/ are generated anew every time the system is booted. Therefore, access permissions can no longer be set permanently with "chmod".
libusb uses resmgr to check the access permissions (libusb is linked against libresmgr; see "ldd /usr/lib/libusb.so").
/etc/resmgr.conf determines which users are permitted to access which USB devices:
class desktop ... # By default, grant access to all USB devices # except for HID and hub devices exclude usb:class=3 desktop exclude usb:class=9 desktop add usb:any desktop # This rule grants access to users logged in locally allow desktop tty=/dev/tty[1-9]* || tty=tty[1-9]* || tty=:0
All USB devices except for devices of the USB device classes
- 3: HID (human interface devices), i.e. keyboards and mice
- 9: Hubs
are added to the resmgr class "desktop". Access to the devices in the resmgr class "desktop" is permitted if the user logs in as follows:
- Via text console (tty=...tty[1-9]*)
- Via graphical login with XDM or KDM (tty=:0 - i.e. only for the first X session)
Upon login via the text console or XDM/KDM, resmgr is launched by a PAM module which informs the resmgr about the login. This is determined in the following PAM configuration files:
- By default for login via the text console in /etc/pam.d/login
- By default for login via XDM/KDM in /etc/pam.d/xdm and /etc/pam.d/xdm-np
- Optionally for login via ssh in /etc/pam.d/sshd
In this way, only locally logged-in users have access by default.
If a user is logged in in such a way that access is permitted, the access is permitted for all processes of this user.
No PAM modules are launched for pseudo-terminals (pts), as this does not constitute a real login to the system. Therefore, resmgr is not informed in this case. This is important if the graphical user interface is started with "startx" after the login via the text console, as terminal emulation programs like xterm and the KDE terminal emulation make use of pseudo-terminals.
- If the graphical user interface is started with "startx", the user process (the login shell) continues to run in the text console, and the access continues to be permitted under the graphical user interface.
- If the graphical user interface is started with "startx & exit" for security reasons, the user process is terminated in the text console, and the access is no longer possible in the graphical user interface.
- If the graphical user interface is started with "exec startx" for security reasons, the user process continues to run in the text console, and the access continues to be permitted in the graphical user interface. However, the login shell is terminated and replaced by "startx".
Another possibility to set the access permissions via "devgid" and "devmode" in /etc/fstab for the usbfs (USB file system) is described in the man pages for "sane-usb" and "mount". However, a distinction by the USB device class is not possible, and the login type (local or remote) cannot be taken into consideration.
Alternatively you can use "saned" which is a service for scanning via network. On the server the saned is set up and launched via xinetd. On the client the "net" backend is used for scanning via network. See "man saned" and "man sane-net". By using the loopback network this can be used on the local host too. In this case server and client are the same machine "localhost". Some scanners (e.g. parallel port scanners) require root privileges. To access such a scanner as normal user on the local host you may set up the following:
- Let the saned run as root (default in /etc/xinetd.d/sane-port)
- Allow access from "localhost" in /etc/sane.d/saned.conf
- Specify the server "localhost" in /etc/sane.d/net.conf
- Activate the "net" backend in /etc/sane.d/dll.conf
You can limit the access to certain users in /etc/sane.d/saned.users with certain saned-specific passwords. To keep the passwords secret make sure that only root has read-access to this file.
SANE Backends
Every backend has its own configuration file /etc/sane.d/"backend".conf and its own man page: "man sane-backend" ("backend" stands for the name of the respective backend).
One of the backends has a special function: The "dll" backend is a meta-backend (see http://www.sane-project.org/html/doc005.html). The dll backend enables a single frontend to access various scanners by way of other backends. The access takes place as follows:
user
|
frontend
|
------ dll meta-backend ------
| |
backend_A backend_B
| |
... ...
| |
scanner A scanner B
The dll meta-backend is always interposed, even if there is only one scanner.
The backends to be used by the dll meta-backend must be activated as follows in /etc/sane.d/dll.conf, the configuration file of the dll meta-backend:
# SANE Dynamic library loader config backend_A backend_B # backend_C
In this example, the back-ends "backend_A" and "backend_B" are activated and "backend_C" is deactivated.
Normally it should be sufficient only to activate the appropriate backend in /etc/sane.d/dll.conf to make an USB scanner ready to use - provided the USB system and the resmgr work as usual and the backend automatically detects the USB scanner and the scanner has a built-in firmware.
If several backends are activated at the same time, there may be a conflict between the backends (see the paragraph about "Image Scan" in the "Scanner" section above). If this is the case, try if it works if you only activate one backend at a time. In this way you can check whether a backend does not work at all or if the problem is merely caused by a conflict with a certain other backend.
Manual modifications may be necessary in /etc/sane.d/backend.conf depending on the scanner model, the way how it is connected (e.g., via USB or SCSI), and the respective backend. In any case, be sure to read the comments in /etc/sane.d/backend.conf and the man page for the respective backend: "man sane-backend"!
Examples:
- Normally, a backend automatically detects the USB scanners it supports. If this does not happen, it should be possible to add a line such as the following in /etc/sane.d/backend.conf:
usb 0xVVVV 0xMMMM Based on the output of "lsusb", enter the hexadecimal vendor ID for 0xVVVV and the hexadecimal model ID for 0xMMMM. For certain backends the syntax "usb 0xVVVV 0xMMMM" may be different or not available at all, see the man page for the respective backend.
- For SCSI scanners, enter a line such as the following for the SCSI device file in /etc/sane.d/backend.conf:
scsi /dev/sg0 Caution: An incorrect SCSI device file can render your system inoperable!
- For parallel-port scanners, manually enter a line such as one of the following in /etc/sane.d/backend.conf:
ieee1284 parport0 (e.g., in /etc/sane.d/canon_pp.conf) pio 0x378 (e.g., in /etc/sane.d/epson.conf) device 0x378 or parport0 (e.g., in /etc/sane.d/plustek_pp.conf) Caution: An incorrect entry can render your system inoperable!
- For some scanners, suitable firmware must be uploaded into the scanner. Get the suitable firmware file (ask the vendor) and enter the firmware file name in /etc/sane.d/backend.conf. Caution: Unsuitable firmware can damage the scanner!
As a backend is usually suitable for several scanner models, the default settings must reflect the least common denominator of all supported models. Therefore, you may want to optimize the settings for a specific model in /etc/sane.d/backend.conf. Caution: Incorrect settings might damage the scanner!
Frontend
For test purposes, use the command-line frontend "scanimage" (see "man scanimage").
"scanimage -L" should display your scanner. If this does not happen, SANE (more precisely: the backend) is not able to access the scanner. If "scanimage -L" only displays the scanner when the command is executed by the root, only root is able to access the scanner, but not the normal users. In this case, the problem lies in the "libusb + resmgr + PAM" layer. The output of "scanimage -L" for a USB scanner has the following format:
device 'backend-name:libusb:bus-ID:device-ID' ...
For a SCSI scanner:
device 'backend-name:/dev/sg0' ...
"scanimage -d Device >/tmp/image.pnm" prompts the scanner to scan an image and save the result in the file /tmp/image.pnm. Replace "Device" with the output of "scanimage -L". Example:
scanimage -d backend:libusb:123:456 >/tmp/image.pnm
The scanning procedure takes place with the default settings of the respective backend.
"scanimage -d Device -h" lists all available options. The first part lists the general options that do not depend on the respective backend. The second part lists the backend-specific options with the possible values or ranges and the respective default settings in square brackets. Example:
Options specific to device 'backend:libusb:123:456':
Scan Mode:
--mode Gray|Color [Color]
Selects the scan mode.
--resolution 75..600dpi [150]
Sets the resolution of the scanned image.
Geometry:
-l 0..216mm [0]
Top-left x position of scan area.
-t 0..297mm [0]
Top-left y position of scan area.
-x 0..216mm [216]
Width of scan-area.
-y 0..297mm [297]
Height of scan-area.
For example, the command for scanning a b/w picture of 10 x 15 cm in portrait orientation with 300 dpi may be as follows:
scanimage -d backend:libusb:123:456 --mode Gray --resolution 300 -x 100 -y 150 >photo.pnm
Trouble-Shooting (Debugging)
For debugging the debug-messages of the various layers in SANE and the test-mode of "scanimage" are useful. See "man sane-usb", "man sane-scsi", "man sane-dll", "man sane-backend" and "man scanimage". Replace "backend" with the name of the respective backend. Replace "Device" either with the name of the respective backend or with a complete SANE device like "backend:libusb:123:456" (see the "Frontend" section).
Examples:
- Testing without debug-messages:
scanimage -d Device -T && echo OK || echo FAILED
- Testing with only the debug-messages of the "dll" meta-backend (useful when for example the "dll" meta-backend cannot find or load the actual backend or more pecise the backend library "/usr/lib[64]/sane/libsane-backend.so..."):
export SANE_DEBUG_DLL=4 scanimage -d Device -T && echo OK || echo FAILED unset SANE_DEBUG_DLL
- Testing with only the debug-messages of the actual backend (this depends on the particular backend, see "man sane-backend"):
export SANE_DEBUG_backend=128 scanimage -d Device -T && echo OK || echo FAILED unset SANE_DEBUG_backend
- Testing with only the debug-messages of the USB system (regarding SCSI see "man sane-scsi"):
export SANE_DEBUG_SANEI_USB=128 scanimage -d Device -T && echo OK || echo FAILED unset SANE_DEBUG_SANEI_USB
- Combinations are possible but may make it more difficult to find errors because there may be too many debug-messages at once:
export SANE_DEBUG_DLL=4 export SANE_DEBUG_backend=128 export SANE_DEBUG_SANEI_USB=128 scanimage -d Device -T && echo OK || echo FAILED unset SANE_DEBUG_SANEI_USB unset SANE_DEBUG_backend unset SANE_DEBUG_DLL
Important Differences compared to SUSE LINUX 9.1
- The resmgr of SUSE LINUX 9.1 grants access only for those USB devices which are listed in /etc/hotplug/usb/sane-hardcoded.usermap and/or in /etc/hotplug/usb/sane.usermap. YaST should add the USB scanner IDs automatically to /etc/hotplug/usb/sane.usermap. Additionally hotplug is needed to add those devices to the "desktop" device class of the resmgr. Since SUSE LINUX 9.2 all USB devices (except keyboards, mice and hubs) are by default in the "desktop" class (see "libusb + resmgr + PAM"). Nevertheless YaST shows a detailed information regarding USB, hotplug and resmgr but normally USB scanners should work without problems regarding resmgr. If USB scanner access fails with SUSE LINUX 9.2 it is probably an USB problem (see "USB Hardware + USB Kernel Modules + hotplug" and "USB Cable Connection and Additional USB Hubs").
- SUSE LINUX 9.1 does not launch a PAM module for the resmgr when the user logs in via text console. Therefore access via resmgr does not work with SUSE LINUX 9.1 when the user logs in via text console. This works with SUSE LINUX 9.2 (see "libusb + resmgr + PAM").
- Since SUSE LINUX 9.2 the sane package is compiled with libieee1284 support for parallel-port scanners. The sane RPM requires "libieee1284.so.3" which is provided by the new package "libieee1284". If you have a parallel-port scanner, you may have to change /etc/sane.d/backend.conf accordingly (see "SANE Backends").
<keyword>scanner,scanning,sane,iscan,ptal,resmgr,9.2,92</keyword>