# Cups-Server auf ARM-Basis - Closed-Source-Treiber?

## musv

Guten Nachmittag, 

eigentlich bin ich derzeit etwas im Stress. Zeit also für sinnlose Bastelprojekte. 

Die Idee:

Cups kann man ja entweder lokal auf dem eigenen Rechner als Server betreiben (Normalzustand). Man kann aber auch einfach den Cups-Server eines anderen Rechners nutzen. 

Vorteil wäre, dass man die Treiber nur auf einem Rechner - nämlich dem Server - installieren muss und jeder neue Rechner im Netzwerk gleich alle Drucker zur Verfügung hat. 

Jetzt sind das bei mir folgende Drucker, bei denen ich allerdings bisher nur die Closed-Source-Treiber nutze:

Samsung CLP-315w (möglicher Open-Source-Treiber: Splix)

Brother HL-2135w (über VPN, möglicher Open-Source-Treiber: Foomatic-db HL-2140)

Cups-Server wäre dann meine NAS (NSA-325) auf ARM-Basis (ARM v5tel). Auf dem Ding hab ich ein natives Linux installiert. Die Zyxel-Firmware kommt nicht mehr zum Einsatz. 

Jetzt die Probleme:

Bei beiden Druckern kommt noch ein Cups-Wrapper zum Einsatz, der in der Closed-Source-Variante nur für die x86-Architektur existiert. 

Der Cups-Wrapper braucht je nach Dokument eine ziemliche Weile und CPU-Last, bis das Dokument tatsächlich in was für den Drucker Verständliches umgewandelt wurde. Bei der NAS würde dann die Gefahr bestehen, dass das Ding erst mal 'ne halbe Stunde rödeln müsste, bis das Dokument aufbereitet ist.

Es ist fraglich, ob die freien Treiber die Druckqualität der Herstellertreiber erreichen.

Ist meine Idee jetzt sinnvoll oder eher Aufwand ohne jeglichen Nutzen mit zweifelhafter Realisierbarkeit?

----------

## l3u

Sind die CUPS-Wrapper nicht einfach nur Shell-Scripte? Ist schon etwas her, dass ich diverse Brother-Drucker auf diversen Gentoo-Rechnern installiert habe, aber ich denke, da musste ich nur Shell-Scripte extrahieren bzw. "kompilieren", also mit anderen (mitgelieferten?) Scripts an die lokalen Pfade anpassen, und der Rest waren externe Abhängigkeiten.

```
$ head /usr/local/Brother/cupswrapper/cupswrapperMFC7440N-2.0.2

#! /bin/sh

#

# Brother Print filter

# Copyright (C) 2005 Brother. Industries, Ltd.

# This program is free software; you can redistribute it and/or modify it

# under the terms of the GNU General Public License as published by the Free

# Software Foundation; either version 2 of the License, or (at your option)

# any later version.
```

Ich kann mich aber auch täuschen … war jedes Mal wieder ein Erlebnis (auch, wenn’s jedes Mal geklappt hat ;-)

----------

## musv

Hab mal nachgesehen. Zumindest die Cups-Filter der Closed-Source-Treiber sind Binaries. 

```
ELF Header:

  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
```

Und bei rastertosamsungplc steht sowas ähnliches da.

Damit wäre wieder mal bewiesen, wie wichtig Open Source ist.

----------

## l3u

Dann hast du wohl schlechte Karten auf ARM …

----------

## musv

Naja, war eh nur 'ne Idee. Bei großen Dokumenten braucht mein Xeon schon 'ne Weile bis das Postscript in die Samsung-Sprache umgewandelt wird. Wenn ich das Ding jetzt auf ARM laufen lassen würde, bräuchte das Dokument vermutlich 'ne halbe Stunde, bis was aus dem Drucker rauskommen würde. 

Zumindest meine Frau würde dann ihre Sachen vermutlich 30x zum Drucker schicken.

----------

## schmidicom

Anscheinend kann man mit qemu Programme (vermutlich aber auch nur statisch gelinkte) laufen lassen welche für eine andere Prozessorarchitektur kompiliert wurden.

Das folgende Beispiel lässt sich vielleicht auch umdrehen wenn du qemu auf deinem NAS installiert bekommst.

http://tuxthink.blogspot.ch/2012/04/executing-arm-executable-in-x86-using.html

----------

## tazinblack

 *musv wrote:*   

> Hab mal nachgesehen. Zumindest die Cups-Filter der Closed-Source-Treiber sind Binaries. 
> 
> ```
> ELF Header:
> 
> ...

 

Oder wie sch.... doch Samsung ist. 

Ich hab hier einen CLX-3185 und musste auch schon mal feststellen, dass das ein ziemlicher Mist ist mit dem rastertosamsungplc.

Aber an der Stelle stellt sich mir immer die Frage: "Was kauf ich denn nächstes Mal für nen Drucker?"

Bis eben dachte ich, dass bei Brother alles Open Source ist, was wohl auch nicht der Fall ist.   :Crying or Very sad: 

----------

## l3u

… aber Brother funktioniert zumindest super mit Linux … auch Scannen übers Netzwerk und sowas …

----------

## musv

schmidicom:

Mein Xeon rechnet bei größeren/komplexen Dokumenten schon mal ca. 20 Sekunden (Single-Thread) mit dem Cups-Filter, um für den Drucker verwertbare Daten zu bekommen.

Bei ARM würde ich grob schätzen, dass ein natives rastertosamsungplc, sofern es denn geben würde, ca. 2 Minuten brauchen würde. 

Und jetzt versuchen wir mal x86 auf ARM zu emulieren. Das Drucken auf der NAS würde dann vermutlich 10 Minuten brauchen, bis der Drucker überhaupt einen Mucks machen würde. Die Qemu-Lösung hätte damit nur den Forschungscharakter eine Machbarkeitsstudie.

l3u:

Der Samsung-Treiber funktioniert genauso wieder Closed-Source-Brother-Treiber. Denn auch bei dem Brother-Treiber (HL-2130) gibt es einen Binär-Cups-Filter. 

Ich glaub, die Situation ist etwas komplexer. Linux-Nutzer heulen immer rum, dass die Hersteller keine Treiber für ihre Geräte liefern. Bei Druckertreibern haben wir seit Jahren die komfortable Situation, dass die meisten Hersteller einen CUPS-Linuxtreiber zur Verfügung stellen. Das liegt vermutlich vor allem daran, dass diverse Druckserver in großen Unternehmen und an Unis unter Linux laufen. Damit würden die Hersteller ohne Treiber vermutlich spürbare Umsatzeinbußen erleiden.

Sowohl für meinen Samsung- als auch für den Brotherdrucker gibt es auch Open-Source-Treiber. In manchen Fällen muss man sich noch irgendwoher die Farbprofile besorgen, die aus lizenzrechtlichen Gründen den freien Treibern nicht beiliegen (können). Auch soll die Druckqualität spürbar geringer sein. Die Samsung-Treiber sind durch Reverse-Engineering entstanden.

Ein vorbildlicher Hersteller (der einzige?) ist HP. Hatte vor 2 Jahren bei meiner Schwägerin mal Open Suse installiert, da Win7 zu katastrophal auf ihre alten Kiste lief. Bei ihrem Multifunktions-Tintenkleckser hatte ich die größten Bedenken, das Billig-Ding zum Laufen zu kriegen. Aber oh Wunder, über die HPLIP funktionierten sowohl der Scanner als auch der Drucker problemlos.

Das Fazit ist die altbekannte Herangehensweise beim Hardwarekauf: Vorher informieren, wie die Treibersituation aussieht. 

Meinen Samsung CLP-315w würde ich vermutlich heute nicht mehr kaufen. Bei der Treiberinstallation muss man frickeln, da Samsung noch einen zusätzlichen Druckdialog vor lp schaltet, was ziemlich nervt. Außerdem sind die Toner relativ klein. Samsung hatte mal ein Firmware-Update veröffentlicht, dass man nur mit originalen Samsung-Tonern drucken darf. Zum Glück scheint diese Restriktion bei mir nicht zu funktionieren. Ich hatte die Tonerpatronen schon mal selbst befüllt. Gekauft hatte ich mir das Teil vor 4 Jahren, da es damals einfach keinen vergleichbaren Drucker (Laser, Farbe, Wlan/Lan) zu diesem Preis (185€) gab.

----------

## bbgermany

 *musv wrote:*   

> Ein vorbildlicher Hersteller (der einzige?) ist HP. Hatte vor 2 Jahren bei meiner Schwägerin mal Open Suse installiert, da Win7 zu katastrophal auf ihre alten Kiste lief. Bei ihrem Multifunktions-Tintenkleckser hatte ich die größten Bedenken, das Billig-Ding zum Laufen zu kriegen. Aber oh Wunder, über die HPLIP funktionierten sowohl der Scanner als auch der Drucker problemlos.

 

Dem kann ich nur zustimmen. Mein HP Color LaserJet CP2025dn sowie mein HP DeskJet 1050A laufen mit HPLIP super auf meinem Cubietruck (Scan- und Printserver). Leider scheinen einiger Hersteller es immer noch nicht begriffen zu haben, dass eine PPD-Datei mehr wert ist als ein Binärtreiber. Aber leider hat auch MS da seine Finger mit drin, siehe: GDI Drucker...

MfG. Stefan

----------

## schmidicom

Kyocera hat auch Modelle welche ohne einen binaren Filter auskommen und trotzdem genau so gute Ergebnisse erzielen wie unter Windows.

----------

## bbgermany

 *schmidicom wrote:*   

> Kyocera hat auch Modelle welche ohne einen binaren Filter auskommen und trotzdem genau so gute Ergebnisse erzielen wie unter Windows.

 

Das sind dann aber bestimmt keine GDI Drucker, oder?

MfG. Stefan

----------

## schmidicom

 *bbgermany wrote:*   

>  *schmidicom wrote:*   Kyocera hat auch Modelle welche ohne einen binaren Filter auskommen und trotzdem genau so gute Ergebnisse erzielen wie unter Windows. 
> 
> Das sind dann aber bestimmt keine GDI Drucker, oder?
> 
> MfG. Stefan

 

Nein, die Modelle welche ich meine haben in der Regel ein eingebautes RIP und werden mit KPDL/PS angesprochen.

Aber wer was richtig gutes haben will darf eben nicht bei den Anschaffungskosten sparen.

----------

## l3u

In Anbetracht der Tatsache, dass ich einen Brother HL-1230 (nur mit Parallel-Anschluss!) mein Eigen nenne, der seit 2003(!) seinen Dienst erfüllt, mein komplettes Studium und das meiner Frau (damals Freundin) und meine Dissertation ca. 100 mal ausgedruckt hat und immer noch 1A läuft, muss ich sagen, dass ich trotz Allem Brother-Fan bin. Egal wie.

----------

## musv

Guten Morgen, 

ich hol mal mein Thema wieder aus der Versenkung und geb mal ein paar Fort-/Rückschrittsmeldungen. 

Treiberwechsel Samsung Unified Printer Driver -> Splix

Aufgrund des gcc-Updates auf 5.x hat's mir den Samsung-Treiber zerschossen (benötigt libstdc++5). Also hab ich mich mal hingesetzt und  Splix zum Laufen gebracht. Natürlich ist das Ganze etwas heimtückischer als man auf den ersten Blick vermutet:

Das Ebuild im Portage lädt nichts mehr runter. Hab dazu einen Bug-Report aufgemacht. 

Die Dateien auf der Source-Forge-Seite sind auch noch hoffnungslos veraltet.

Einen Fork findet man hier. Allerdings scheiterte git clone auf merkwürdige Weise bei mir. Also hab ich es als Zip runtergeladen.

Die Installation ist dann wie gehabt. Ein make baut die pstoqpdl und rastertoqpdl. Die beiden Dateien schmeißt man nach /usr/libexec/cups/filter. Dann muss man noch den Ordner mit den CMS-Dateien vom Unified-Treiber nach /usr/libexec/cups/profiles/samsung verlinken / kopieren. Und in Cups selbst wählt man einfach die entsprechende PPD-Datei. Das war's. 

Bei der Qualität rätsel ich noch, ob der Unified-Treiber jetzt tatsächlich sichtbar bessere Ergebnisse liefert. Ich hab den Eindruck, die Farben sind beim Splix-Treiber etwas dunkler. Aber Fotos will man mit dem Samsung CLP-315 ja sowieso nicht ausdrucken. Ausgedruckte Texte sehen jedenfalls einwandfrei aus. Da gibt's keinen Unterschied zum offiziellen Samsung-Treiber. 

ARM-Printserver

Meine NAS wird unter Arch-Linux betrieben, da ich dort keine Tage Downtime riskieren will. Die Cups- und Splix-Installation sowie Druckereinrichtung war dort problemlos. Die Testseite wurde auch ordentlich gedruckt. Ach ja, wie befürchtet, dauert das Drucken von Grafiken natürlich ewig. Allein schon die Cups-Testseite benötigte schon mal ca. 30 Sekunden, bevor der Drucker überhaupt anfing, grün zu blinken.

Jetzt kommen wir zum Problem: Das Ansprechen des Cups-Servers von anderen Rechnern aus. 

Früher konnte man das mal über die /etc/cups/client.conf erledigen. Einfach dort den Servernamen rein. Und schon hatte man direkten Zugriff auf den Printserver und brauchte auch lokal keine Druckertreiber mehr zu installieren. Das wollte ich. Dummerweise scheint es dieses Feature nicht mehr zu geben. Siehe dazu Arch-Wiki. Ok, der Nachteil dieser Lösung war halt, dass man nur einen Server damit ansprechen konnte. 

Die "neue" Lösung soll sein, dass freigegebene Drucker anderer Server direkt in Druckerliste des lokalen Cups-Servers eingebunden werden. Blöderweise scheint dafür Avahi zwingend notwendig zu sein.  Bisher bin ich ohne Avahi ausgekommen. Ich mag diese Lösung nicht sonderlich. 

Vielleicht verfolg ich das Thema in ein paar Monaten mal erneut.

----------

## l3u

Häng doch den Drucker nicht an ein NAS, sondern einfach direkt ins Netzwerk!

Wenn er keinen Netzwerkanschluss hat, dann würde ich mir einen Druckerserver holen. Die sind ja relativ günstig. Dann kann man den Drucker einfach als Netzwerkdrucker zum lokalen CUPS-Server hinzufügen. So mach ich das daheim mit unseren zwei Druckern, einer ist selber netzwerkfähig, der andere hat einen Druckerserver (Parallel → LAN, die o. g. alte Kiste ;-).

Funktioniert einwandfrei!

----------

## musv

 *l3u wrote:*   

> Häng doch den Drucker nicht an ein NAS, sondern einfach direkt ins Netzwerk!

 

Der Drucker hängt am Netzwerk. Installiert ist aber noch zusätzlich der Drucker meines Vaters (über VPN) und cups-pdf.

Das Ziel ist eigentlich, dass jeder Rechner, der sich bei mir im Netzwerk anmeldet, die Drucker des Cups-Servers auf der NAS nutzen kann, ohne eigene Treiber installieren zu müssen. 

Nur leider scheint die Freigabe nicht ohne Avahi zu funktionieren.

----------

## Christian99

es gibt clientseitig cups-browsed, das pollt regelmäßig die angegebenen server und stellt alle freigegebenen drucker lokal zur verfügung. ohne avahi

----------

