Schlagwort-Archive: Sane

Linux/Sane: Segfault mit Panasonic/Matsushita KVS-50xx-Scanner

Business as usual: Pünktlich zum Jahresanfang wird man von sämtlichen Vertragspartnern mit totem Baum zugeworfen. Glücklicherweise habe ich passende Scanner, die das Material in etwas besser verwaltbare Formen überführen können. Zuletzt verwendete ich dazu einen Panasonic/Matsushita KVS-5026, welchen ich aus dem Schrott retten konnte. Zwar habe ich noch einige schnellere Modelle, dieser hatte jedoch bisher die wenigsten Probleme mit Double-Feeding und ist durch die Bauform bei mir einfacher zu nutzen.

Leider war der Start dieses Jahr nicht ganz so erfolgreich – der Scanner wird korrekt erkannt, versuchte ich jedoch einen Scan zu starten gab es den allseits beliebten „Segmentation fault“. Boo.

Der Trick des letzten Problems half dieses mal leider nicht – auch die aktuelle GIT-Version zeigen den selben Fehler. Da es für das passende Backend kvs20xx keinen Maintainer gibt ist wohl auch keine Besserung zu erwarten.

OK, ich bin kein C-Programmierer, habe keine Ahnung von Debuggern unter X86 und produziere auch sonst eher nicht qualitätsorientieren Code – was kann schon schief gehen.

Ein paar Debug-Textausgaben später konnte ich den Fehler auf die Funktion sane_open, genauer die erste „echte“ Codezeile dort „for (i = 0; devlist[i]; i++)“ eingrenzen. Offenbar wurde früher durch sane automatisch ein Scan iniziiert und die devlist daher gefüllt. In der aktuellen Version scheint es beim Aufruf leer zu sein und mit NULL hantieren mag C wohl nicht. Als workaround konnte ich ein paar Zeilen des Fujitsu-Treibers ruberkopieren, welche die Inizialisierung ggf. nachholen. Auch diese musste etwas angepasst werden um mit dem direkten Aufruf umgehen zu können. Immerhin: Der Scanner läuft und ich kann weitermachen. Fein.

 

Upstream: #315625

Fujitsu Scanner-Fehler mit Sane & aktuellen Kernel

Dokumentenscanner von Fujitsu sind schnell und teuer – es sei denn die Windows-Unterstützung fällt weg. Ältere Modelle wie der fi-4120 laufen nur bis Windows XP zuverlässig, mit Windows 7/8/10 schaut man in die Röhre, vor allem wenn 64 Bit im Spiel sind. Kein Wunder, dass die ehemals fast 700€ teuren Geräte jetzt für gebraucht für wenig Geld zu finden sind. Unter Linux ist das ganze eigentlich recht entspannt: Die Geräte werden durch Sane unterstützt und sind entsprechend problemlos nutzbar. Ich selbst habe einen solchen schon länger an einem Raspi im Betrieb um Briefe & Co. zu digitalisieren.

Leider scheint das „Problemlos“ momentan eine Auszeit zu nehmen: Bei anderen Anwendern aus der hiesigen Linux User Group macht der Scanner in letzter Zeit Probleme: Nach dem Einschalten sieht alles OK aus, versucht man jedoch zu scannen erhält man einen „Error during device I/O“. Am OS sollte es nicht hängen – sowohl mein Raspi als auch der betroffene Rechner laufen mit Arch. Auch die „üblichen“ Tipps, namentlich „keine USB-Hubs“, trafen nicht zu.

Also: Debuggen. Während bei meinem Netbook und dem Raspi keine Fehler auftreten kann ich ihn mit Laptop und einem PC nachvollziehen. Erstere arbeiten mit ARM bzw. einer 32 Bit CPU und unterstützen nur USB 2.0, letztere sind 64 Bit mit USB 3.0. Zur Übersichtlichkeit habe ich erst mal alle Treiber außer Fujitsu aus /etc/sane/dll.conf entfernt. Den Debug-Modus für Sane und den Treiber aktiviert man mit folgenden Zeilen:

Nach dem Einschalten taucht der Scanner wie üblich in lsusb auf. Auch sane-find-scanner kann die USB-ID erkennen. scanimage -L zeigt dem Scanner im ersten Durchlauf ebenfalls, führt man den selben Befehl jedoch erneut aus tauchen USB-Fehler auf. IO-Error, Invalid Argument, etc. Ausgerüstet mit den passenden Logs findet sich in den Quellen des Sane-Projektes ein passender Commit vom 16.12.2014, welcher einen Workarround für aktuelle Kernel-Images bereitstellt. Hier ist offenbar eine Regression, welche die Ansteuerung der Fujitsu-Scanner betrifft. Worth a try, also schnell mal das ältere sane-Paket deinstalliert und stattdessen sane-git aus AUR installiert. Siehe da: Läuft. Soweit ich erkenne betrifft der Fehler nur einige USB-Controller, was ggf. erklärt warum ich auf meinem Raspi keine Fehler finden konnte.

tl;dr: GIT ist manchmal doch funktionsfähiger als stable

Scanner-Button unter Arch Linux

Gesehen habe ich sie schon oft, die Hardware-„Scan“-Tasten diverser Scanner – einen wirklichen Sinn haben sie für mich nie ergeben, sind doch üblicherweise Scanner und Tastatur nicht sonderlich weit voneinander entfernt. Nun habe ich für ein autonomes Scansystem einen Raspi ohne Monitor mit Scanner und Scripten verknüpft – wäre praktisch, wenn ich mir jetzt noch die Scan-Taste nutzbar machen könnte, oder?

Das Zauberwort schien erst „scanbuttond“ zu lauten, welches für Arch im AUR verfügbar ist – andere Distributionen scheinen ebenfalls großteils Pakete bereit zu stellen. Nach der Installation kann man mit dem Befehl

scanbuttond -f

prüfen, ob der Scanner unterstützt wird: Das Programm startet kommentarlos im Vordergrund, sollte beim Drücken des Scan-Knopfes jedoch eine passende Meldung erzeugen. Sollte – in meinem Falle leider nicht. Auslöser ist vermutlich die neuere libusb, welche scanbuttond das Gerät nicht finden lässt.

Nach kurzer Recherche fand ich im Arch-Forum den Verweis auf scanbd – ebenfalls im AUR – welches noch aktiv entwickelt zu werden scheint. Die Einrichtung selbst ist in der Arch-Wiki beschrieben. In der Hoffnung dass mein Gerät sofort funktioniert wird der Daemon mit folgendem Befehl gestartet:

scanbd -d 7 -f

Die Ausgaben sind etwas chaotisch, jedoch ist definitiv mein Scannermodell zu erkennen und auch beim Drücken der Scan-Taste ist etwas passendes zu sehen:

scanbd: trigger action for scan for device fujitsu:fi-4120Cdj:13715 with script test.script
[…]
scanbd: append string fujitsu:fi-4120Cdj:13715 to signal scan_begin
scanbd: now sending signal scan_begin
[…]

Entsprechend der Anleitung werden die Dateien kopiert (cp /etc/sane.d/* /etc/scanbd/sane.d/), in /etc/sane.d/dll.conf alles bis auf „net“ gelöscht und in /etc/sane.d/net.conf der Server „localhost“ aktiviert. In /etc/scanbd/sane.d/dll.conf wiederum wird „net“ gelöscht.

Der Scan-Button ist bereits mit /etc/scanbd/test.script vorbelegt, der Einfachheit halber habe ich nur den Inhalt der Datei durch meine Befehle ersetzt. Es wäre auch möglich die zahlreichen Zusatztasten meines Scanners zu nutzen um so bereits einen Speicherort o.Ä. zu definieren oder z.B. den Scan bereits beim einlegen des Papiers zu starten, aber ich belasse es erst mal beim Standard. Unter Arch sollte man nach der Konfiguration noch das Debuglevel in /etc/scanbd/scanbd.conf senken, ansonsten wird das Systemlog durch die sekündlichen Prüfroutinen gut gefüllt.

Dank der kleinen Bastellösung kann ich nun „ohne PC“ scannen – Papier rein, Knopf drücken und der Raspi übernimmt automatisch das einscannen, OCR und archivieren mit (zumindest meistens) brauchbaren Metadaten – der Feinschliff kann dann später am PC erfolgen.