Der Treiber vom Matrox-Server bindet xf86_ansic.h ein. Soweit ich verstehe, ist das aber in aktuellen XF86-Paketen nicht mehr drin.
Damit stehe ich erstmal wieder auf dem Schlauch. Wahrscheinlich ist es das Einfachste, mir eine billige andere GraKa zu holen.
strunz
Vielen Dank für die Antwort.
Daas sdk-Paket hatte ich dann noch auf Verdacht installiert , und tatsächlich findet pkg-config jetzt, was es soll.
Wegen der Frage, was es überhaupt gesucht hat, hatte ich die man page des Werkzeugs befragt. Die sagt.:
NAME
pkg-config - Return metainformation about installed libraries
SYNOPSIS
pkg-config [--modversion] [--help] [--print-errors] [--silence-errors] [--cflags] [--libs] [--libs-only-L] [--libs-only-l]
[--cflags-only-I] [--variable=VARIABLENAME] [--define-variable=VARIABLENAME=VARIABLEVALUE] [--print-variables] [--unin‐
stalled] [--exists] [--atleast-version=VERSION] [--exact-version=VERSION] [--max-version=VERSION] [--list-all]
[LIBRARIES...] [--print-provides] [--print-requires] [--print-requires-private] [LIBRARIES...]
Nirgendwo wird von header-Dateien oder so etwas gesprochen ... Danach habe ich meine Frage gestellt.
Ich muß jetzt erstmal los, im neuen Jahr kann ich weitersehen und werde mich dann hier wieder melden.
strunz
...
Hallo allerseits,
ich habe folgendes Problem:
OpenSuSE11.4, Standard-mga-Treiber der Distribution
Matrox G550 Dual DVI, Samsung Syncmaster SMS24A450, VGA-Anschluß über DVI-VGA-Adapter
Nachdem mein alter Sharp-Monitor, den ich bei 1280x1024 an derselben Graphikkarte mit gleichem Treiber ohne Probleme laufen hatte, nicht mehr wollte, habe ich besagten Samsung-Monitor erworben und angeschlossen.
Graphikkarte und Monitor einigen sich auf die Modeline 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync (74.0 kHz),
allerdings ist die Darstellung am Monitor fehlerhaft und das Adjustment des Monitors ist nicht in der Lage, das zu korrigieren (Bild um etwa 20..30 pixel über den linken Rand hinaus verschoben, Maßstab paßt nicht: Bildschirmpixelabstand<>Darstellungspixelabstand, der Monitor behauptet in seinem Menu, er würde mit 1600 x 1200 angesteuert
obwohl bis auf die links fehlenden etwa 20..30 Pixel sonst zumindest alles auf dem sichtbaren Bereich landet).
Wird der Monitor an einem anderen Rechner mit einer nvidia-Karte unter Debian betrieben, wird lt Xorg-Log dieselbe Modeline benutzt (klar, die gibt ja der Monitor vor), und da paßt alles: Darstellung ok (Monitor Auto-Adjustment geht), Monitor zeigt an daß er mit 1920x1200@60Hz angesteuert wird. Der Monitor ist also ok, und die Schuld liegt anscheinend bei der G550 und/oder dem Treiber.
Ich wollte den Treiber, den es bei Matrox gibt (matrox_driver-x86_64-src-4.4.0), ausprobieren, aber das Paket möchte, daß pkg-config eine Bibliothek namens xorg-server findet, was es nicht tut. Es gibt in den von mir besuchten Repos kein so genanntes Paket; xorg-x11-server hab ich installiert, aber das ist hier wohl nicht gemeint (pkg-config --exists xorg-x11-server endet ebenfalls negativ)..
Falls jemand einen Tip hat, was ich bei dem betagten mga-Treiber der SuSE-Distri noch drehen könnte, oder aber, was dem Matrox-Treiber zum Glück wirklich fehlt (und ob der überhaupt helfen würde), wäre ich sehr dankbar.
strunz
Es ist Neues, aber wenig erfreuliches, zu berichten.
Ich habe nun einen nagelneuen HP Officejet Pro 8500 A e-all-in-one (A910a) im Haus.
Der ist per WLAN verbunden. Ich habe für den Drucker 3 Warteschlangen mittels yast2 eingerichtet:
1. einrichtung mit dem im yast vorgesehenen "hp-setup" und hpijs-Treiber (hp-officejet_pro_8500_a910-hpijs.ppd):
Ausdruck Testseite (2 Seiten) schlägt fehl mit folgender Meldung im cups error log:
D [15/May/2011:11:09:10 +0200] [Job 1673] prnt/hpijs/hpijs.cpp 638: unable to open PrintContext object err=2
D [15/May/2011:11:09:10 +0200] [Job 1673] GPL Ghostscript 9.00: Can't start ijs server "hpijs"
Ich habe, da ich anderso gelesen habe, daß /usr/lib/cups/filter/foomatic auf /usr/lib/cups/filter/foomatic-rip-hplip verweisen müßte, den SymLink entsprechend geändert, also
von
lrwxrwxrwx 1 root root 25 Apr 13 22:50 foomatic-rip -> ../../../bin/foomatic-rip
auf
lrwxrwxrwx 1 root root 18 May 15 11:07 foomatic-rip -> foomatic-rip-hplip
, das half aber nichts.
2. einrichtung mit dem im yast vorgesehenen "hp-setup" und alternativem von yast angebotenen Treiber (hp-officejet_pro_8500_a910.ppd.
Ausdruck Testseiten schlägt ähnlich fehl wie schon in meinen vorangegangenen Beiträgen für den HP DJ 895Cxi mit dem gutenprint-treiber berichtet, indem nämlich die 2. Seite quasi mehrfach gedruckt wird. Um das zu verdeutlichen, hänge ich mal ein Bild des Ausdruckes der 2. Seite an - es gibt allerdings subtile Unterschiede zum vorher Gefundenen: diesmal habe ich 18 kopien, aber das "Hereinfalten von oben" entfällt, was nach unten über den Rand verschoben ist, entfällt diesmal.
Es sieht aber außerdem so aus, als wäre das Farbrad etwas durcheinandergeraten ...
Noch ein (wie ich denker, positiver) Unterschied zum hpijs-Treiber: Es ist auffällig, daß der Strahlenkranz der Testseite (rechts vom Graukeil) deutlich feiner als mit dem hpijs-Treiber gedruckt wird (das kann man im angehängten scan leider nicht sehen).
3. Einrichtung in yast "normal", also ohne "hp-setup" aufzurufen, mit dem hpijs-Treiber (hp-officejet_pro_8500_a910-hpijs.ppd).
Testseiten werden gedruckt,kleiner Fehler (wie scon beim HP DeskJet 895 Cxi), daß nämlich die label am oberen und unteren Seitenrand (<druckername>:Yast2testprint@<hostname>) durchsichtig gedruckt werden, man also den Hintergrund (hier: Zentimeterskala) durchsieht.
Fazit: man muß, falls man auf das yast-Angebot des "hp-setup" hereinfällt, 3 Anläufe nehmen, um den Drucker überhaupt benutzen zu können, wobei der Fehler beim 1. Versuch oben auf einen Fehler der Distribution hindeutet. Der Fehler im 2. Versuch trat mit einem anderen HP-Drucker und dem da verwendeten gutenprint-Treiber bereits ähnlich (aber nicht gleichartig) auf und deutet auf einen Fehler in Cups bzw. den bereitgestellten Treibern hin. Ich nehme an, daß der PS-Druckjob von GS unter Verwendung der PPD-Dateien in den eigentlichen (hier PCL3-)Druckjob übersetzt wird. Ich kann nicht glauben, daß GS buggy ist ...
Aber es ist eben interessant, daß ich mit keiner Vorgängerdistr seit 2000 irgendwelche Probleme dieser Art mit Druckern hatte. Ich befürchte, die Methode der Verschlimmbesserung hält nun auch bei SuSE oder im Linux-Umfeld insgesamt Einzug.
Falls keiner Lösungsvoerschläge hat, hilft dieser Thread vielleicht wenigstens anderen, etwas Zeit zu sparen.
strunz
Ok, noch was:
raw funktioniert jetzt mit der kritischen spreadsheet-Datei -- warum auch immer : die einzige Änderung für den raw-Drucker war, daß er jetzt statt nach USB nach lp0 ausgibt - also doch ***auch*** ein USB-Treiberproblem??
Uwe
l
Wieder da.
parallelport war im BIOS eigentlich aktiviert, und ich hatte vor dem reboot die module gecheckt: lp war da.
Aber erst nach dem reboot konnte ich den parallelport auch ansprechen. komisch.
testseite mit dem hp-treiber sieht soweit ok aus (besser als zuvor), versuche jetzt den gutenprint-treiber.
Aber (keine Ahnung, ob das so sein muß - hatte seit ewigen Zeiten nix mehr mit dem Parallelport zu tun): während der Ausgabe an den Drucker hingen alle ls Kommandos (!), cd ging.
Das erscheint mir recht seltsam und nicht tragbar ...
Auch hier wieder Rätsel: ich drucjke gerade Testseiten mit dem gutenprint-Treiber und ls hängt ***nicht***. Kann doch aber nicht am Druckertreiber liegen, zumal der ja schon lange fertig ist und der Auftrag nur noch übertragen wird ...
Hm, ich wollte gerade schreiben, daß der Drucker am Parallelport funktioniert, aber mit dem gutenprint-Treiber sieht nur die erste der beiden Testseiten soweit ok aus, bei der zweiten werden die Seitenelemente 4 mal, jeweils um knap 1/3 Seitenlänge versetzt ausgegeben, die Elemente verdecken sich, und offensichtlich werden die am weitesten versetzten Elemente zuerst gedruckt (sieht man an der Art der gegenseitigen Verdeckung. Was unten über den Seitenrand verschoben würde, erscheint von oben wieder hereingeschoben ...
Am USB-Port sah der obere Teil der2. Testseite mit dem Gutenprint-Treiber genauso aus, die Ausgabe/der Drucker hing aber nachdem er die ersten paar Zentimeter der Seite gedruckt hatte.
Jedenfalls scheint das Problem doch im Treiberbereich oder im Bereich des Drucksystems zu liegen.
Gibt es Ideen?
Uwe
Tja, ich hatte bereits vorher über das "Control Center" die Drucker neu eingerichtet, ohne Erfolg. Hab's nochjmal mit yast probiert, ebenso negativ. Wenn es nicht so wäre, daß die Fehler an einem Win2K-Rechner nicht auftreten, würde ich auf einen Defekt am Drucker tippen - aber ...
Und außerdem sind die Fehler je nach Ausgabeweg (W2K->CIFS->raw, RHEL->CIFS->raw, 11.4->gutenprint,11.4->hpijs) verschieden, aber für sich jeweils reproduzierbar.
Es kommt also kein "Salat erster Ordnung", sondern es werden Teile der Ausgabe weggelassen, auf separate Blätter gedruckt, z.T. wird auch übereinandergedruckt, hinundwieder
hat man eine dot-Reihe zufällig gedruckt (d.h., eine Düse des Kopfes hat irgendwie eine Reihe zufälliger Punkte gedruckt, das kommt manchmal, höchstens ein- bis zweimal pro Seite vor).
Wie gesagt, der Drucker scheint an sich fast richtige Druckjobs zu bekommen, aber ab und zu ist ein blödsinniges Kommando drin, und wer baut diese ein, wenn nicht das 11.4er-System?
Ganz unsinnig ist das beim raw-Drucker.
Falls es aber nicht das 11.4er Druckersystem ist, bleibt eigentlich nur noch der USB-Port bzw -Treiber.
Ich habe versucht, den Drucker am Parallelport zu konfigurieren.
Erste Hürde: yast / printer config erkennt den Parallelport nicht.
Abhilfe siehe http://forums.opensuse.org/deu…-11-4-nicht-gefunden.html.
Aber auch danach scheint der Parallelport nicht richtig konfiguriert; offenbar kommt nix beim Drucker an.
noch nichtmal cat /etc/hosts > /dev/lp0 bewirkt eine Reaktion, geschweige denn das Drucken einer Testseite aus der yast-Druckerkonfig. Erstaunlicherweise gibt es auch keine Rückmeldung in cups errorlog, da ist kein Fehler vermeldet, und lpq sagt "ready and printing" ...
Ich werde mal das System booten und im BIOS-Menü nachschauen, dmidecode sagt:
Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J4A1
Internal Connector Type: None
External Reference Designator: LPT 1
External Connector Type: DB-25 male
Port Type: Parallel Port ECP/EPP
aber vielleicht ist der Port ja irgendwie deaktiviert.
Also bis später
Ich habe meinen Rechner vor einigen Tagen von 10.3 auf 11.4 gebracht. Danach habe ich nun ziemliche Probleme mit dem Drucken.
Ich habe einen HP DJ 895Cxi per USB am Rechner.Ich habe 3 CUPS-Drucker konfiguriert, die alle auf den entsprechenden USB-Anschluß ausgeben: einen raw-Drucker, einen Drucker mit dem Gutenprint-Treiber (HP DeskJet 895C - CUPS+Gutenprint v5.2.6) und einen weiteren ( HP Deskjet 895c, hpcups 3.11.1.1).
Ich nutze den raw-Drucker, um von anderen Rechnern aus zu drucken (via Samba/CIFS).
Vor dem Upgrade hatte ich keinerlei Probleme mit dem Drucker.
Nach dem Upgrade sehen Ausdrucke eines 2-seitigen ods-sheets fehlerhaft und dazu noch verschieden aus, je nachdem ob ich sie von einem W2K-Rechner (CIFS), einem weiteren Linux-Rechner oder vom SuSE-11.4-Rechner aus (also lokal, wobei beide Druckertreiber probiert wurden) ausdrucke.
Schließe ich den Drucker direkt an den W2K-Rechner an, ist der Ausdruck ok (gleicher Druckertreiber wie bei Druck über CIFS/Samba auf den raw-Drucker). Das bedeutet, daß der Druckauftrag auf dem SuSE-System offenbar modifiziert wird, opbwohl der raw-Perinter ja gerade dies nicht tun darf.
Die Dateien mime.types und mime.convs waren nach dem Upgrade in /etc/cups nicht vorhanden, ich habe sie vom letztem 10.3-Backup eingespielt. Dies brachte aber keine Lösung des Problems.
Nun würde mich interessieren, ob andere Leute ähnliche Probleme haben oder hatten, und ob jemand vielleicht ein paar Ideen hätte, woran die Misere liegen könnte.
Vielen Dank schon mal im Voraus.
strunz
