SDB:Scanner einrichten ab SUSE LINUX 9.2

aus openSUSE, der freien Wissensdatenbank

Anliegen

Sie möchten Ihren Scanner einrichten.

Vorgehen

Grundlegende Informationen finden Sie in den Handbüchern zu SUSE LINUX 9.2.

Im folgenden finden Sie weitergehende Informationen, insbesondere technische Hintergrundinformationen und Hinweise zur manuellen Konfiguration.

Am Ende werden einige wichtige Unterschiede zu SUSE LINUX 9.1 genannt.

Ergänzungen speziell zu SUSE LINUX 9.3 finden Sie im folgenden Artikel: SDB:Scanner einrichten ab SUSE LINUX 9.3

Um den Artikel nicht zu komplex werden zu lassen, werden hier schwerpunktmäßig nur USB-Scanner betrachtet.

• Informationen, die sich nicht speziell auf USB beziehen, gelten auch für SCSI- und Parallelport-Scanner.
• Für SCSI-Scanner siehe "man sane-scsi" und SDB:SCSI Scanner wird unter SUSE LINUX 9.1 nicht erkannt
• Für Parallelport-Scanner siehe die Man-Page zum jeweiligen Backend (vergl. den Abschnitt "SANE-Backends" unten) und die Informationen zum Einrichten des Parallelports im Handbuch.

Grundlagen

Die zentrale Software für den Scannerbetrieb liefert das "SANE Projekt": http://www.sane-project.org/

Die SANE Projekt Software besteht aus "SANE-Backends" und "SANE-Frontends" und befindet sich bei SUSE LINUX in den "sane" Paketen (sane-backends und sane-frontends).

Die eigentlichen Hardware-Treiber für die verschiedenen Arten von Scannern sind die sog. "SANE-Backends", siehe http://www.sane-project.org/sane-backends.html

Ein Backend kann ganz verschiedene Modelle unterstützen, wenn die verschiedenen Modelle auf gleiche Art angesprochen werden können. Die Modelle sind dann in gewisser Weise kompatibel zueinander weil sie dieselbe "Sprache" verstehen. Je nach Backend variiert die Art dieser Sprache:

• Am primitivsten ist die Sprache, wenn damit nur direkt Werte in die Steuerregister des Chipsatzes eingetragen werden können, der die eigentliche Scaneinheit im Scanner direkt ansteuert. Die genauen Werte können von Modell zu Modell verschieden sein. Da die Scannerhardware direkt angesteuert wird, können falsche Werte schlechte Scanergebnisse bringen oder sogar den Scanner bschädigen. Beispiele sind die Modelle, die vom "plustek" Backend unterstützt werden.
• Ordentlich gemachte Scanner haben eine richtige "Scannersprache" eingebaut. Weil das Backend hier nicht den Chipsatz im Scanner direkt programmieren muss, ist die Ansteuerung wesentlich einfacher und sicherer. Beispiele sind die Modelle, die vom "epson" Backend unterstützt werden.

SANE bedeutet "Scanner Access Now Easy". SANE bietet über die "libsane" Bibliothek eine einheitliche Schnittstelle für Anwendungsprograme (API = Application Programming Interface), so dass Anwendungsprograme einen einheitlichen Zugriff auf die verschiedenen Scannermodelle haben.

Anwendungsprograme, die über ein SANE-Backend auf einen Scanner zugreifen, heissen "SANE-Frontends" bzw. nur "Frontends".

Wegen der einheitlichen Schnittstelle gibt es nicht nur Frontends von SANE (scanimage, xscanimage), sondern auch beliebige andere, z.B. XSane oder das KDE Frontend Kooka (im Paket kdegraphics3-scan).

Ein Backend greift aber nicht selbst direkt auf die Scannerhardware zu, sondern verwendet seinerseits den Kernel zusammen mit diversen Subsystemen, um die Datenübertragung zur Scannerhardware zu bewerkstelligen. Beispielsweise sind neben dem Kernel noch folgende Subsysteme involviert, um auf einen USB-Scanner zuzugreifen:

• PAM (Pluggable Authentication Modules)
• resmgr (Resource Manager)
• libusb (Bibliothek für den Zugriff auf USB Geräte)
• hotplug (Automatische Aktivierung von Hotplug-Geräten)

Zusammen ergibt sich ein Stapel aus etlichen Schichten, der komplett funktionieren muss, damit man als normaler Benutzer aus einem Anwendungsprogramm auf einen USB-Scanner zugreifen kann:

Benutzer
  |
Anwendungsprogramm (Frontend)
  |
SANE-Backend
  |
libusb
  |
resmgr <-- PAM <-- Anmeldung des Benutzers (Login)
  |
USB-Kernelmodule <-- hotplug <-- Anschließen des Scanners (Plug in)
  |
USB-Hardware im Rechner
  |
USB-Kabelverbindung (evt. zusätzliche USB-Hubs)
  |
Scanner

Die korrekte Funktion aller unteren Schichten ist Voraussetzung für die Funktion einer höheren Schicht. Daher werden im folgenden die verschiedenen Schichten bzw. Subsysteme von unten nach oben besprochen.

Scanner

Prüfen Sie [file:///usr/share/doc/packages/sane/sane-backends/sane-mfgs.html /usr/share/doc/packages/sane/sane-backends/sane-mfgs.html], ob es zu Ihrem Scanner ein SANE-Backend in Ihrer installierten SANE Version gibt. Beachten Sie, dass diese Informationen grundsätzlich keine Garantie beinhalten. Es ist möglich, dass der Hersteller verschiedene Gerätevarianten unter demselben Namen vertreibt und nicht alle Varianten unterstützt sind (siehe z.B. die Angaben zum "Artec/Ultima 2000").

Prüfen Sie ggf. auch in http://www.sane-project.org/sane-mfgs.html, ob es zu Ihrem Scanner ein SANE-Backend gibt. Beachten Sie, dass diese Informationen den neuersten Stand der SANE-Software wiedergeben und auch keine Garantie beinhalten. Es ist möglich, dass die SANE-Version, die in Ihrer SUSE LINUX Version enthalten ist, Ihren Scanner noch nicht unterstützt.

Welche Scannermodelle von welchem Backend Ihrer installierten SANE Version zu welchem Grad unterstützt bzw. nicht unterstützt sind ist in [file:///usr/share/doc/packages/sane/sane-backends/sane-backends.html /usr/share/doc/packages/sane/sane-backends/sane-backends.html] aufgelistet.

Obige HTML-Dateien werden aus Beschreibungsdateien erzeugt, die es pro Backend gibt: /usr/share/sane/descriptions/Backend.desc

Die Einträge haben folgendes Format:

 :mfg "Hersteller A"

 :model "Modell 1"
 :interface "USB"
 :status :complete

 :model "Modell 2"
 :interface "SCSI"
 :status :good

 :mfg "Hersteller B"

 :model "Modell X"
 :interface "Parport"
 :status :minimal

 :model "Modell Y"
 :interface "IEEE-1394"
 :status :untested

 :model "Modell Z"
 :interface "Proprietary"
 :status :unsupported
 

Etliche Scanner sind nur durch ein sog. "externes Backend" unterstützt, siehe [file:///usr/share/doc/packages/sane/sane-backends/sane-mfgs-external.html /usr/share/doc/packages/sane/sane-backends/sane-mfgs-external.html] und [file:///usr/share/doc/packages/sane/sane-backends/sane-backends-external.html /usr/share/doc/packages/sane/sane-backends/sane-backends-external.html] bzw. für den neuersten Stand siehe http://www.sane-project.org/lists/sane-backends-external.html

Externe Backends sind nicht Bestandteil der Software des SANE Projekts, also nicht im Paket sane enthalten.

Bei SUSE LINUX 9.2 gibt es zwei Pakete mit externen Backends:

• Die freie "HPOJ" Treibersoftware von HP im Paket hp-officeJet. Da es sich um freie Software handelt, wird dieses Paket standardmäßig installiert. Diese Software unterstützt die meisten HP Multifunktionsgeräte (Drucker+Scanner) über den PTAL-Dienst und das "hpoj" Backend. Hier ist also noch ein weiteres Subsystem "PTAL" involviert, was passend zu konfigurieren und zu aktivieren ist. Die Konfiguration kann mit YaST erfolgen, erfordert aber ggf. bzgl. des PTAL-Dienstes zusätzliche manuelle Nacharbeit bzw. eine Umkonfiguration von USB auf PTAL bei der Druckereinheit. Für SUSE LINUX 9.2 gibt es bereits ein Update des hp-officeJet Pakets, das einen Fehler bzgl. der Aktivierung des PTAL-Dienstes behebt. Für weitere Informationen siehe SDB:HP OfficeJet ("all-in-one" Gerät) einrichten Beachten Sie, dass letzteres den neuersten Stand der HPOJ Software bei HP wiedergibt.
• Die nur teilweise freie "Image Scan" Treibersoftware von Epson im Paket iscan, die das Backend "epkowa" bereitstellt. Beachten Sie die Lizenzbestimmungen in der Datei /usr/share/doc/packages/iscan/COPYING.KOWA (siehe "rpm -qi iscan"). Da es sich um proprietäre Software handelt, wird dieses Paket nicht standardmässig installiert. Die Konfiguration muss manuell erfolgen. Manche Scanner sind sowohl vom Backend "epson" als auch von "epkowa" unterstützt. YaST verwendet nur das epson Backend. Beim Installieren des iscan Pakets wird das epkowa Backend automatisch in /etc/sane.d/dll.conf aktiviert. Ggf. ist das unerwünschte Backend in /etc/sane.d/dll.conf zu deaktivieren (siehe den Abschnitt "SANE-Backends" unten). Zur Konfiguration siehe "man iscan", "man sane-epkowa", /usr/share/doc/packages/iscan/userg_e.pdf und http://www.epkowa.co.jp/english/linux_e/index.html Beachten Sie, dass letzteres den neuersten Stand der Image Scan Software bei Epson wiedergibt.

Bei SUSE LINUX 9.3 siehe: SDB:Scanner einrichten ab SUSE LINUX 9.3

Welche Scannermodelle von welchem externen Backend zu welchem Grad unterstützt bzw. nicht unterstützt sind, ist pro Backend in einer Beschreibungsdatei /usr/share/sane/descriptions-external/Backend.desc aufgelistet.

Manche Scanner funktionieren nicht, wenn nicht nach dem Einschalten des Scanners passende Firmware (Software, die im Scanner selbst die eigentliche Hardware des Geräts steuert) in den Scanner geladen wird. Für solche seltsamen Modelle muss also die passende Firmware beschafft werden (fragen Sie den Hersteller des Scanners) und das Backend muss für den Firmware-Upload konfiguriert werden (siehe den Abschnitt "SANE-Backends" unten). Da Firmware unter der Lizenz des Geräteherstellers steht, dürfen wir keine Firmware mit SUSE LINUX vertreiben, es sei denn, der Hersteller würde uns die Firmware unter einer freien Lizenz zur Distribution und Re-Distribution zur Verfügung stellen. Bei normalen Scannern ist die Firmware dauerhaft im Gerät gespeichert, so dass der Scanner nach dem Einschalten direkt funktionsbereit ist.

Wenn es zu dem Scanner kein Backend für SANE gibt (siehe http://www.sane-project.org/sane-backends.html#S-UNSUPPORTED und /usr/share/sane/descriptions/unsupported.desc), dann kann das Gerät nicht mit einem der üblichen Frontends (scanimage, xscanimage, xsane, kooka) verwendet werden. Evtl. gibt es andere Software (z.B. direkt vom Hersteller - fragen Sie dazu direkt den Hersteller), wenn nicht, dann kann das Gerät nicht verwendet werden.

USB-Kabelverbindung und evt. zusätzliche USB-Hubs

USB-Kabel haben eine Maximallänge:

• Billige "Low Speed" Kabel (nicht verdrillt, nicht abgeschirmt): Maximal 3 Meter. Für schnelle Datentrasferrate (USB 2) ungeeignet.
• Höherwertige "Full Speed" und "High Speed" Kablel (verdrillt und abgeschirmt): Maximal 5 Meter.
• Ist ein USB-Hub zwischengeschaltet, kann sich die Maximallänge je nach eingesetztem Kabel und Hub verkürzen.

Manche Scanner haben keine eigene Stromversorgung, sondern nehmen den Strom vom USB. Wenn Ihr USB-System nicht genügend Leistung bereitstellt, kann so ein Scanner nicht funktionieren. Probieren Sie, ob es mit einem zwischengeschalteten USB-Hub, der eine eigene Stromversorgung hat, funktioniert.

USB-Hardware im Rechner + USB-Kernelmodule + hotplug

Ein USB-Scanner muss von folgenden Befehlen angezeigt werden:

• /sbin/lsusb
• cat /proc/bus/usb/devices

Wird das Scannermodell nicht angezeigt, dann ist keine Datenübertragung zwischen Rechner und Scanner möglich, weil der Kernel das USB-Gerät nicht erkannt hat bzw. weil nicht alle erforderlichen USB-Kernelmodule geladen sind.

Schließen Sie bei Problemen den Scanner testweise als einziges USB-Gerät direkt am Rechner an (neben USB-Tastatur und USB-Maus, falls USB-Tastatur und USB-Maus verwendet werden). Booten Sie dann mit eingeschaltetem Scanner das System komplett neu. Normalerweise sorgt dabei hotplug dafür, dass die passenden USB-Kernelmodule automatisch geladen werden. Lassen Sie sich direkt nach dem Reboot die USB-Kernelmeldungen mit "dmesg | grep -i usb" anzeigen und suchen Sie darin nach Fehlermeldungen (z.B. "error" oder "fail").

Prüfen Sie, ob die zu Ihrer USB-Hardware im Rechner passenden USB-Kernelmodule geladen sind. Prüfen Sie, ob Ihre USB-Hardware (d.h. der USB Chipsatz) in Ihrem Rechner unterstützt wird. Der Befehl "lspci | grep -i usb" listet die "USB Controller" auf. Siehe http://www.linux-usb.org/

libusb + resmgr + PAM

Beachten Sie, dass sich die Einzelheiten von Version zu Version ändern. Außerdem wird es zukünftige Erweiterungen geben (z.B. "udev", "HAL", ...). Ein Artikel bzgl. "Scanner einrichten" kann nicht alle Details von USB, hotplug, udev, HAL, resmgr, PAM usw. beschreiben. Konsultieren Sie die entsprechende spezifische Dokumentation, wenn es in einem dieser Bereiche Probleme gibt.

Ein Backend greift via libusb auf einen USB-Scanner zu. Das erfolgt via /proc/bus/usb/xxx/yyy (oder via /sys/bus/usb/devices/) wobei xxx (Bus-Nummer) und yyy (Geräte-Nummer) nicht vorher festgelegt sind. Es wird beim Zugriff via libusb (seit Kernel 2.6) keine feste Gerätedatei (wie etwa /dev/usbscanner beim 2.4 Kernel) verwendet, sondern bei jedem Booten werden die Einträge unter /proc/bus/usb/ neu erzeugt. Daher können Zugriffsberechtigungen nicht mehr dauerhaft mit "chmod" festgelegt werden.

Die Zugriffsberechtigung prüft libusb via resmgr (libusb ist gegen libresmgr gelinkt, siehe "ldd /usr/lib/libusb.so").

Welche Benutzer berechtigt sind, auf welche USB-Geräte zuzugreifen, ist in /etc/resmgr.conf festgelegt:

 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
 

Alle USB-Geräte werden zur resmgr-Klasse "desktop" hinzugefügt, ausser Geräten der USB-Geräteklassen

• 3: HID (Human Interface Devices), also Tastaturen und Mäuse
• 9: Hubs

Der Zugriff auf die Geräte in der resmgr-Klasse "desktop" wird erlaubt, wenn sich der Benutzer wie folgt angemeldet hat:

• Via Textconsole (tty=...tty[1-9]*)
• Via graphischem Login mit XDM oder KDM (tty=:0 - d.h. nur für die erste X Session)

Der resmgr wird beim Anmelden via Textconsole oder XDM/KDM von einem PAM-Modul aufgerufen und über jede neue Anmeldung eines Benutzers informiert. Das ist in folgenden PAM-Konfigurationsdateien festgelegt:

• Standardmäßig für Login via Textconsole in /etc/pam.d/login
• Standardmäßig für Login via XDM/KDM in /etc/pam.d/xdm und /etc/pam.d/xdm-np
• Optional für Login via ssh in /etc/pam.d/sshd

Damit wird erreicht, dass standardmäßig nur lokal angemeldete Benutzer Zugriff haben.

Wenn ein Benutzer so angemeldet ist, dass der Zugriff erlaubt ist, dann ist der Zugriff für alle Prozesse dieses Benutzers erlaubt.

Für Pseudo-Terminals (pts) wird kein PAM-Modul aufgerufen da es sich um keine echte Anmeldung (login) am System handelt. Daher wird hier der resmgr nicht informiert. Das ist bedeutsam, wenn nach Anmeldung via Textconsole die graphische Oberfläche mit "startx" gestartet wird, denn Terminalemulationsprogramme (wie z.B. xterm oder die KDE-Terminalemulation) verwenden Pseudo-Terminals.

• Wird die graphische Oberfläche mit "startx" gestartet, dann läuft der Benutzerprozess (die Login-Shell) auf der Textconsole weiter und der Zugriff bleibt auch unter der graphischen Oberfläche erlaubt.
• Wird die graphische Oberfläche aus Sicherheitsgründen mit "startx & exit" gestartet, dann wird der Benutzerprozess auf der Textconsole beendet und unter der graphischen Oberfläche ist kein Zugriff mehr möglich.
• Wird die graphische Oberfläche aus Sicherheitsgründen mit "exec startx" gestartet, dann läuft der Benutzerprozess auf der Textconsole weiter und der Zugriff bleibt auch unter der graphischen Oberfläche erlaubt. Die Login-Shell wurde aber beendet und durch "startx" ersetzt.

Eine alternative Möglichkeit, die Zugriffsberechtigungen via "devgid" und "devmode" in /etc/fstab für das usbfs (USB-Filesystem) festzulegen, ist in den Man-Pages zu "sane-usb" und "mount" beschrieben. Hierbei ist es allerdings weder möglich, nach der USB-Geräteklasse zu unterscheiden, noch kann die die Art der Anmeldung (lokal oder remote) berücksichtigt werden.

Eine andere Alternative bietet der "saned", der Scannen via Netzwerk ermöglicht. Der saned wird auf dem Server via "xinetd" gestartet. Das Scannen via Netzwerk erfolgt auf dem Client, indem dort das "net" Backend verwendet wird. Siehe "man saned" und "man sane-net". Das kann auch auf dem lokalen Rechner verwendet werden, denn dort steht das Loopback-Netzwerk zur Verfügung. Server und Client sind dann derselbe Rechner "localhost". Um auf dem lokalen Rechner als normaler Benutzer auf einen Scanner zuzugreifen, der eigentlich nur als root angesprochen werden kann (z.B. Parallelport Scanner) sind folgende Schritte nötig:

1. Den saned als root laufen lassen (Voreinstellung in /etc/xinetd.d/sane-port).
2. In /etc/sane.d/saned.conf den Zugriff von "localhost" erlauben.
3. In /etc/sane.d/net.conf "localhost" als Server eintragen.
4. In /etc/sane.d/dll.conf das "net" Backend aktivieren.

Der Zugriff kann via /etc/sane.d/saned.users auf gewisse Benutzer mit gewissen saned-spezifischen Passwörtern eingeschränkt werden, wobei nur root diese Datei lesen können darf um die Passwörter zu schützen.

SANE-Backends

Jedes Backend hat eine eigene Konfigurationsdatei /etc/sane.d/Backend.conf und eine eigene Man-Page dazu: "man sane-Backend". Hierbei ist "Backend" durch den Namen des jeweiligen Backends zu ersetzen.

Ein spezielles Backend hat eine besondere Funktion: Das "dll" Backend ist ein sog. "Meta-Backend" (siehe http://www.sane-project.org/html/doc005.html). Das dll Backend ermöglicht einem einzelnen Frontend über verschiedene andere Backends auf verschiedene Scanner zuzugreifen. Der Zugriff erfolgt dann so:

                 Benutzer
                    |
                 Frontend
                    |
     ------ dll Meta-Backend ------
    |                              |
Backend_A                      Backend_B
    |                              |
   ...                            ...
    |                              |
Scanner A                      Scanner B

Das dll Meta-Backend ist immer zwischengeschaltet, auch wenn nur ein Scanner vorhanden ist.

In der Konfigurationsdatei des dll Meta-Backends /etc/sane.d/dll.conf müssen die Backends aktiviert sein, die vom Meta-Backend dll verwendet werden sollen, etwa

 # SANE Dynamic library loader config
 Backend_A
 Backend_B
 #Backend_C
 

In diesem Fall sind "Backend_A" und "Backend_B" aktiviert und "Backend_C" ist deaktiviert.

Normalerweise sollte alleine die Aktivierung des passenden Backends in /etc/sane.d/dll.conf genügen, um einen USB-Scanner in Betrieb zu nehmen, nämlich dann, wenn das USB-System und der resmgr normal funktionieren und das Backend den USB-Scanner automatisch findet und wenn der Scanner seine Firmware fest eingebaut hat.

Wenn mehrere Backends gleichzeitig aktiviert sind, kann es passieren, dass sich die Backends nicht vertragen (vergl. den Absatz zu "Image Scan" im Abschnitt "Scanner" oben). Probieren Sie dann, ob es funktioniert, wenn Sie zur selben Zeit maximal ein Backend aktiviert haben. Sie können so feststellen, ob ein Backend grundsätzlich nicht funktioniert, oder ob es nur zusammen mit einem bestimmten anderen Backend zu Problemen kommt.

Abhängig vom Scannermodell, von der Art wie es angeschlossen ist (z.B. via USB oder SCSI) und vom jeweiligen Backend können manuelle Anpassungen in /etc/sane.d/Backend.conf notwendig sein. Lesen Sie in jedem Fall vorher die Kommentare in /etc/sane.d/Backend.conf und die Man-Page zum jeweiligen Backend: "man sane-Backend"!

Beispiele:

Normalerweise findet ein Backend die von ihm unterstützten USB-Scanner automatisch. Wenn nicht, dann sollte es möglich sein in /etc/sane.d/Backend.conf eine Zeile der Art

usb 0xVVVV 0xMMMM

einzutragen. Dabei ist für 0xVVVV die hexadezimale Vendor-ID (Herstellernummer) und für 0xMMMM die hexadezimale Model-ID (Modellnummer) gemäss der Ausgabe von "lsusb" einzutragen. Evtl. ist aber bei gewissen Backends das Format "usb 0xVVVV 0xMMMM" anders oder gar nicht möglich, siehe die Man-Page zum jeweiligen Backend.

Für SCSI-Scanner ist die SCSI Gerätedatei in /etc/sane.d/Backend.conf in einer Zeile der Art

scsi /dev/sg0

einzutragen. Achtung: Eine falsche SCSI Gerätedatei kann Ihr System unbrauchbar machen!

Für Parallelport-Scanner ist in /etc/sane.d/Backend.conf eine Zeile der Art

ieee1284 parport0

(z.B. in /etc/sane.d/canon_pp.conf)

pio 0x378

(z.B. in /etc/sane.d/epson.conf)

device 0x378

oder

parport0

(z.B. in /etc/sane.d/plustek_pp.conf) manuall einzutragen. Achtung: Ein falscher Eintrag kann Ihr System unbrauchbar machen!

Für manche Scanner muss passende Firmware in den Scanner geladen werden. Dazu ist die passende Firmware-Datei zu beschaffen (fragen Sie den Hersteller) und es muss in /etc/sane.d/Backend.conf der Firmware-Dateiname passend eingetragen werden. Achtung: Falsche Firmware kann den Scanner beschädigen!

Da ein Backend normalerweise für mehrere Scannermodelle geeignet ist, müssen die Voreinstellungen den kleinsten gemeinsamen Nenner aller unterstützten Modelle wiederspiegeln. Daher kann es sinnvoll sein, die Einstellungen für ein spezielles Modell in /etc/sane.d/Backend.conf zu optimieren. Achtung: Falsche Einstellungen könnten den Scanner evtl. beschädigen!

Frontend

Verwenden Sie zumindest zum Testen das Kommandozeilenfrontend "scanimage" (siehe "man scanimage").

Mit "scanimage -L" muss Ihr Scanner angezeigt werden. Wenn nicht, dann kann SANE (genauer das Backend) nicht auf den Scanner zugreifen. Wenn "scanimage -L" nur dann den Scanner anzeigt, wenn es vom Benutzer root aufgerufen wird, dann kann zwar root auf den Scanner zugreifen, aber kein normaler Benutzer. Das Problem liegt dann in der "libusb + resmgr + PAM" Schicht. Die "scanimage -L" Ausgabe hat bei einem USB-Scanner die Form

device 'Backend-Name:libusb:Bus-Nummer:Geräte-Nummer' ...

und bei einem SCSI-Scanner beispielsweise:

device 'Backend-Name:/dev/sg0' ...

Mit "scanimage -d Device >/tmp/image.pnm" wird eine Vorlage vom Scanner eingescannt und das Ergebnis wird in der Datei /tmp/image.pnm gespeichert. Für Device ist dabei genau die "scanimage -L" Ausgabe einzusetzten, also etwa so:

scanimage -d backend:libusb:123:456 >/tmp/image.pnm

Das Einscannen erfolgt dabei mit den Voreinstellungen des jeweiligen Backends.

Mit "scanimage -d Device -h" werden alle verfügbaren Optionen ausgegeben. Im ersten Teil die allgemeinen Optionen, die vom jeweiligen Backend unabhängig sind. Im zweiten Teil folgen die backend-spezifischen Optionen mit den möglichen Werten bzw. Wertebereichen und der jeweiligen Voreinstellung in eckigen Klammern, z.B.:

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.

Um ein Schwarzweissphoto im 10x15 cm Hochformat mit 300 Dpi einzuscannen, könnte dementsprechend etwa folgender Befehl einzugeben sein:

scanimage -d backend:libusb:123:456 --mode Gray --resolution 300 -x 100 -y 150 >photo.pnm

Fehlersuche (Debugging)

Zur Fehlersuche sind Debug-Meldungen der verschiedenen Schichten in SANE und der Test-Modus von "scanimage" hilfreich. Siehe "man sane-usb", "man sane-scsi", "man sane-dll", "man sane-Backend" und "man scanimage". Hierbei ist "Backend" durch den Namen des jeweiligen Backends zu ersetzen. Für "Device" ist entweder auch der Name des jeweiligen Backends einzusetzen oder "Device" ist durch ein komplettes SANE-Device zu ersetzen, etwa "backend:libusb:123:456" (vergl. den Abschnitt "Frontend").

Beispiele:

Test ohne Debug-Meldungen:

scanimage -d Device -T && echo OK || echo FAILED

Test nur mit Debug-Meldungen des "dll" Meta-Backends (nützlich, wenn z.B. das "dll" Meta-Backend das eigentliche Backend bzw. die Backend-Bibliothek "/usr/lib[64]/sane/libsane-Backend.so..." nicht finden oder nicht laden kann):

export SANE_DEBUG_DLL=4
scanimage -d Device -T && echo OK || echo FAILED
unset SANE_DEBUG_DLL

Test nur mit Debug-Meldungen des eigentlichen Backends (das ist abhängig vom jeweiligen Backend, siehe "man sane-Backend"):

export SANE_DEBUG_Backend=128
scanimage -d Device -T && echo OK || echo FAILED
unset SANE_DEBUG_Backend

Test nur mit Debug-Meldungen bzgl. des USB-Systems (bzgl. SCSI siehe "man sane-scsi"):

export SANE_DEBUG_SANEI_USB=128
scanimage -d Device -T && echo OK || echo FAILED
unset SANE_DEBUG_SANEI_USB

Kombinationen sind möglich, erschweren aber evtl. die Fehlersuche weil es dann leicht zu viele Debug-Meldungen auf einmal sind:

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

Wichtige Unterschiede zu SUSE LINUX 9.1

• Bei SUSE LINUX 9.1 gibt der resmgr den Zugriff nur für die USB-Geräte frei, deren Vendor- und Model-ID in /etc/hotplug/usb/sane-hardcoded.usermap und/oder in /etc/hotplug/usb/sane.usermap eingetragen ist. Einen Eintrag in letztere Datei sollte YaST automatisch machen. Es wird hierbei zusätzlich auch hotplug benötigt, was die entsprechenden Geräte zur "desktop" Klasse des resmgr hinzugefügt. Bei SUSE LINUX 9.2 sind alle USB Geräte (außer Tastauren, Mäusen und Hubs) standardmäßig in der "desktop" Klasse des resmgr (siehe den Abschnitt "libusb + resmgr + PAM"). Bei SUSE LINUX 9.2 zeigt YaST bei USB-Scannern sicherheitshalber eine längere Information bzgl. USB, hotplug und resmgr an. Normalerweise sollte aber bei SUSE LINUX 9.2 ein USB-Scanner ohne Probleme beim Zugriff via resmgr funktionieren. Wenn nicht, ist es wahrscheinlich ein USB Problem, siehe die Abschnitte "USB-Hardware im Rechner + USB-Kernelmodule + hotplug" und "USB-Kabelverbindung und evt. zusätzliche USB-Hubs".
• Bei SUSE LINUX 9.1 wird kein PAM-Modul für den resmgr beim Anmelden via Textconsole aufgerufen. Deswegen funktioniert bei SUSE LINUX 9.1 der Zugriff via resmgr nur beim Anmelden via XDM/KDM. Bei SUSE LINUX 9.2 funktioniert der Zugriff via resmgr auch beim Anmelden via Textconsole (siehe den Abschnitt "libusb + resmgr + PAM").
• Bei SUSE LINUX 9.2 ist das Paket sane mit libieee1284 Unterstützung für Parallelport-Scanner compliliert. Das sane RPM braucht daher "libieee1284.so.3" was vom neuen Paket "libieee1284" bereitgestellt wird. Dementsprechend sind bei einem Parallelport-Scanner ggf. Einträge in /etc/sane.d/Backend.conf anzupassen (siehe den Abschnitt "SANE-Backends").