Leidiges Thema: CUPS und XSANE

[mr44er]

N'abend

Es geht um folgendes Multifunktions-Gerät: Canon MP550

dmesg | grep Canon
ugen2.3: <Canon> at usbus2
umass0: <Canon MP550 series, class 0/0, rev 2.00/0.04, addr 3> on usbus2
da0: <Canon MP550 series 0104> Removable Direct Access SCSI-2 device
ulpt0: <Canon MP550 series, class 0/0, rev 2.00/0.04, addr 3> on usbus2

umass0 und da0 können ignoriert werden. Das sind die Kartenslots, die benutze ich nicht.

Gestern habe ich zuerst CUPS mit libusb gebaut und die Anweisungen nach dem Bauen des Ports befolgt, FALLS man mit libusb baut und das Gerät per USB anschließt.

cupsd_enable="YES"
devfs_system_ruleset="system"

hab ich in die rc.conf eingetragen. Was genau bewirkt das devfs? Ist das sowas wie ein Berechtigungslayer? Wieso schreibt man die Berechtigung nicht direkt fest?

Egal. wie ich die devfs.rules gefüttert (und devfs immer neustartete), ich konnte unter Lokale Drucker bei CUPS nichts auswählen, es wurde nichts angezeigt.
Durch google konnte ich rausfinden, dass ulpt ein local print port ist und das u drauf hinweist, dass er nur als solchen angesteuert werden will, jedoch per USB verbunden ist.

Also CUPS nochmal ohne libusb gebaut und

[system=10]

add path 'ulpt0' mode 0660 group cups
add path 'ugen2.3' mode 0660 group cups
add path 'usb/2.3.0' mode 0660 group cups       #ugen2.3 zeigt auf usb/2.3.0

devfs.rules damit befüllt. Siehe da, CUPS zeigt USB Printer #1 (Unknown) und USB Printer #1 (no reset) (Unknown). Da ich nicht weiß, was das mit no reset heißt, habe ich den ersten genommen, Treiber etc. eingerichtet, funktioniert wunderbar, alle Funktionen da und ein sauberes Druckbild.
Was hat das mit dem no reset und der 10 in system=10 auf sich?
Im Netz findet man auch Unterschiede bei Anleitungen, die ugen einmal mit '-zeichen und ohne zeigen. Was ist denn davon jetzt richtig?

Da das Drucken nun ging, habe ich mich an den Scanner gemacht.

sane-find-scanner -q
found USB scanner (vendor=0x04a9 [Canon], product=0x173d [MP550 series]) at libusb:/dev/usb:/dev/ugen2.3
scanimage -L
device `pixma:04A9173D_249687' is a CANON Canon PIXMA MP550 multi-function peripheral

Habe dann die Gruppe 'scanner' angelegt und meinen Benutzer hinzugefügt.

Die devfs.rules dann entsprechend editiert:

[system=5]    #Laut einer Anleitung habe ich die 5 übernommen. Ist das eine Priorität oder Reihenfolge beim Abarbeiten?

add path ugen2.3 mode 0660 group scanner
add path usb/2.3.0 mode 0660 group scanner

Da sane-find-scanner -q ja rausfand, dass der Scanner auf ugen2.3 sitzt, habe ich die Zeilen jeweils für CUPS auskommentiert.

Xsane klappte auf Anhieb, aber heute musste ich feststellen, dass das Drucken nicht mehr funktionierte.

Nun habe ich angefangen, rauszufinden, wo der Fehler liegt und habe ausgeklammert und rumprobiert, was wohin genau kommt.
Xsane lässt sich nicht mehr starten, bzw. lässt es sich nur noch im Taskmanager killen, Drucken geht auch nicht.

Es kann ja nur was Banales sein....

 

[mr44er]

Ich habs geschafft!

Eins vorweg: cups-base muss ohne libusb gebaut werden, sonst findet CUPS rein gurnix, nie, never.

Damit ich weniger tippen muss, habe ich die Gruppe 'scanner' wieder gelöscht und stattdessen 'usb' angelegt...damit keine Mißverständnisse aufkommen.

Ich denke, bluescreen hatte hier das gleiche Problem: http://www.bsdforen.de/threads/kleines-scanner-problem.31214/

Wahrscheinlich weils ein "all in one" ist , muss beim
scannen wohl der Drucker angewählt werden.

Das hat mich dann auf die richtige Fährte geführt. Es ist in der Tat so, dass 'ulpt0' zum Drucken und zum Scannen angesprochen werden muss!

Da dachte ich mir, machen wirs uns mal einfach und geben auch jedem Schreib-/Leserechte:

add path 'ulpt0' mode 0666 -> xsane startet nicht, bzw hängt die Instanz fest und muss gekillt werden.


add path 'ulpt0' mode 0666 group usb -> xsane startet nicht, ebenso hängt auch hier die Instanz fest.

Korrekt funktioniert nun:

[system=10]   
add path 'ulpt0' mode 0666 group cups

add path 'ugen2.3' mode 0660 group usb
add path 'usb/2.3.0' mode 0660 group usb

Ich lese da heraus, dass CUPS als 'Sonstige' nicht funktioniert/funktionieren soll (Sicherheit?), XSane aber schon. Kann das jemand bestätigen?

Noch ganz wichtig: Falls das ebenfalls jemand mit einem All-in-one-Gerät nachpopeln möchte, so muss vor jedem

service devfs restart

das USB-Kabel rausgezogen werden und der cupsd gestoppt

service cupsd stop

werden, da sonst die Berechtigungen aus der devfs.rules nicht gesetzt werden (können). Ich vermute, es liegt daran, dass entweder sane oder cups mit den hängenden Instanzen den Zugriff auf die devs blockieren.

Mit

ls -l /dev

sieht man zwar die Änderungen, aber sie greifen nicht, wenn man das USB-Kabel nicht vorher abzieht.