SDB:Configuring Scanners
Concern
You want to configure your scanner.
Procedure
To set up a scanner run the YaST Scanner module. The YaST Scanner module can be found in the YaST Control Center under Hardware -> Scanner. For more information you may have a look at YaST/Modules/Scanner at http://old-en.opensuse.org/YaST/Modules/Scanner.
Many USB scanners are set up full automated when plugged in at the USB so that there is no need to run the YaST Scanner module.
Full automated USB scanner setup happens via the udev rules file /etc/udev/rules.d/56-sane-backends-autoconfig.rules which is provided in the openSUSE package "sane-backends-autoconfig". For details see the package description (e.g. via "rpm -qi sane-backends-autoconfig"). If you do not like automated scanner driver activation, do not install this package or remove it when it is already installed.
The following paragraphs provide further information regarding the technical background and the manual configuration.
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". 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.
Basics
The "SANE Project" http://www.sane-project.org provides the central software for operating scanners.
The SANE Project software development happens at https://gitlab.com/sane-project
The SANE project software consists of "SANE-backends" and "SANE-frontends". In openSUSE, you find the "SANE-backends" software in the "sane-backends" package.
The SANE backends constitute the actual hardware drivers for the various scanner types; see http://www.sane-project.org/sane-backends.html.
In general "driver" means device-model-specific software and data.
A backend can support various models if the various models can be addressed in the same way. Such models are compatible with each other to a certain extent 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 inside 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 easier and safer to drive such a scanner. Examples: The models which are supported by the "epson2" 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 command line frontend "scanimage" which is included in the "SANE-backends" software, the uniform interface enables the use of other frontends like the graphical frontend XSane (see http://www.xsane.org/) which is provided by openSUSE in the package "xsane".
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 plain kernel:
- libusb (library to access USB devices)
- udev (set user access permissions to access USB devices)
- kernel modules to access USB devices
Regardless of the details, in general 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 (scanner user frontend) | SANE backend (scanner driver) | libusb (generic USB device access functions) | USB kernel modules (plus udev triggered by USB scanner plug-in) | USB hardware in the machine | USB cable connection (additional USB hubs if necessary) | Scanner
Only the parts "SANE backend (scanner driver)" and "Application (scanner user frontend)" are what could be called "the actual scanning software".
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
First and foremost the scanner must be supported by openSUSE.
Information about scanners supported by openSUSE:
Run the YaST scanner module and check the list of models therein. You do not need to have a scanner connected to do this. Click "Add" and pretend to set up an imaginary scanner. Select the model and the driver from the list and click "Next" so that the YaST scanner module could show you additional messages regarding particular known issues and problems. Finally the selected driver for the model gets activated. When no scanner is connected, all what happens is that the driver tries to autodetect a scanner which will of course fail in this case.
Alternatively to find out whether or not a SANE backend is available for your scanner in your installed SANE version check the following file:
/usr/share/doc/packages/sane-backends/sane-mfgs.html
The accuracy of the information therein cannot be guaranteed, as Linux support information is usually based on user statements. 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. The accuracy of the information therein cannot be guaranteed, as Linux support information is usually based on user statements. Possibly the SANE version included in your openSUSE version does not yet support your scanner.
The following list shows which scanner models are supported (or not supported), to what degree and by which backend of your installed SANE version:
/usr/share/doc/packages/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
Information about scanners supported by Linux (not necessarily supported by openSUSE):
A considerable number of scanners are supported only by means of a so called "external backend"; see the files /usr/share/doc/packages/sane/sane-backends/sane-mfgs-external.html and /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 furthermore see the section about "Third-Party Scanner Drivers" below.
External backends are not part of the "SANE-backends" software of the SANE project. Therefore external backends are not included in the "sane-backends" package.
For each known external backend, a 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 uploaded 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 distribute firmware with openSUSE 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 so that a normal scanner is ready to use as soon as it is powered on.
If no SANE backend is available for the scanner or when the scanner is listed as "unsupported" by SANE (see http://www.sane-project.org/sane-backends.html#S-UNSUPPORTED and the file /usr/share/sane/descriptions/unsupported.desc), the device cannot be used with one of the common frontends (scanimage, xsane). Possibly there may be other software e.g., directly from the vendor - ask the vendor about this - and read the section regarding "Third-Party Scanner Drivers" below.
RPM packages of the "sane-backends" scanner drivers
The various openSUSE versions (e.g. openSUSE Leap, openSUSE Tumbleweed) usually provide the latest "sane-backends" version that is officially released by the SANE project at the time when the particular openSUSE version is developed and prepared (not at the later time when the particular openSUSE version is finally released).
The currently latest "sane-backends" version that is officially released by the SANE project is usually available in the openSUSE Build Service development project "graphics" (usually a relatively short time after it was released by the SANE project).
In general we do not provide unstable "sane-backends" development versions (e.g. Git snapshots) in the "graphics" project which is for developing the openSUSE "sane-backends" RPM package but not for developing scanner drivers. The latter happens upstream at the SANE project.
If your particular scanner model is listed at SANE upstream that it requires a newer "sane-backends" version than what there is provided in your particular openSUSE version and if that newer "sane-backends" version is officially released at SANE upstream, then have a look at the openSUSE Build Service development project "graphics" if there is already the "sane-backends" version that you need available for your particular openSUSE version.
To get the "sane-backends" RPM package from the "graphics" project, go to http://software.opensuse.org and search for "sane-backends". Click on the listed result "sane-backends" and then "Show other versions". Then select your exact openSUSE version (e.g. openSUSE Leap 15.1, openSUSE Leap 15.2, openSUSE Tumbleweed) and further "Show unstable packages" and finally select the package from the "graphics" project. Use packages that match your particular system. Packages for a bit older systems may work in a bit newer systems. For example a package for openSUSE Leap 15.1 may work in openSUSE Leap 15.2 but never use packages for newer systems in an older system like packages for "openSUSE Tumbleweed" when your system is not "openSUSE Tumbleweed" (unless you really want to mess up your system).
The "graphics" repository is the official openSUSE development repository for the openSUSE "sane-backends" RPM package which means:
The "graphics" development project may contain new software or work-in-progress changes of existing software that might neither be in a stable state nor fit well into currently installed systems. Have this in mind if you think about to install packages from the "graphics" project into your currently running system.
The packages in the "graphics" project are without any guarantee or warranty and without any support. As an extreme example, this means if your complete computer center crashes because of those packages, it is only your problem.
On the other hand this does not mean that those packages are known to be terrible broken but they are not thoroughly tested so that any unexpected issue can happen.
In the end the "sane-backends" software is only an application (scanner drivers are no kernel drivers) which means that your system should not "explode" when you upgrade "sane-backends" with a newer version from the "graphics" project (provided you use the matching packages for your particular system).
If a new version does not work it should usually help to downgrade (and to reconfigure as needed) to get it working again.
Caution: Badly broken scanner driver software could even damage your scanner hardware. In particular when a scanner makes bad-sounding noises it means that the scanner hardware could get damaged.
In general we (i.e. openSUSE) distribute the "sane-backends" scanner drivers from the SANE project but we do not develop scanner drivers.
Usually we do not have all those various kind of scanners for all those various kind of scanner drivers so that usually we cannot do anything when a particular scanner driver does not work. In particular usually we cannot reproduce issues with scanner drivers.
When a particular scanner driver is listed at the SANE project that it should work for your particular scanner model but it does not work for you with the currently latest "sane-backends" version that is officially released by the SANE project, then it is recommended to report the issue directly to the driver authors of the SANE project at http://www.sane-project.org and https://gitlab.com/sane-project/backends so that there is a direct communication between you and the upstream authors.
I.e. before you report an issue to the driver authors at the SANE project you may have to upgrade the "sane-backends" RPM package to the one from the openSUSE "graphics" project and verify that the issue also happens with the currently latest "sane-backends" release.
The best way to report an issue is the sane-devel mailing list so that the upstream authors plus interested users can notice it, see http://www.sane-project.org/mailing-lists.html or even more directly report it as "New issue" via https://gitlab.com/sane-project/backends/-/issues
Version upgrades of scanner driver packages
For scanner drivers a version upgrade makes sense only for those users who actually have a scanner that is not yet supported with the version that we provide in an openSUSE release or in a SUSE Linux Enterprise product.
Because the "sane-backends" package and also the "hplip" package support each one very many different scanner models it is less than hopeless to have them tested by us (i.e. by openSUSE) in a reasonable way which means: Basically scanner drivers are not at all tested for all the different supported scanner models.
Therefore a scanner driver package version upgrade as a regular maintenance update that all users get more or less automatically is not possible because regressions for this or that scanner model are unknown in advance.
Or in other words: When a particular scanner driver version works for a particular user with a particular scanner model there is zero reason to enforce a version upgrade for that user by a general maintenance update.
On the other hand when a scanner driver version does not work for a particular user with a particular scanner model there is zero reason for that user not to do a version upgrade and try out if the newer version may work for his particular model (provided the newer version claims that model is supported).
Therefore we try to provide the newest "sane-backends" version in the openSUSE "graphics" project and the newest "hplip" version in the Printing project.
In general we (i.e. openSUSE) distribute scanner driver packages from the upstream projects but we do not develop scanner drivers so that usually we cannot do anything when a particular scanner driver does not work. In particular usually we cannot reproduce issues with scanner drivers. In case of issues with scanner drivers see the section below about "Trouble-Shooting (Debugging)" for basic tests and basic operations how to diagnose the cause of an issue.
USB
USB Speed
Nowadays there are basically three different kind of USB connectors:
- USB 1.0 and USB 1.1 with so called "Low Speed" and "Full Speed" (USB kernel driver uhci_hcd or ohci_hcd)
- USB 2.0 with so called "Hi-Speed" (USB kernel driver ehci_hcd)
- USB 3.0 and USB 3.1 with so called "SuperSpeed" and "SuperSpeed+" (USB kernel driver xhci_hcd)
Theoretically an older scanner with USB 1.x interface should also work on a USB 2.0 port at the computer and even at a USB 3.x port because higher speed USB ports at the computer should be compatible with lower speed USB devices.
But in practice in particular older scanners with USB 1.x interface may not at all work or not work reliably on a USB 3.x port at the computer.
When an older USB scanner is listed as supported but it does not work or does not work reliably, it is recommended to connect the scanner at a USB port at the computer with matching USB speed or at least to connect it not at a USB 3.x port.
Weird issues may happen when the USB 3 kernel driver xhci_hcd is used:
Currently there could be sometimes issues with USB ports where "xhci_hcd" is used as kernel driver.
When "lsusb -t" shows "Driver=xhci_hcd" for the USB bus and port where the USB scanner is connected (see "lsusb" where the scanner is connected), there could be issues depending on the computer hardware and firmware, the kernel version, and the sane-backends version: For example "I/O errors" or arbitrary inexplicable failures every now and then in particular when scanning in color mode and/or with higher resolution (i.e. such failures happen in particular when there is much scanning data).
When there are issues with USB scanners that are connected at a USB port where the kernel driver xhci_hcd is used, connect the scanner at a traditional real USB 2 port if possible.
Neither the color of the USB connector nor what it is labeled on the computer is reliable regarding what kernel driver is used for a USB port. Only the "lsusb -t" output shows what kernel driver is used. What USB kernel driver is used depends on what USB hardware there is in the computer. It is not possible to use USB 3 hardware as if it was USB 2 hardware. It is not possible to use USB 3 hardware without the xhci_hcd kernel driver. On nowadays computers there is often only USB 3 hardware so that blacklisting the xhci_hcd kernel module would make the whole USB no longer work which is in particular bad when keyboard and mouse are connected via USB 3 hardware. Only a few particular USB 3 capable chipsets provide both real USB 3 hardware and real USB 2 hardware. One needs real USB 2 hardware in the computer to use a scanner without the xhci_hcd kernel driver.
When there are only USB ports where the kernel driver xhci_hcd is used and there are issues with USB scanners (in particular "I/O errors" or arbitrary inexplicable failures every now and then) see what "man sane-usb" tells about SANE_USB_WORKAROUND in recent sane-backends versions.
USB Cable Connection and Additional USB Hubs
Maximum length of USB cables:
- Low Speed cables: No more than 3 meters.
- Full Speed and Hi-Speed cables: No more than 5 meters.
- SuperSpeed cables: Maximum practical length is 3 meters.
See the Wikipedia page on USB Cabling.
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 Kernel Modules + udev
The details here change from version to version. An article regarding scanner setup cannot describe all the details about the various lower levels. Refer to the appropriate specific documentation if there are problems in one of these areas.
A USB scanner must be displayed by the following command:
lsusb
(run it both as root and as normal user), or, should command above not be available:
/sbin/lsusb
If it does 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 a USB keyboard or USB mouse if any). Then reboot the system while keeping the scanner switched on. Normally, hotplug/udev 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 particular 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" (you may have to run it as root) lists the USB controllers; see http://www.linux-usb.org/
USB scanner access permissions via udev
The details here change from version to version. An article regarding scanner setup cannot describe all the details about the various lower levels. 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/ or via /dev/bus/usb/xxx/yyy (the actual location changed and changes all the time from kernel/udev/libusb/whatever... version to version) 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/ or /dev/bus/usb/ (or wherever it actually is for the current version) are generated anew every time the system is booted and/or whenever a scanner is unplugged and re-plugged to the USB (perhaps even when a USB scanner is switched off and on). Therefore, access permissions can no longer be set permanently as usual with the traditional "chmod" command.
The best workaround to get those kind of issues out of sight is to use the "saned" which is a service for scanning via network (for some details see the below section about "Scanning via Network"). On the server the saned is set up and launched traditionally via xinetd or nowadays via systemd. On the client the "net" meta-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". To access a scanner via the "saned" on the local host you may set up the following:
- Let the saned run as root (for xinetd by 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" meta-backend in /etc/sane.d/dll.conf
In the YaST scanner configuration, you can set up such a "Local Host Configuration" via "Other" and "Scanning via Network". Usually this is the easiest workaround when there are scanner access problems for normal users. A little drawback is that scanning frontends for the user root will recognize the scanner twice. Once directly as "backend:..." and a duplicate via the net meta-backend as "net:localhost:backend:...".
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.
Note that running the saned as root is a security issue because now you have a server process running as root on your computer that is accessible via network. Therefore you must have firewall protection against unwanted access to the saned, see SDB:CUPS and SANE Firewall settings
Alternatively you may change the udev access permission settings:
udev is used to set read/write permissions via ACL (run "getfacl /dev/bus/usb/<bus-number>/<device-number>" to show them) for the one normal desktop user who is currently logged in locally (i.e. logged in via graphical XDM/Kdm) so that the currently logged in desktop user gets sufficient permissions to use the scanner unit as normal user.
The udev rules from the sane-backends package are in /etc/udev/rules.d/55-libsane.rules - see "man udev" how to make such entries.
For scanners in HP all-in-one devices there is a special complication in the udev rules because HP all-in-one devices have additional udev rules from the hplip package in /etc/udev/rules.d/55-hpmud.rules or /usr/lib/udev/rules.d/56-hpmud.rules which are set before or after the udev rules from the sane-backends package in /etc/udev/rules.d/55-libsane.rules so that entries in one file may get overwritten by settings in another file. To avoid unexpected results keep the settings in those files in sync.
Only as non-authoritative information how USB scanner (and printer) device node setup via udev should usually work nowadays (as of this writing dated October 2015):
USB scanners and scanner units in USB multifunction devices (printer/scanner/copier) get normal-user read/write access via udev and for the printer unit in a USB multifunction device it is sufficient that the device node has group "lp" and group read/write access (also via udev) because the CUPS backend runs as user "lp" that is in group "lp". (CUPS backends and SANE backends are different things. For CUPS backends see "What is a CUPS backend and how does it work" in SDB:CUPS in a Nutshell.)
Therefore USB scanners and USB multifunction devices get "rw-rw-r-- root lp" set for the device node which happens via /etc/udev/rules.d/55-libsane.rules (from sane-backends RPM) and for HP all-in-one devices additionally via /usr/lib/udev/rules.d/56-hpmud.rules (from the hplip RPM).
Both set ENV{libsane_matched}="yes" and that one triggers in /usr/lib/udev/rules.d/70-uaccess.rules (from the systemd RPM) that TAG+="uaccess" is set which triggers in /usr/lib/udev/rules.d/73-seat-late.rules (from the systemd RPM) to RUN{builtin}+="uaccess" that manages device node user ACLs which finally results the '+' in "rw-rw-r--+ root lp" (i.e. an ACL setting) for the device node.
To display the ACL run as root "getfacl /dev/bus/usb/<bus_number>/<device_number>".
The ACL is only set when a normal user logs in directly at the computer (not from remote). In this case that normal user gets read/write access for the USB device node.
For USB multifunction devices the multifunction aspect could make it troublesome in other Linux distributions that may use the SANE upstream way to set scanner device nodes to group "scanner" and add the users to that "scanner" group which conflicts with the CUPS backend that usually needs "lp" group read/write access to access the printer unit so that special setup is needed to make printing work.
In openSUSE there is no group "scanner". Only the "lp" group exists and is used in /etc/udev/rules.d/55-libsane.rules as MODE="0664", GROUP="lp".
It is sufficiently secure and reasonable easy to use by default the same group "lp" for printers and scanners because both kind of devices usually require physical user access (to get the printed paper or to place a paper on the scanner) so that both kind of devices should usually require the same kind of security and for multifunction devices only one group can be set and then the "lp" group is the more reasonable default setting.
For example what is reported to 'root' when someone else is currently directly logged in as normal user "johndoe":
# lsusb ... Bus 002 Device 003: ID a1b2:c3e4 ACME Fancy Scanner 1000 ... # ls -l /dev/bus/usb/002/003 crw-rw-r--+ ... root lp ... # getfacl /dev/bus/usb/002/003 getfacl: Removing leading '/' from absolute path names - file: dev/bus/usb/002/003 - owner: root - group: lp user::rw- user:johndoe:rw- group::rw- mask::rw- other::r--
SANE Backends
Every backend has its own configuration file /etc/sane.d/"backend".conf and its own man page: "man sane-backend" (replace "backend" with 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 backends "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 a USB scanner ready to use - provided the USB system and the udev layer work correctly 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. 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 with "man sane-backend" (replace "backend" with the name of the respective 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 user "root", only root is able to access the scanner, but not the normal users. In this case, the problem lies in the "USB scanner access permissions via udev" layer. The output of "scanimage -L" for a USB scanner has usually the following format
device 'backend-name:libusb:bus-ID:device-ID' ...
and for a SCSI scanner
device 'backend-name:/dev/sg[0123...]' ...
The actual SANE device string format (e.g. libusb:bus-ID:device-ID or /dev/sg[0123...]) depends on the particular backend.
The command "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 SANE device string according to 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 (excerpts):
-d, --device-name=DEVICE
use a given scanner device
--format=pnm|tiff|png|jpeg
file format of output file
-v, --verbose
more status messages
...
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 as jpeg output file format with verbose status messages may be as follows:
scanimage -v -d backend:libusb:123:456 --format=jpeg --mode Gray --resolution 300 -x 100 -y 150 >photo.jpg
Scanning via Network
How to access a scanner device directly via network connection
Preferably a scanner device with USB and network connection should also support the traditional wired network cable connection and not only wireless because wireless is known to be sometimes problematic so that one should be able to fall back to the wired network cable connection when there are issues with wireless access. In theory it should not matter which kind of network connection is used. In practice wireless networking is known to often not work reliable compared to the traditional wired network connection. Furthermore wireless networking could be insecure, see see SDB:CUPS_and_SANE_Firewall_settings. When scanning works via USB (preferably traditional USB2 - see above regarding possible issues with USB3) but not via wireless network, connect the device via traditional wired network cable and re-do the scanner setup to test if scanning works via traditional wired network. In general it is a precondition for scanning via network that scanning works at least via traditional USB2. When a scanner driver does not work via USB2 it is usually hopleless that it will work via network.
When a scanner device has a network connection a special SANE scanner driver that has built-in support for scanner device access and communication via the network connection is required.
The "saned" (see below) does not support to access a scanner device via network.
The reason behind is that there is no generic layer in between that would do some kind of generic scanner device access and/or scanner device communication. For each scanner device the scanner driver itself implements device access and communication. E.g. for USB scanners the scanner driver itself implements the actual USB communication with the device. Accordingly for network scanners the scanner driver itself must implement device access and communication.
How to access a USB scanner connected to another host via network
Assume there is a USB scanner connected to one host (the "server") and you like to acces it from another host (the "client").
A precondition is that scanning already works on the server.
To grant additional access via network, you can use "saned" which is a service for scanning via network. On the server the saned is set up and launched traditionally via xinetd but nowadays with systemd things are somewhat different. On the client the "net" meta-backend is used for scanning via network. See "man saned" and "man sane-net".
- On the server let the saned run (set "disable = no" in /etc/xinetd.d/sane-port and start the xinetd or do equivalent things for systemd)
- On the server allow access from the client in /etc/sane.d/saned.conf
- On the client specify the server in /etc/sane.d/net.conf
- On the client activate the "net" meta-backend in /etc/sane.d/dll.conf
In the YaST scanner configuration, you can set up such a configuration" via "Other" and "Scanning via Network".
Note the security warning when you read "man saned":
saned is not intended to be exposed to the internet or other non-trusted networks.
Running the saned is a security issue because now you have a server process running on your computer that is accessible via network. Therefore you must have firewall protection against unwanted access to the saned, see SDB:CUPS and SANE Firewall settings
The following stack consisting of various layers must be functional in its entirety in order to enable users to access a USB scanner which is connected to a remote host (the server) from the user's local workstation (the client) where the user application runs:
User | Application (frontend) | SANE net (meta-backend on the client) | Client network interface | client machine Network ======================================= | server machine Server network interface | SANE saned (meta-frontend for the backend) | SANE backend (actual driver for the scanner) | libusb | USB kernel modules | USB hardware in the server machine | USB cable connection | Scanner
This kind of setup for scanning via network makes sense only when the client workstation is also located next to the scanner (in particular when both the client and the server with the scanner are located in the same room), see the following:
How to use a professional network printer scanner copier all-in-one device
In contrast to the above described scanning on a USB scanner a powerful network printer scanner copier all-in-one device is usually used in a different way by "stand-alone scanning to e-mail" where neither a particular scanner driver software nor any SANE software is involved at all.
Normally one can scan directly on a professional network printer scanner copier and specify scan resolution and image file format (e.g. tiff, PDF, ...) and all the other scanning options directly at the device and in particular one can specify an e-mail address to which the device will send the scanned image file so that one will receive the scanned image as a mail attachment according to what was specified as image file format.
Before you buy a network printer scanner copier, check carefully that the particular device does support "stand-alone scan to e-mail" (without any additional software) and that the device provides a well usable user interface for daily work.
This way of operating is usually much more convenient for the user because when you would use a SANE backend you would have to specify all the scanning parameters on your workstation by using a SANE frontend.
But when your workstation is far away from the network scanner device, you would have to walk to the network scanner to place your sheet of paper in it and post a big red note on the network scanner that you are currently using it for scanning so that others know what is going on and don't remove your sheet, then walk back to your workstation to specify the scanning parameters and start the scan and finally you would have to walk again to the network scanner to fetch your sheet and remove your note and walk back to your workstation. On the other hand this way of operating is much better for your physical health ;-)
Regarding the printer unit in an all-in-one device see the "Printer plus Scanner all-in-one devices" section in SDB:Printer buying guide.
Trouble-Shooting (Debugging)
For debugging the debug-messages of the various layers in SANE and the verbose 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 -v >/dev/null && 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 precisely the backend library "/usr/lib[64]/sane/libsane-backend.so...":
export SANE_DEBUG_DLL=4 scanimage -d Device -v >/dev/null && echo OK || echo FAILED unset SANE_DEBUG_DLL
Testing with only the debug-messages of the actual backend. The debug value depends on the particular backend, see "man sane-backend" (replace "backend" with the name of the respective backend):
export SANE_DEBUG_backend=128 scanimage -d Device -v >/dev/null && 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 -v >/dev/null && 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 -v >/dev/null && echo OK || echo FAILED unset SANE_DEBUG_SANEI_USB unset SANE_DEBUG_backend unset SANE_DEBUG_DLL
Third-Party Scanner Drivers
A third-party driver is proprietary software when it contains at least one part which is proprietary software - usually a proprietary binary-only library which might be called a "module".
For proprietary software nobody - except the authors or vendor of the proprietary software - can provide any kind of help and support because nobody - except the authors or vendor - know how their proprietary software really works.
In this case you can only contact those wherefrom you got the proprietary software for any kind of help and support.
If third-party scanner driver software does not work in compliance with SANE you can only contact those wherefrom you got the third-party driver for help and support.
If third-party scanner driver software works in compliance with SANE:
The YaST2 scanner module cannot support third-party scanner drivers because there is no defined way in SANE how third-party scanner driver software must install so that generic scanner setup software (like the YaST2 scanner module) could support it.
But generic scanner setup support is usually not needed because:
Basically third-party scanner driver software which works in compliance with SANE should add its driver name during installation of the driver software to /etc/sane.d/dll.conf so that the driver is activated and then the driver should work, see "SANE Backends" above.
After you installed a third-party scanner driver which works in compliance with SANE, verify that its driver is listed in /etc/sane.d/dll.conf so that the driver is activated.
Afterwards check if "scanimage -L" (run it as root and as normal user) finds the scanner, see "Frontend" above.
If the driver is activated via /etc/sane.d/dll.conf but "scanimage -L" does not find the scanner when you run it as root, it is actually the driver which does not find the scanner which means that the driver does not work.
If "scanimage -L" finds the scanner when you run it as root but does not find it when you run it as normal user, there is usually an access permission issue, see "USB scanner access permissions via udev" above.
It would not help if YaST supports a third-party scanner driver because all what YaST could do is to activate the driver in /etc/sane.d/dll.conf but YaST cannot fix a driver which is activated but does not work.
If a third-party scanner driver does not work, you may try to debug it on your own, see "Trouble-Shooting (Debugging)" above or contact those wherefrom you got the third-party driver for further help and support.