README & Installationshinweise für das Accelerated Linux Driver Set von NVIDIA Letztes Update: Datum: $ 14.06.2004 $ Aktuellster Treiber: 1.0-6106 Das Accelerated Linux Driver Set von NVIDIA bietet beschleunigte 2D-Funktionalität und Hochleistungs-OpenGL-Support für NVIDIA Grafikprozessoren unter x86-Linux. Diese Treiber ermöglichen eine optimierte Hardwarebeschleunigung von OpenGL-Anwendungen über einen Direct Rendering X-Server und unterstützen fast alle NVIDIA Grafikchips (eine vollständige Liste der unterstützten Chips finden Sie in ANHANG A). TwinView, TV-Out und Flachbildschirme werden ebenfalls unterstützt. Diese RERADME-Datei beschreibt, wie das Accelerated Linux Driver Set von NVIDIA installiert, konfiguriert und eingesetzt wird. Diese Datei wird auf der NVIDIA-Website (www.nvidia.com) veröffentlicht und nach /usr/share/doc/NVIDIA_GLX-1.0/ installiert. __________________________________________________________________________ INHALT: (Abschnitt 01) WAHL DES GEEIGNETEN NVIDIA-PAKETES FÜR IHR SYSTEM (Abschnitt 02) INSTALLIEREN DES NVIDIA-TREIBERS (Abschnitt 03) EDITIEREN IHRER X-KONFIGURATIONSDATEI (Abschnitt 04) FAQs - HÄUFIG GESTELLTE FRAGEN (Abschnitt 05) KONTAKT (Abschnitt 06) WEITERE RESSOURCEN (Anhang A) ANHANG A: UNTERSTÜTZTE NVIDIA-GRAFIKCHIPS (Anhang B) ANHANG B: MINDESTANFORDERUNGEN AN DIE SOFTWARE (Anhang C) ANHANG C: INSTALLIERTE KOMPONENTEN (Anhang D) ANHANG D: X-KONFIGURATIONSOPTIONEN (Anhang E) ANHANG E: EINSTELLUNGSMÖGLICHKEITEN FÜR DIE OPENGL- UMGEBUNGSVARIABLE (Anhang F) ANHANG F: AGP KONFIGURIEREN (Anhang G) ANHANG G: ALI-SPEZIFISCHE PROBLEME (Anhang H) ANHANG H: TNT-SPEZIFISCHE PROBLEME (Anhang I) ANHANG I: KONFIGURIEREN VON TWINVIEW (Anhang J) ANHANG J: TV-OUT KONFIGURIEREN (Anhang K) ANHANG K: KONFIGURIEREN EINES LAPTOPS (Anhang L) ANHANG L: PROGRAMMIEREN VON MODI (Anhang M) ANHANG M: FLIPPING UND UBB (Anhang N) ANHANG N: BEKANNTE PROBLEME (Anhang O) ANHANG O: PROC-SCHNITTSTELLE (Anhang P) ANHANG P: XVMC-UNTERSTÜTZUNG (Anhang Q) ANHANG Q: GLX-UNTERSTÜTZUNG (Anhang R) ANHANG R: MEHRERE X-BILDSCHIRME AUF EINER KARTE (Anhang S) ANHANG S: UNTERSTÜTZUNG FÜR ENERGIESPARFUNKTIONEN (Anhang T) ANHANG T: ANZEIGEGERÄTENAMEN Um diese Anweisungen kurz und bündig zu halten, werden die meisten Warnhinweise und häufig auftretenden Probleme nicht detailliert in den Installationsanweisungen, sondern im Abschnitt "FAQs - HÄUFIG GESTELLTE FRAGEN" aufgeführt. Es wird aus diesem Grunde empfohlen, diese README- Datei vollständig zu lesen, bevor Sie einen der beschriebenen Schritte ausführen. __________________________________________________________________________ (Abschnitt 01) WAHL DES GEEIGNETEN NVIDIA-PAKETS FÜR IHR SYSTEM __________________________________________________________________________ NVIDIA verfügt über ein einheitliches Treiberarchitektur-Modell, d.h. ein Treibersatz kann mit allen unterstützten NVIDIA-Grafikchips verwendet werden. Eine Liste der durch die aktuellen Treiber unterstützten NVIDIA- Grafikchips finden Sie in Anhang A. In der Treiberversion 1.0-4349 wurde ein neuer Paket- und Installations- Mechanismus eingeführt, der den Installationsprozess stark vereinfacht. Es muss nur noch eine einzige Datei heruntergeladen werden: NVIDIA-Linux-x86-1.0-6106-pkg1.run. Diese Datei enthält den gesamten Inhalt der alten Pakete NVIDIA_kernel und NVIDIA_GLX. Ab der Version 1.0-4496 wird nun ein zusätzliches Paketsuffix der Form "-pkg#" an die .run-Datei angehängt. Dies dient der Unterscheidung zwischen Paketen, die denselben Treiber, jedoch unterschiedliche vorkompilierte Kernelschnittstellen enthalten. (Laden Sie im Zweifelsfall einfach die .run-Datei mit der höchsten pkg-Nummer.) __________________________________________________________________________ (Abschnitt 02) INSTALLIEREN DES NVIDIA-TREIBERS __________________________________________________________________________ BEVOR SIE MIT DER INSTALLATION DER TREIBER BEGINNEN Verlassen Sie den X-Server, bevor Sie mit der Installation beginnen. Darüber hinaus sollten Sie den Standard-Runlevel so einstellen, dass Sie statt in den X-Server direkt auf eine VGA-Konsole booten (dies geschieht normalerweise durch eine Änderung in der Datei /etc/inittab; wenn Sie sich nicht sicher sind, wie Sie vorgehen müssen, lesen Sie bitte die Dokumentation, die Sie mit Ihrer Linux-Distribution erhalten haben). Das Wiederherstellen ist dann einfacher, wenn ein Problem während der Installation auftritt. Nach der Treiberinstallation müssen Sie erst Ihre X-Konfigurationsdatei bearbeiten, damit der neu installierte Treiber verwendet wird. Lesen Sie hierzu auch den unten stehenden Abschnitt "EDITIEREN IHRER X-KONFIGURATIONSDATEI". EINFÜHRUNG ZUM NEUEN NVIDIA-TREIBER-INSTALLATIONSPAKET Nachdem Sie NVIDIA-Linux-x86-1.0-6106-pkg1.run heruntergeladen haben, beenden Sie X, wechseln mit cd in das Verzeichnis, in das Sie die Datei heruntergeladen haben, und führen folgenden Befehl aus: sh NVIDIA-Linux-x86-1.0-6106-pkg1.run Die .run-Datei ist ein selbstextrahierendes Archiv. Bei der Ausführung der .run-Datei entpackt diese den Archivinhalt und startet das enthaltene Hilfsprogramm 'nvidia-installer', das Sie durch die Installation des NVIDIA-Treibers führt. Für die .run-Datei gibt es viele Befehlszeilenoptionen. Einige der gebräuchlicheren sind im Folgenden beschrieben: --info Gibt eingebettete Informationen zur .run-Datei aus und beendet die Ausführung dann. --check Prüft die Integrität des Archivs und beendet die Ausführung dann. --extract-only Extrahiert den Inhalt von ./NVIDIA-Linux-x86-1.0-6106.run, startet 'nvidia-installer' jedoch nicht. --help Gibt Informationen zur Verwendung der gebräuchlichen Befehlszeilenoptionen aus und beendet die Ausführung dann. --advanced-options Gibt Informationen zur Verwendung der gebräuchlichen sowie der erweiterten Befehlszeilenoptionen aus und beendet die Ausführung dann. Die Installation installiert auch das Hilfsprogramm 'nvidia-installer', mit dem Sie später die Treiber deinstallieren können, automatisch aktualisierte Treiber herunterladen können usw. KERNEL-SCHNITTSTELLEN Das NVIDIA-Kernelmodul verfügt über eine Kernelschnittstellenebene, die speziell für die von Ihnen eingesetzte Kernelkonfiguration und -version kompiliert werden muss. NVIDIA stellt den Quelltext dieser Kernelschnittstellenebene sowie eine vorkompilierte Version für viele Kernels aus beliebten Distributionen zur Verfügung. Bei der Ausführung des Installationsprogramms prüft dieses, ob eine vorkompilierte Kernelschnittstelle für den von Ihnen eingesetzten Kernel vorhanden ist. Ist dies nicht der Fall, so prüft es (eine Internet- Verbindung vorausgesetzt), ob auf der NVIDIA-FTP-Seite eine vorhanden ist, und lädt diese ggf. herunter. Wenn eine für Ihren Kernel passende, vorkompilierte Kernelschnittstelle gefunden wird, wird diese mit dem Binärteil des NVIDIA-Kernelmoduls gelinkt[1]. Als Ergebnis dieses Vorgangs erhalten Sie ein für Ihren Kernel passendes Kernelmodul. Kann keine passende vorkompilierte Kernelschnittstelle gefunden werden, so kompiliert das Installationsprogramm die Kernelschnittstelle für Sie. Zuerst überprüft es jedoch, ob Sie die korrekten Kernel-Header auf Ihrem System installiert haben. Wenn das Installationsprogramm die Kernelschnittstelle kompilieren soll, müssen Sie das Kernel-Sources-Paket für Ihren Kernel installieren. [1] HINWEIS: Für die Installation muss ein Linker installiert sein. Der Linker (normalerweise '/usr/bin/ld') ist Teil des Pakets binutils; bitte stellen Sie vor der Installation des NVIDIA-Treibers sicher, dass dieses Paket installiert ist. LEISTUNGSMERKMALE DES NVIDIA-INSTALLERS o Deinstallation: Die Treiberinstallation fertigt Sicherheitskopien der bestehenden Dateien an und protokolliert, welche neuen Dateien installiert werden. Sie können folgenden Befehl ausführen: nvidia-installer --uninstall um den aktuellen Treiber zu deinstallieren; die neu auf das System installierten Dateien werden so entfernt und die gesicherten Dateien wiederhergestellt. Bei der Installation neuer Treiber werden ältere Treiberinstallationen automatisch entfernt. o Automatische Aktualisierung: Wenn Sie folgenden Befehl ausführen: nvidia-installer --latest stellt das Hilfsprogramm eine Verbindung zur NVIDIA-FTP-Site her und gibt die aktuellste Treiberversion sowie die URL zum Speicherort der aktuellsten Treiberdateien zurück. Wenn Sie folgenden Befehl ausführen: nvidia-installer --update stellt das Hilfsprogramm eine Verbindung zur NVIDIA-FTP-Site her, lädt die aktuellsten Treiber herunter und installiert diese. o Mehrere Benutzeroberflächen: Wenn der Installer die korrekte ncurses- Bibliothek finden kann, verwendet er eine ncurses-basierte Benutzeroberfläche, ansonsten eine einfache Befehlszeilenoberfläche. Um die ncurses-Benutzeroberfläche zu deaktivieren, verwenden Sie die Option '--ui=none'. o Aktualisierte Kernelschnittstellen: Der Installer kann vorkompilierte Kernelschnittstellen von der NVIDIA-FTP-Site herunterladen (d. h. für Kernelversionen, die nach der jeweiligen NVIDIA-Treiberversion veröffentlicht wurden). HÄUFIGE FRAGEN ZUM NVIDIA-INSTALLER F: Wie entpacke ich den Inhalt der .run-Datei, ohne den Treiber tatsächlich zu installieren? A: Führen Sie folgenden Befehl aus: sh NVIDIA-Linux-x86-1.0-6106-pkg1.run --extract-only So wird das Verzeichnis 'NVIDIA-Linux-x86-1.0-6106-pkg1' angelegt, das den entpackten Inhalt der .run-Datei enthält. F: Wie kann ich auf den Quelltext für die Kernelschnittstellenebene zugreifen? A: Die Quelldateien für die Kernelschnittstellenebene befinden sich im Verzeichnis usr/src/nv der entpackten .run-Datei. Um zu diesen Quelldateien zu gelangen, führen Sie folgende Befehle aus: sh NVIDIA-Linux-x86-1.0-6106-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-6106-pkg1/usr/src/nv/ F: Nach einem Kernel-Upgrade lässt sich das NVIDIA-Kernelmodul nicht mehr laden. Wo liegt das Problem? A: Die Kernelschnittstellenschicht des NVIDIA-Kernelmoduls muss eigens für die von Ihnen eingesetzte Kernelkonfiguration und -version kompiliert werden. Wenn Sie ein Kernel-Upgrade durchgeführt haben, können Sie das Problem am einfachsten beheben, indem Sie den Treiber neu installieren. FÜR FORTGESCHRITTENE: Sie können das NVIDIA-Kernelmodul auch für einen noch nicht aktiven Kernel installieren, z. B. wenn Sie gerade eine neue Kernel-Build erstellt und den Kernel installiert haben, das System jedoch noch nicht neu gebootet haben. Verwenden Sie hierzu einen Befehl nach folgendem Muster: sh NVIDIA-Linux-x86-1.0-6106-pkg1.run --kernel-name='KERNEL_NAME' 'KERNEL_NAME' wäre hierbei der Kernelname, den 'uname -r' ausgäbe, wenn der gewünschte Kernel ausgeführt würde. F: Warum bietet NVIDIA keine rpm-Pakete mehr an? A: Einige Linux-Distributionen verwenden keine rpm-Pakete; NVIDIA wollte jedoch eine einheitliche Lösung für alle Linux-Distributionen. Wie in der NVIDIA-Softwarelizenz angegeben können die einzelnen Linux- Distributionen den NVIDIA-Linux-Treiber gerne nach Belieben in ein anderes Paketformat packen und weitergeben. F: nvidia-installer funktioniert auf meinem Rechner nicht. Wie kann ich den Treiber aus der .run-Datei installieren? A: Um den NVIDIA-Treiber in der .run-Datei ohne nvidia-installer zu installieren, können Sie die enthaltene Makefile verwenden: sh ./NVIDIA-Linux-x86-1.0-6106-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-6106-pkg1 make install Diese Installationsmethode wird nicht empfohlen und quasi nur als "ultima ratio" angeboten, falls nvidia-installer auf Ihrem System nicht korrekt funktioniert. F: Funktioniert nvidia-installer auch über einen Proxy-Server? A: Ja. Die FTP-Unterstützung in nvidia-installer basiert auf snarf und berücksichtigt daher den Inhalt der Umgebungsvariablen FTP_PROXY, SNARF_PROXY und PROXY. F: Was bedeutet das Suffix "pkg#" am Namen der .run-Datei? A: Das Suffix "pkg#" dient der besseren Unterscheidung von .run-Dateien, die zwar denselben Treiber, jedoch unterschiedliche vorkompilierte Kernelschnittstellen enthalten. Wenn eine Distribution nach der Veröffentlichung einer bestimmten NVIDIA-Treiberversion einen neuen Kernel freigibt, so kann einfach ein neues Paket aus dem aktuellen NVIDIA-Treiber und einer vorkompilierten Kernelschnittstelle für diesen neuen Kernel erstellt werden. Alle anderen vorkompilierten Kernelschnittstellen aus dem bisherigen Paket sind dabei weiterhin im neuen Paket enthalten. Wenn sich .run-Dateien mit derselben Versionsnummer in der pkg- Nummer unterscheiden, so liegt dieser Unterschied einzig und allein in den enthaltenen Kernelschnittstellen. .run-Dateien mit höheren pkg-Nummern enthalten also immer den kompletten Inhalt aller .run- Dateien mit niedrigeren pkg-Nummern. F: Ich habe NVIDIA-Linux-x86-1.0-6106-pkg1.run installiert und sehe nun, dass auf der NVIDIA-Downloadseite für Linux-Treiber gerade das Paket NVIDIA-Linux-x86-1.0-6106-pkg2.run veröffentlicht wurde. Soll ich jetzt also NVIDIA-Linux-x86-1.0-6106-pkg2.run herunterladen und installieren? A: Nein, dies ist nicht nötig. Alle .run-Dateien mit der Versionsnummer 1.0-6106 enthalten unabhängig von der pkg-Angabe denselben Treiber. Sie müssen also nichts neu installieren. F: Kann ich eine .run-Datei mit meinen eigenen vorkompilierten Kernelschnittstellen erweitern? A: Ja, dies ist über die Option "--add-this-kernel" der .run-Datei möglich. Mit dieser Option wird die .run-Datei entpackt, eine vorkompilierte Kernelschnittstelle für den gerade ausgeführten Kernel erstellt und eine neue .run-Datei mit dieser Kernelschnittstelle erzeugt. An den Namen dieser neuen Datei wird die Endung "-custom" angehängt. Diese Option kann beispielsweise hilfreich sein, wenn Sie für die Administration mehrerer Rechner mit demselben Linux-Kernel verantwortlich sind. F: Wo finde ich den Quelltext für das Hilfsprogramm nvidia-installer? A: Das Hilfsprogramm nvidia-installer wird unter der GPL veröffentlicht. Die aktuellsten Quellen sind unter folgender Adresse verfügbar: ftp://download.nvidia.com/XFree86/nvidia-installer/ EXTERNE KOMPONENTEN UND DANKSAGUNGEN ZUM NVIDIA-INSTALLER nvidia-installer wurde durch das Tool loki_update inspiriert: (http://www.lokigames.com/development/loki_update.php3.) Die FTP- und HTTP-Unterstützung in nvidia-installer basiert auf snarf 7.0: (http://www.xach.com/snarf/). Das selbstextrahierende Archiv (alias die ".run-Datei") wird mit makeself.sh erzeugt: (http://www.megastep.org/makeself/) __________________________________________________________________________ (Abschnitt 03) EDITIEREN IHRER X-KONFIGURATIONSDATEI __________________________________________________________________________ Im April 2004 veröffentlichte die X.org Foundation einen X-Server auf Basis von XFree86. Viele Linux-Distributionen werden den bisher ausgelieferten XFree86-X-Server durch den neuen X.org-Server ersetzen. Im Wesentlichen sollte diese Umstellung für Linux-Anwender mit NVIDIA Hardware keine weiteren Auswirkungen haben. Es sind jedoch zwei Ausnahmen zu beachten: 1. Die Konfigurationsdatei des X.org-Servers verwendet zwar dieselbe Syntax wie die XF86Config unter XFree86, sie ist jedoch unter /etc/X11/xorg.conf gespeichert. Wenn in dieser Readme-Datei die Rede von der "X-Konfigurationsdatei" ist, ist damit je nach Version entweder die XF86Config oder eben die neue xorg.conf gemeint. 2. Ähnlich ist die Situation bei der Protokolldatei (Logfile) des X.org-Servers. Ihr Ausgabeformat entspricht fast exakt dem der XFree86.0.log, sie befindet sich jedoch unter /var/log/Xorg.0.log. In dieser Readme-Datei wird auf beide Dateien einheitlich mit dem Begriff "X-Logfile" Bezug genommen. Bei der Einführung von XFree86 4.0 verwendete diese eine geringfügig andere XF86Config-Dateisyntax als die Version 3. Damit die Versionen 3.x und 4.x von XFree86 gleichzeitig auf dem System bestehen können, wurde entschieden, dass XFree86 4.x die Konfigurationsdatei "/etc/X11/XF86Config-4" verwendet, wenn diese existiert, und nur wenn diese nicht existiert, die Datei "/etc/X11/XF86Config" (dies ist eines starke Vereinfachung der Kriterien, bitte lesen Sie die XF86Config-Manpage, um eine vollständige Beschreibung des Suchpfades zu erhalten). Bitte achten Sie darauf, dass Sie wissen, welche Konfigurationsdatei Ihr X-Server verwendet. Wenn Sie sich nicht sicher sind, schauen Sie in Ihrer X-Logfile (/var/log/XFree86.0.log bzw. /var/log/Xorg.0.log) nach einer Zeile, die mit "(==) Using config file:" beginnt. Wenn Sie nicht über eine funktionierende X-Konfigurationsdatei verfügen, gibt es mehrere Möglichkeiten. Sowohl mit XFree86 als auch mit dem NVIDIA- Treiberpaket wird jeweils eine Beispiel-Konfigurationsdatei ausgeliefert (die NVIDIA-Version wird in /usr/share/doc/NVIDIA_GLX-1.0/ installiert). Sie können darüber hinaus ein Programm wie 'xf86config' verwenden; einige Distributionen haben auch ein eigenes Tool zum Erzeugen einer X-Konfigurationsdatei. Weitere Informationen über die Syntax der Konfigurationsdatei erhalten Sie auf der entsprechenden Manpage ("man XF86Config" bzw. "man xorg.conf"). Wenn Sie bereits über eine X-Konfigurationsdatei verfügen, die einen anderen Treiber verwendet (wie z. B. den 'nv'- oder 'vesa'-Treiber), müssen Sie lediglich den entsprechenden Abschnitt 'Device' finden und die Zeile: Driver "nv" (oder Driver "vesa") durch Driver "nvidia" ersetzen. Im Abschnitt 'Module' muss Folgendes erscheinen: Load "glx" Die folgenden Zeilen sollten ebenfalls entfernt werden: Load "dri" Load "GLcore" (vorausgesetzt, sie existieren). Es gibt viele Optionen, die der X-Konfigurationsdatei hinzugefügt werden können, um Feineinstellungen am NVIDIA X-Treiber vorzunehmen. Eine vollständige Liste dieser Optionen finden Sie in Anhang D. Sobald Sie Ihre X-Konfigurationsdatei konfiguriert haben, können Sie X neu starten und die beschleunigten OpenGL-Bibliotheken nutzen. Nachdem Sie X neu gestartet haben, sollten Sie jede OpenGL-Anwendung starten und automatisch mit den neuen NVIDIA-Bibliotheken nutzen können. Hinweise zur Problembeseitigung finden Sie weiter unten im Abschnitt "FAQs - HÄUFIG GESTELLTE FRAGEN". __________________________________________________________________________ (Abschnitt 04) FAQs - HÄUFIG GESTELLTE FRAGEN __________________________________________________________________________ F: Wo soll ich anfangen, wenn ich Probleme mit der Grafikanzeige habe? A: Eines der nützlichsten Tools bei der Problemdiagnose ist die X-Logfile in /var/log (Dateibezeichnung: "/var/log/XFree86.<#>.log" bzw. "/var/log/Xorg.<#>.log", wobei "<#>" die Servernummer darstellt - üblicherweise 0). Zeilen, die mit "(II)" beginnen, sind Informationen, "(WW)" sind Warnmeldungen und "(EE)" Fehlermeldungen. Stellen Sie sicher, dass die korrekte Config-Datei verwendet wird (d. h., die Config-Datei, die Sie bearbeiten); achten Sie auf die Zeile mit dem folgenden Anfang: "(==) Using config file:". Achten Sie auch darauf, dass statt des Treibers 'nv' oder 'vesa' der NVIDIA-Treiber verwendet wird; schauen Sie nach: "(II) LoadModule: "nvidia"". Zeilen des Treibers sollten mit folgenden Zeichen beginnen: "(II) NVIDIA(0)". F: Wie kann ich mehr Informationen in die X-Logfile ausgeben lassen? A: Standardmäßig gibt der NVIDIA X-Treiber relativ wenige Meldungen an stderr und die X-Logfile aus. Müssen Probleme behoben werden, kann es hilfreich sein, etwas ausführlichere Informationen ausgeben zu lassen, indem Sie die X-Befehlszeilenoptionen "-verbose" und "-logverbose" aktivieren. Diese Optionen legen fest, wie ausführlich die Angaben auf stderr bzw. in der Logfile sind (Verbosity Level). Ist der "Verbosity Level" auf 5 oder höher eingestellt, so gibt der NVIDIA- X-Treiber mehr Informationen aus (X setzt als Standard einen "Verbosity Level" von 1 für stderr bzw. 3 für die Logfile). Um die ausführliche Ausgabe an stderr und die Logdatei für den NVIDIA- X-Treiber zu aktivieren, geben Sie zum Starten von X folgenden Befehl ein: 'startx -- -verbose 5 -logverbose 5'. F: Mein X-Server startet nicht und in der X-Logfile steht folgende Meldung: "(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!" A: Wenn das NVIDIA-Kernelmodul nicht einwandfrei funktioniert, funktioniert auch sonst nichts. Wenn Sie in der X-Logfile eine Meldung ähnlich der folgenden erhalten: "(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!" (NVIDIA-Kernelmodul konnte nicht initialisert werden), so besteht höchstwahrscheinlich ein Problem mit dem NVIDIA-Kernelmodul. Wenn Sie aus einem RPM installiert haben, sollten Sie zunächst überprüfen, dass das RPM speziell für den von Ihnen verwendeten Kernel erstellt wurde. Sie sollten auch überprüfen, ob das Modul geladen wurde ('/sbin/lsmod'). Sollte es nicht geladen sein, versuchen Sie es explizit mit 'insmod' oder 'modprobe' zu laden (der X-Server muss vor der Installation eines neuen Kernelmoduls verlassen werden). Wenn Sie Fehlermeldungen über nicht aufgelöste Symbole erhalten, wurde das Kernelmodul wahrscheinlich unter Verwendung von Headerdateien für eine andere Kernelrevision erstellt, als Sie im Einsatz haben. Sie können explizit festlegen, welche Kernel- Headerdateien verwendet werden, indem Sie das NVIDIA-Kernelmodul mit der Option --kernel-include-dir erstellen (weitere Informationen erhalten Sie über 'sh NVIDIA-Linux-x86-1.0-6106-pkg1.run --advanced-options'). Bitte beachten Sie, dass sich die Konvention für den Speicherort der Kernel-Headerdateien etwa um die Zeit der Veröffentlichung der Kernelversion 2.4.0 geändert hat. Wird das Kernelmodul nicht einwandfrei geladen, versucht modprobe/insmod möglicherweise, ein älteres Kernelmodul zu laden (vorausgesetzt, dass Sie aktualisiert haben). Eventuell kann es helfen, in das Verzeichnis mit dem neuen Kernelmodul zu wechseln und 'insmod ./nvidia.o' auszuführen. Eventuell fehlen auch die /dev/nvidia*-Gerätedateien. Darüber hinaus besteht die Möglichkeit, dass das NVDIA-Kernelmodul bei Problemen Fehlermeldungen ausgibt -- zur Anzeige dieser Meldungen überprüfen Sie bitte /var/log/messages (bzw. den Speicherort, an den syslog Kernelmeldungen schickt). Diesen Meldungen ist "NVRM" vorangestellt. F: X wird gestartet, OpenGL-Anwendungen brechen jedoch sofort ab. A: Wenn X gestartet wird, OpenGL aber Probleme verursacht, haben Sie wahrscheinlich ein Problem mit anderen Bibliotheken oder es existieren tote Symlinks. Details hierzu finden Sie in Anhang C. In einigen Fällen müssen Sie einfach nur 'ldconfig' erneut ausführen. Bitte überprüfen Sie auch, ob die korrekten Erweiterungen vorhanden sind - 'xdpyinfo' sollte die Erweiterungen "GLX", "NV-GLX" und "NVIDIA-GLX" als vorhanden anzeigen. Sind diese drei Erweiterungen nicht vorhanden, besteht höchstwahrscheinlich ein Problem mit dem Laden des GLX-Moduls oder dieses ist nicht in der Lage, implizit GLcore zu laden. Überprüfen Sie Ihre X-Konfigurationsdatei und stellen Sie sicher, dass GLX geladen wird (siehe "Editieren Ihrer X-Konfigurationsdatei" weiter oben). Wenn mit Ihrer XF86Config-Datei alles stimmt, überprüfen Sie die X-Logfile auf Warn-/Fehlermeldungen, die GLX betreffen. Überprüfen Sie auch, ob die notwendigen Symlinks vorhanden sind (siehe Anhang C). F: Bei der Installation des NVIDIA-Kernelmoduls erscheint eine Fehlermeldung wie die folgende: #error Modules should never use kernel-headers system headers #error but headers from an appropriate kernel-source A: Sie müssen die Quellen für den Linux-Kernel installieren. In den meisten Situationen kann dieses Problem durch die Installation des Pakets kernel-sources für Ihre Distribution behoben werden. F: OpenGL-Anwendungen werden mit der folgenden Fehlermeldung geschlossen: Error: Could not open /dev/nvidiactl because the permissions are too restrictive (/dev/nvidiactl konnte nicht geöffnet werden, da die Zugriffsrechte zu eingeschränkt sind). Please see the TROUBLESHOOTING section of /usr/share/doc/NVIDIA_GLX-1.0/README for steps to correct (Bitte lesen Sie den Problembehandlungsbereich der /usr/share/doc/NVIDIA_GLX-1.0/README, um mögliche Schritte zur Korrektur zu erhalten) A: Wahrscheinlich ändert ein Sicherheitsmodul für das PAM-System die Zugriffsrechte für die NVIDIA-Gerätedateien. In den meisten Fällen funktioniert dieses Sicherheitssystem - es ist jedoch möglich, dass es durcheinandergerät. Zur Behebung dieses Problems empfehlen wir, diese Sicherheitsfunktion zu deaktivieren. Unterschiedliche Linux- Distributionen verwenden hierfür unterschiedliche Steuerungsdateien. Wenn Ihr System z. B. über die Datei /etc/security/console.perms verfügt, können Sie diese Datei ändern und die Zeile, die mit "" beginnt, entfernen (laut anderen Berichten kann es auch nötig sein, weitere Verweise auf in der console.perms zu entfernen, NVIDIA hat dies jedoch nicht getestet). Wenn Ihr System stattdessen eine Datei /etc/logindevperms hat, so können Sie aus dieser Datei die Zeile mit dem Verweis auf /dev/nvidiactl löschen. Diese Schritte verhindern, dass das PAM- Sicherheitssystem die Zugriffsrechte für die NVIDIA-Gerätedateien ändert. Danach müssen die Zugriffsrechte für die Gerätedateien wieder auf die ursprünglichen Rechte und Besitzer zurückgesetzt werden. Dies kann durch die folgenden Befehle erfolgen: chmod 0666 /dev/nvidia* chown root /dev/nvidia* F: OpenGL-Anwendungen stürzen ab und geben folgende Warnmeldung aus: WARNING: Your system is running with a buggy dynamic loader. This may cause crashes in certain applications. If you experience crashes you can try setting the environment variable __GL_SINGLE_THREADED to 1. For more information please consult the FREQUENTLY ASKED QUESTIONS section in the file /usr/share/doc/NVIDIA_GLX-1.0/README. (ACHTUNG: Ihr System läuft mit einem fehlerhaften dynamischen Lader. Dies kann zu Abstürzen in bestimmten Anwendungen führen. Sollte dies der Fall sein, können Sie die Umgebungsvariable GL_SINGLE_THREADED auf 1 setzen. Weitere Informationen erhalten Sie im Abschnitt FAQs - HÄUFIG GESTELLTE FRAGEN in der Datei: /usr/share/doc/NVIDIA_GLX-1.0/README). A: Der dynamische Lader in Ihrem System hat einen Bug, der zum Absturz von Anwendungen führt, die mit pthreads verbunden sind und die libGL über dlopen() mehrere Male öffnen. Dieser Bug ist in älteren Versionen des dynamischen Laders enthalten. Zu den Distributionen, die mit diesem Lader ausgeliefert wurden, gehören unter anderen RedHat Linux 6.2 und Mandrake Linux 7.1. Die Version 2.2 und neuer des Laders funktioniert erwiesenermaßen korrekt. Ist die abstürzende Anwendung single-threaded, so können Sie die Umgebungsvariable __GL_SINGLE_THREADED auf 1 setzen, um den Absturz zu verhindern. Geben Sie in der bash-Shell hierzu folgenden Befehl ein: export __GL_SINGLE_THREADED=1 In csh und davon abgeleiteten Shells verwenden Sie: setenv __GL_SINGLE_THREADED 1 Frühere Versionen des NVIDIA Accelerated Linux Driver Set haben versucht, dieses Problem zu umgehen; dieser Lösungsversuch verursachte jedoch Probleme mit anderen Anwendungen und wurde nach der Version 1.0-1541 entfernt. F: Quake3 stürzt ab, wenn der Grafikmodus geändert wird. A: Wahrscheinlich haben Sie das oben beschriebene Problem. Bitte überprüfen Sie die Textausgabe auf die "WARNING"-Meldung aus dem vorhergehenden Tipp. Wenn Sie vor dem Start von Quake3 __GL_SINGLE_THREADED auf 1 setzen, tritt das Problem nicht mehr auf. F: Mein System läuft zwar, aber anscheinend recht instabil. Was ist hier nicht in Ordnung? A: Eventuell hat das Problem etwas mit dem AGP-Bus zu tun. Nähere Informationen finden Sie in Anhang F. F: Beim Starten von X wird das Kernelmodul nicht dynamisch geladen; ich muss immer zunächst 'modprobe nvidia" ausführen. Was ist hier nicht in Ordnung? A: Stellen Sie sicher, dass die Zeile "alias char-major-195 nvidia" in Ihrer Modulkonfigurationsdatei erscheint. Dies ist in der Regel entweder "/etc/conf.modules", "/etc/modules.conf" oder "/etc/modutils/alias"; Details hierzu finden Sie in der Dokumentation Ihrer Distribution. F: Frage: Ich kann keine Build für das NVIDIA-Kernelmodul erstellen, oder aber ich kann die Build erstellen, das Modul dann jedoch nicht mit modprobe/insmod in meinen Kernel laden. Was ist hier nicht in Ordnung? A: In der Regel werden diese Probleme dadurch verursacht, dass die Build die falschen Kernel-Headerdateien verwendet (d. h. die Headerdateien für eine andere Kernelversion als die, die Sie verwenden). Laut der alten Konvention sollten die Kernel-Headerdateien in "/usr/include/linux/" gespeichert werden, dies wurde jedoch durch "/lib/modules/`uname -r`/build/include" ersetzt. Der nvidia-installer sollte in der Lage sein, den entsprechenden Speicherort zu bestimmen; wenn Sie jedoch ein Problem haben, können Sie die Build zwingen, bestimmte Headerdateien zu verwenden, indem Sie die Option --kernel-include-dir verwenden. Damit dies funktionieren kann, müssen natürlich die geeigneten Kernel-Headerdateien auf Ihrem System installiert sein. Lesen Sie hierzu die Dokumentation Ihrer Distribution. Bei einigen Distributionen werden die Kernel- Headerdateien nicht standardmäßig installiert, oder aber es werden Header installiert, die nicht hundertprozentig zum verwendeten Kernel passen. F: Warum laufen OpenGL-Anwendungen so langsam? A: Die Anwendung verwendet wahrscheinlich eine andere Bibliothek, die sich noch auf Ihrem System befindet, und nicht die von NVIDIA gelieferte OpenGL-Bibliothek. Details finden Sie in ANHANG C. F: Bei der Ausführung von Quake2 treten Probleme auf. A: Quake2 erfordert geringfügige Konfigurationsarbeiten, damit es funktioniert. Zunächst wird im Quake2 Verzeichnis ein Symlink mit dem Namen libGL.so erstellt, der auf libMesaGL.so verweist. Dieser Symlink sollte entfernt oder umbenannt werden. Damit Quake 2 im OpenGL-Modus ausgeführt werden kann, geben Sie 'quake2 +set vid_ref glx +set gl_driver libGL.so' ein. Quake2 scheint keinen Vollbildmodus zu unterstützen. Sie können jedoch den X-Server in der jeweiligen Quake2- Auflösung ausführen, um so den Vollbildmodus zu simulieren. F: Bei der Ausführung von Heretic II treten Probleme auf. A: Heretic II installiert ebenfalls als Standard den Symlink libGL.so in das Anwendungsverzeichnis. Sie können diesen Symlink entfernen oder umbenennen, da das System dann den Standardlink libGL.so findet (den unsere Treiber in /usr/lib installieren). In Heretic II können Sie dann im Grafikmenü den Rendermodus auf OpenGL einstellen. Auf der folgenden Website gibt es für Heretic II auch einen Patch von lokigames: http://www.lokigames.com/products/heretic2/updates.php3 F: Wo bekomme ich gl.h oder glx.h, damit ich OpenGL-Programme kompilieren kann? A: Auf den meisten Systemen sind diese Headerdateien vorinstalliert. NVIDIA hat jedoch eine eigene gl.h und glx.h mitgeliefert, die nach /usr/share/doc/NVIDIA_GLX-1.0/usr/include/GL installiert werden. Um diese Header zu verwenden, kopieren Sie sie nach /usr/include/GL. Alternativ können Sie auch dem Installer befehlen, die Dateien nach /usr/include/GL zu kopieren; übergeben Sie hierfür bei der Installation der Datei NVIDIA-Linux-x86-1.0-6106-pkg1.run die Befehlszeilenoption '--opengl-headers'. F: Kann ich mich per E-Mail benachrichtigen lassen, wenn eine neue Version des NVIDIA Accelerated Linux Driver Set verfügbar wird? A: Ja. Füllen Sie das Formular auf der folgenden Seite aus: http://www.nvidia.com/view.asp?FO=driver_update F: Mein System hängt sich beim vt-Umschalten auf, wenn rivafb aktiviert ist. A: Momentan ist es nicht möglich, rivafb und das NVIDIA-Kernelmodul gleichzeitig zu verwenden. Im Allgemeinen ist es auch keine gute Idee, zwei unahängige Softwaretreiber für die gleiche Hardware zu verwenden. F: Beim Kompilieren des NVIDIA-Kernelmoduls erscheint diese Fehlermeldung: You appear to be compiling the NVIDIA kernel module with a compiler different from the one that was used to compile the running kernel. This may be perfectly fine, but there are cases where this can lead to unexpected behaviour and system crashes. If you know what you are doing and want to override this check, you can do so by setting IGNORE_CC_MISMATCH. In any other case, set the CC environment variable to the name of the compiler that was used to compile the kernel. (Sie kompilieren anscheinend das NVIDIA-Kernelmodul mit einem Compiler, der nicht mit dem übereinstimmt, der für zum Kompilieren des aktiven Kernels verwendet wurde. Das kann völlig in Ordnung sein, kann jedoch auch zu unvorhergesehenen Ereignissen und Systemabstürzen führen. Wenn Sie wissen, was Sie tun, und diese Prüfung umgehen möchten, können Sie dies durch die Einstellung von IGNORE_CC_MISMATCH erreichen. Setzen Sie in allen anderen Fällen die CC-Umgebungsvariable auf den Namen des Compilers, der zur Kompilierung des Kernels verwendet wurde.) A: Sie sollten das NVIDIA-Kernelmodul mit der gleichen Compilerversion kompilieren, die auch zur Kompilierung Ihres Kernels eingesetzt wurde. Einige Linux-Kernel-Datenstrukturen sind von der gcc-Version abhängig, die bei dessen Kompilierung verwendet wurden, z.B. in include/linux/spinlock.h: ... * Most gcc versions have a nasty bug with empty initializers. */ #if (__GNUC__ > 2) typedef struct { } rwlock_t; #define RW_LOCK_UNLOCKED (rwlock_t) { } #else typedef struct { int gcc_is_buggy; } rwlock_t; #define RW_LOCK_UNLOCKED (rwlock_t) { 0 } #endif Wird der Kernel mit gcc 2.x kompiliert, die Kernelschnittstelle jedoch mit gcc 3.x (oder umgekehrt), so variiert die Größe von rwlock_t und Vorgänge wie ioremap schlagen fehl. Wenn Sie sehen möchten, mit welcher gcc-Version Ihr Kernel kompiliert wurde, so prüfen Sie die Ausgabe von: cat /proc/version Wenn Sie sehen möchten, welche gcc-Version momentan in Ihrem $PATH steht, so prüfen Sie die Ausgabe von: gcc -v F: X versagt mit der Fehlermeldung "Failed to allocate LUT context DMA" (Zuweisung von LUT-Kontext-DMA fehlgeschlagen) den Dienst. A: Dies ist eine der möglichen Konsequenzen, wenn Sie die NVIDIA-Kernelschnittstelle mit einer anderen gcc-Version kompilieren als der, die zur Kompilierung des Linux-Kernels eingesetzt wurde (siehe oben). F: Wie steht NVIDIA offiziell zu Linux-Kerneln im Entwicklerstadium? A: NVIDIA unterstützt Kernels, die sich im Entwicklerstadium befinden, offiziell nicht. Der gesamte Kernelmodul-Quelltext, der Berührungspunkte mit dem Kernel aufweist, steht sich jedoch im Verzeichnis usr/src/nv/ der .run-Datei. NVIDIA freut sich, wenn Mitglieder der Linux-Community Patches für diese Quelldateien schreiben, um Kompatibilität mit Entwicklungskernels zu erreichen. Mit einer Google-Suche finden Sie höchstwahrscheinlich verschiedene solche Patches aus der Entwicklergemeinde. F: Ich habe mit dem Update-Utility meiner Distribution einige Bibliotheken aktualisiert, und jetzt funktioniert mein NVIDIA-Grafiktreiber nicht mehr. Wo liegt das Problem? A: Eventuell treten Konflikte mit den vom Update-Utility Ihrer Distribution installierten Bibliotheken auf. Wie Sie solche Konflikte aufspüren können, erfahren Sie in ANHANG C: INSTALLIERTE KOMPONENTEN. F: Bei 'rpm --rebuild' erscheint der Fehler "unknown option" (unbekannte Option). A: In neueren Versionen von rpm wird die Option "--rebuild" nicht mehr unterstützt; wenn Sie eine solche Version verwenden, sollten Sie stattdessen den Befehl 'rpmbuild --rebuild' verwenden. Die ausführbare Datei 'rpmbuild' ist im Paket rpm-build enthalten. F: Ich verwende eine interne Grafiklösung auf Basis der nForce oder nForce2. In meiner X-Logfile erscheinen nun Fehlermeldungen wie diese hier: Not using mode "1600x1200" (exceeds valid memory bandwidth usage) (Modus "1600x1200" wird nicht verwendet - zulässige Speicherbandbreite wird überschritten) A: Integrierte Grafiklösungen haben strengere Beschränkungen für die Speicherbandbreite, weshalb Sie Einschränkungen bei den zur Verfügung stehenden Auflösungen und/oder Bildwiederholraten hinnehmen müssen. Um dieses Problem zu umgehen, können Sie die maximale Bildwiederholrate reduzieren, indem Sie den oberen Wert des Bereichs "VertRefresh" im Abschnitt "Monitor" Ihrer X-Konfigurationsdatei heruntersetzen. Sie können auch den Bandbreitentest mit der Option "NoBandWidthTest" in der X-Konfigurationsdatei deaktivieren; wir empfehlen dies jedoch nicht. F: Ich habe eine neue Build des NVIDIA-Kernelmoduls erstellt; wenn ich es nun aber einfügen will, erscheint eine Meldung, die sich über nicht aufgelöste Symbole beschwert. A: Nicht aufgelöste Symbole entstehen oft dadurch, dass die Kernelquellen nicht mit dem aktuell eingesetzten Kernel übereinstimmen. Um die Build des NVIDIA-Kernelmoduls korrekt durchführen zu können, müssen diese Dateien übereinstimmen. Bitte stellen Sie sicher, dass Ihre Kernelquellen erstens installiert sind und zweitens zum eingesetzten Kernel passen. F: Wie kann ich herausfinden, ob meine Kernelquellen installiert sind? A: Wenn Sie eine Distribution haben, die RPM verwendet (Red Hat, Mandrake, SuSE usw.), so können Sie dies mit RPM herausfinden. Geben Sie in der Shell folgenden Befehl ein: 'rpm -qa | grep kernel' und gehen Sie die Ausgabe durch. Sie sollten ein Paket für den Kernel (oft mit einem Namen der Form "kernel-2.4.18-3") und ein Kernelquellen- Paket mit derselben Version sehen (oft mit einem Namen der Form "kernel-source-2.4.18-3"). Wenn keine der Zeilen auf das Vorhandensein eines Quellenpakets hindeutet, müssen Sie das Quellenpaket wahrscheinlich installieren. Wenn die aufgeführten Versionen nicht übereinstimmen (z. B. kernel-2.4.18-10 und kernel-source-2.4.18-3), so müssen Sie das Kernelquellen-Paket auf dieselbe Version wie den eingesetzten Kernel bringen. Wenn Sie mehrere Kernels installiert haben, so müssen Sie das Kernelquellen-Paket für den *aktiven* Kernel installieren (bzw. sicherstellen, dass das installierte Quellenpaket zum aktiven Kernel passt). Gehen Sie hierzu die Ausgabe von 'uname -r' durch und gleichen Sie die Versionen entsprechend an. F: Warum kann ich das NVIDIA-Kernelmodul, das ich für den Kernel 2.4.18-3bigmem von Red Hat Linux 7.3 kompiliert habe, nicht laden? A: Die mit Red Hat Linux 7.3 ausgelieferten Kernel-Headerdateien für den Kernel 2.4.18-3bigmem sind falsch konfiguriert. Sie können das von NVIDIA vorkompilierte Kernelmodul für diesen Kernel laden; wenn Sie die NVIDIA-Kernelschnittstellendateien für diesen Kernel jedoch selbst kompilieren möchten, müssen Sie zunächst folgende Befehle ausführen: cd /lib/modules/`uname -r`/build/ make mrproper cp configs/kernel-2.4.18-i686-bigmem.config .config make oldconfig dep Hinweis: Red Hat Linux liefert Kernel-Headerdateien aus, die gleichzeitig für ALLE Kernel einer bestimmten Distributionsversion konfiguriert sind. Eine beim Booten erzeugte Headerdatei stellt einige Parameter ein, die dann die korrekte Konfiguration auswählen. Wenn Sie die Kernel-Header mit obigen Befehlen neu erstellen, entstehen Kernel- Header, die ausschließlich für den Kernel 2.4.18-3bigmem von Red Hat Linux 7.3 geeignet sind; für andere Konfigurationen sind diese Kernel- Header somit unbrauchbar. F: Der X-Start dauert sehr lang (teilweise mehrere Minuten). Was kann ich dagegen unternehmen? A: Wenn startx sehr lange dauert, so liegt dies nach unserer Erfahrung meistens daran, dass das Grafik-BIOS falsche Angaben zu den potenziell angeschlossenen Anzeigegeräten oder zum für die Erkennung verwendeten i2c-Port enthält. Sie können diese Probleme mit der Option "IgnoreDisplayDevices" in der X-Konfigurationsdatei umgehen (bitte lesen Sie hierzu die Beschreibung in ANHANG D: X-KONFIGURATIONSOPTIONEN). F: Warum belegt X so viel Speicher? A: Beim Messen des Speicherbedarfs einer Anwendung müssen Sie aufpassen, dass Sie zwischen dem realen Systemarbeitsspeicher und virtuellen Abbildern gemeinsam genutzter Ressourcen unterscheiden. Die meisten gemeinsam genutzten Bibliotheken werden beispielsweise nur ein einziges Mal in den physischen Speicher geladen, dann jedoch in mehrere Prozesse abgebildet. Wenn Sie den Gesamt-Speicherbedarf berechnen, sollten Sie diesen Speicher nur einmal mitzählen. Ebenso kann der Onboard-Speicher einer Grafikkarte oder der Registerspeicher anderer Geräte in mehrere Prozesse abgebildet werden. Solche Abbilder belegen jedoch keinen "echten" Systemspeicher. In den XFree86-Mailinglisten wird dieses Thema ausgiebig diskutiert, so z. B. hier: http://marc.theaimsgroup.com/?l=xfree-xpert&m=96835767116567&w=2 In der obigen Diskussion wird ein Utility namens 'pmap' erwähnt, das unter folgender Adresse verfügbar ist: http://web.hexapodia.org/~adi/pmap.c Dieses Tool ist sehr hilfreich, um die Art von Speicherzuweisungen zu bestimmen. Wenn 'top' beispielsweise angibt, dass X mehrere hundert MB Speicher belegt, so zeigt die letzte Zeile der Ausgabe von pmap: mapped: 287020 KB writable/private: 9932 KB shared: 264656 KB dass X in Wirklichkeit nur rund 10 MB Systemspeicher belegt (der Wert unter "writable/private"). Denken Sie auch daran, dass X Ressourcen für X-Clients belegen muss (Fenstermanager, Webbrowser usw.); wenn weitere Clients Ressourcen wie z. B. Pixmaps anfordern, steigt der Speicherbedarf von X entsprechend und sinkt dann wieder, wenn Sie X-Anwendungen schließen. F: In OpenGL-Anwendungen treten auf meinem System erhebliche Speicherlecks auf! A: Wenn Ihr Kernel die -rmap-VM verwendet, so können Speicherlecks infolge einer Speicherverwaltungs-Optimierung auftreten, die in -rmap14a eingeführt wurde. Die -rmap-VM wird von verschiedenen gebräuchlichen Distributionen eingesetzt, und das Speicherleck besteht bekanntermaßen in mehreren Distributionskernels. In -rmap15e ist das Leck behoben. Wenn Sie den Verdacht haben, dass Ihr System betroffen sein könnte, so versuchen Sie es mit einem Kernelupdate oder wenden sich für weitergehende Unterstützung an den Lieferanten Ihrer Distribution. F: Einige OpenGL-Anwendungen (wie z. B. Quake3 Arena) stürzen ab, wenn ich sie unter Red Hat Linux 9 starte. A: Einige Versionen des von Red Hat ausgelieferten glibc-Pakets, die TLS unterstützen, verarbeiten Aufrufe von dlopen() nicht korrekt, wenn auf gemeinsam genutzte Bibliotheken zugegriffen werden soll, die bestimmte TLS-Modelle nutzen. Dieses Problem zeigt sich zum Beispiel, wenn Quake Arena versucht, mit dlopen() die libGL-Bibliothek von NVIDIA zu öffnen. Bitte installieren Sie mindestens die Version glibc-2.3.2-11.9 (als Update von Red Hat verfügbar). F: Ich habe den Treiber installiert, aber das Kontrollkästchen zum Aktivieren der 3D-Beschleunigung lässt sich immer noch nicht anwählen. Habe ich irgendwas falsch gemacht? A: Die Konfigurationsapplets der meisten Distributionen wissen nichts mit dem NVIDIA-Treiber anzufangen und aktualisieren sich bei seiner Installation daher nicht ordnungsgemäß. Ihr Treiber sollte jedoch trotzdem problemlos funktionieren (solange er nur korrekt installiert wurde). F: Wo finde ich die tar-Archive? A: Wir stellen inzwischen keine separaten tar-Archive mehr zur Verfügung, da es sich bei der .run-Datei prinzipiell auch nur um ein tar-Archiv mit vorgelagertem Shell-Skript handelt. Sie können das tar-Archiv aus der .run-Datei extrahieren, indem Sie die .run-Datei mit der Option '--extract-only' ausführen. F: Wo finde ich ältere Treiberversionen? A: Unter ftp://download.nvidia.com/XFree86_40/. F: Bei der Anzeige auf einem Fernsehgerät stellt X die vga-Konsole nicht wieder her. Die X-Logfile enthält folgende Fehlermeldung: Unable to initialize the X int10 module; the console may not be restored correctly on your TV. A: Der NVIDIA X-Treiber nutzt das Int10-Modul von X, um den Konsolenstatus für den TV-Ausgang zu speichern und wiederherzustellen. Wenn die Nutzung des Int10-Moduls aus irgendeinem Grund nicht möglich ist, kann die Konsole demzufolge nicht ordnungsgemäß wiederhergestellt werden. Wenn Sie eine eigene Build des X-Servers erstellt haben, sollten Sie sich vergewissern, dass diese das Int10-Modul enthält. Wenn Sie eine X-Server-Build Ihrer Linux-Distribution verwenden, in der das Int10-Modul fehlt, so wenden Sie sich bitte an den Hersteller der Distribution. F: Beim Ändern von Einstellungen in Spielen wie Quake 3 Arena oder Wolfenstein: Enemy Territory stürzt das Spiel ab und ich bekomme folgende Fehlermeldung: ...loading libGL.so.1: QGL_Init: dlopen libGL.so.1 failed: /usr/lib/tls/libGL.so.1: shared object cannot be dlopen()ed: static TLS memory too small A: Diese Spiele öffnen und schließen den NVIDIA OpenGL-Treiber mittels der Funktionen dlopen() und dlclose(), wenn Sie die Einstellungen ändern. Einige Versionen von glibc (wie die mit Red Hat Linux 9 ausgelieferte Version) haben in diesem Zusammenhang einen Fehler, der dazu führt, dass in Anspruch genommene statische TLS-Einträge nicht wieder freigegeben werden. Durch diesen glibc-Fehler treten Fehler auf, wenn der OpenGL-Treiber mehrmals hintereinander neu geladen wird. In neueren Versionen von glibc ist dieser Fehler behoben -- siehe dazu auch die Red Hat-Fehlernummer 89692: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89692 F: X stürzt bei 'startx' ab. In der X-Logfile findet sich folgende Fehlermeldung: (EE) NVIDIA(0): Failed to obtain a shared memory identifier. A: Der NVIDIA OpenGL-Treiber und der NVIDIA X-Treiber benötigen zur gegenseitigen Kommunikation gemeinsam genutzten Speicher. Daher muss CONFIG_SYSVIPC in Ihrem Kernel aktiviert sein. F: Bei der Treiberinstallation beschwert sich das Installationsprogramm, dass X angeblich noch läuft, obwohl ich es beendet hatte. Wo liegt das Problem? A: Um festzustellen, ob ein X-Server läuft, prüft das Installationsprogramm, ob X-Lock-Dateien existieren (/tmp/.X[n]-lock mit [n] als der Nummer des X-Anzeigegeräts von 0 bis 7). Wenn Sie X zwar beendet haben, jedoch aus irgendeinem Grund noch eine solche Lock- Datei existiert, so müssen Sie diese von Hand löschen (jedoch AUF KEINEN FALL, solange X noch läuft). F: Nach der Installation des NVIDIA-Treibers stimmen die Schriftgrößen nicht mehr. A: Falsche Schriftgrößen werden in der Regel dadurch verursacht, dass ein Monitor falsche Abmessungen an das System meldet. Dies hat zur Folge, dass verschiedene X-Anwendungen Schriften falsch skalieren. Die aktuell von X angenommenen Monitorabmessungen können Sie mit folgendem Befehl überprüfen: xdpyinfo | grep dimensions Dieser Befehl liefert Ihnen die Monitorgröße in Pixeln und Millimetern. Wenn die Millimeterangaben deutlich von der Realität abweichen, können Sie sie durch einen DisplaySize-Eintrag im Monitor-Abschnitt Ihrer X-Konfigurationsdatei korrigieren. Nähere Informationen hierzu finden Sie in der Manpage zu XF86Config bzw. xorg.conf. Die vom Monitor gemeldeten Abmessungen können Sie überprüfen, indem Sie X mit ausführlichen Protokollmeldungen starten (startx -- -logverbose). Nach dem Start sollte Ihre X-Logfile dann einen Eintrag der folgenden Form enthalten: (II) NVIDIA(0): Max H-Image Size [cm]: horiz.: 36 vert.: 27 (Die tatsächlichen Werte werden natürlich abweichen.) Aus diesen Werten errechnet der NVIDIA-Treiber die DPI-Auflösung. F: Ich möchte Valgrind mit OpenGL-Anwendungen verwenden. Meine Distribution verwendet jedoch ELF TLS, und Valgrind unterstützt NVIDIAs ELF TLS OpenGL-Implementierung noch nicht. A: Dieses Problem können Sie umgehen, indem Sie die Umgebungsvariable LD_ASSUME_KERNEL auf einen Wert unter "2.3.99" setzen (Beispiel: 'export LD_ASSUME_KERNEL 2.3.98'). NVIDIAs OpenGL-Bibliotheken enthalten einen ABI-Vermerk für ELF, der die zur Verwendung der Bibliotheken mindestens erforderliche Kernelversion festlegt. Die ELF TLS OpenGL-Bibliotheken benötigen als Binärschnittstelle mindestens einen Linux-Kernel der Version 2.3.99, da in dieser Version erstmals die für ELF TLS erforderliche LDT- Unterstützung realisiert wurde. Die OpenGL-Bibliotheken ohne ELF TLS kommen mit der Kernelversion 2.2.5 aus. Zur Laufzeit verhindert der Loader, dass Bibliotheken geladen werden, die eine neuere ABI als die aktuelle Kernelversion erfordern. Über die Umgebungsvariable LD_ASSUME_KERNEL können Sie die Kernelversion überschreiben, die der Loader für diese Prüfung verwendet. Wenn Sie LD_ASSUME_KERNEL also auf eine Kernelversion unter 2.3.99 setzen, erzwingen Sie damit, dass der Loader statt den ELF TLS OpenGL- Bibliotheken die normalen OpenGL-Bibliotheken verwendet. Sollte es aus irgendeinem Grund nötig sein, den ABI-Vermerk aus den NVIDIA OpenGL-Bibliotheken zu entfernen, so können Sie dies erreichen, indem Sie der .run-Datei bei der Installation die Option "--no-abi-note" übergeben. __________________________________________________________________________ (Abschnitt 05) KONTAKT __________________________________________________________________________ Es gibt ein Webforum für Themen, die den NVIDIA-Linux-Treiber betreffen. Sie erreichen es, wenn Sie www.nvnews.net aufrufen und dann den Links "Forum" und "Linux Discussion Area" folgen. Wenn Sie Hilfe benötigen, sollten Sie es zunächst hier versuchen; hier können Anwender Fragen stellen, die Fragen anderer Anwender beantworten sowie alte archivierte Beiträge durchsuchen. Sollte alles andere fehlschlagen, können Sie sich für Support unter der folgenden E-Mail-Adresse mit NVIDIA in Verbindung setzen: linux-bugs@nvidia.com. Bitte beachten Sie jedoch, dass diese Adresse nur die letzte Anlaufstelle sein sollte, nachdem Sie die häufig gestellten Fragen in dieser README durchgelesen und im Webforum auf nvnew.net nach Hilfe gesucht haben. Wenn Sie eine E-Mail an linux-bugs@nvidia.com schicken, fügen Sie bitte immer die Datei nvidia-bug-report.log als Anlage bei. Diese Datei können Sie erzeugen, indem Sie das Skript nvidia-bug-report.sh ausführen (das Skript wird bei der Treiberinstallation automatisch mitinstalliert). __________________________________________________________________________ (Abschnitt 06) WEITERE RESSOURCEN __________________________________________________________________________ Linux OpenGL ABI http://oss.sgi.com/projects/ogl-sample/ABI/ NVIDIA Linux HowTo http://www.linuxdoc.org/HOWTO/mini/Nvidia-OpenGL-Configuration/index.html OpenGL www.opengl.org The XFree86 Project www.xfree86.org #nvidia (irc.freenode.net) __________________________________________________________________________ (Anhang A) ANHANG A: UNTERSTÜTZTE NVIDIA-GRAFIKCHIPS __________________________________________________________________________ NVIDIA-CHIPNAME PCI-GERÄTE-ID RIVA TNT 0x0020 RIVA TNT2/TNT2 Pro 0x0028 Vanta/Vanta LT 0x002C RIVA TNT2 Ultra 0x0029 RIVA TNT2 Model 64/Model 64 Pro 0x002D Aladdin TNT2 0x00A0 GeForce 256 0x0100 GeForce DDR 0x0101 Quadro 0x0103 GeForce2 MX/MX 400 0x0110 GeForce2 MX 100/200 0x0111 GeForce2 Go 0x0112 Quadro2 MXR/EX/Go 0x0113 GeForce2 Integrated GPU 0x01A0 GeForce2 GTS/GeForce2 Pro 0x0150 GeForce2 Ti 0x0151 GeForce2 Ultra 0x0152 Quadro2 Pro 0x0153 GeForce4 MX 460 0x0170 GeForce4 MX 440 0x0171 GeForce4 MX 420 0x0172 GeForce4 MX 440-SE 0x0173 GeForce4 440 Go 0x0174 GeForce4 420 Go 0x0175 GeForce4 420 Go 32M 0x0176 GeForce4 460 Go 0x0177 Quadro4 550 XGL 0x0178 GeForce4 440 Go 64M 0x0179 Quadro NVS 0x017A Quadro4 500 GoGL 0x017C GeForce4 410 Go 16M 0x017D GeForce4 MX 440 mit AGP8X 0x0181 GeForce4 MX 440SE mit AGP8X 0x0182 GeForce4 MX 420 mit AGP8X 0x0183 GeForce4 MX 4000 0x0185 Quadro4 580 XGL 0x0188 Quadro NVS mit AGP8X 0x018A Quadro4 380 XGL 0x018B GeForce4 MX Integrated GPU 0x01F0 GeForce3 0x0200 GeForce3 Ti 200 0x0201 GeForce3 Ti 500 0x0202 Quadro DCC 0x0203 GeForce4 Ti 4600 0x0250 GeForce4 Ti 4400 0x0251 GeForce4 Ti 4200 0x0253 Quadro4 900 XGL 0x0258 Quadro4 750 XGL 0x0259 Quadro4 700 XGL 0x025B GeForce4 Ti 4800 0x0280 GeForce4 Ti 4200 mit AGP8X 0x0281 GeForce4 Ti 4800 SE 0x0282 GeForce4 4200 Go 0x0286 Quadro4 980 XGL 0x0288 Quadro4 780 XGL 0x0289 Quadro4 700 GoGL 0x028C GeForce FX 5800 Ultra 0x0301 GeForce FX 5800 0x0302 Quadro FX 2000 0x0308 Quadro FX 1000 0x0309 GeForce FX 5600 Ultra 0x0311 GeForce FX 5600 0x0312 GeForce FX 5600XT 0x0314 GeForce FX 5200 0x0320 GeForce FX 5200 Ultra 0x0321 GeForce FX 5200 0x0322 GeForce FX 5200LE 0x0323 GeForce FX 5500 0x0326 GeForce FX 5100 0x0327 Quadro NVS 280 PCI 0x032A Quadro FX 500/600 PCI 0x032B GeForce FX Go53xx 0x032C GeForce FX 5900 Ultra 0x0330 GeForce FX 5900 0x0331 GeForce FX 5900XT 0x0332 GeForce FX 5950 Ultra 0x0333 GeForce FX 5900ZT 0x0334 Quadro FX 3000 0x0338 Quadro FX 700 0x033F GeForce FX 5700LE 0x0343 GeForce FX 5700VE 0x0344 GeForce FX 5700 Ultra 0x0341 GeForce FX 5700 0x0342 GeForce FX Go5700 0x0347 Quadro FX Go1000 0x034C Quadro FX 1100 0x034E GeForce FX Go5600 0x031A GeForce FX Go5650 0x031B Quadro FX Go700 0x031C GeForce FX Go5200 0x0324 GeForce FX Go5250 0x0325 GeForce FX Go5200 32M/64M 0x0328 GeForce FX Go5300 0x032C GeForce FX Go5100 0x032D GeForce FX Go5700 0x0348 GeForce 6800 Ultra 0x0040 GeForce 6800 0x0041 Quadro FX 4000 0x004E GeForce 6800/GeForce 6800 Ultra 0x00F0 GeForce 6800 Ultra 0x00F9 GeForce PCX 5750 0x00FA GeForce PCX 5900 0x00FB GeForce PCX 5300 0x00FC GeForce PCX 4300 0x00FF __________________________________________________________________________ (Anhang B) ANHANG B: MINDESTANFORDERUNGEN AN DIE SOFTWARE __________________________________________________________________________ o Linux-Kernel 2.2.12 # cat /proc/version o XFree86 4.0.1 # XFree86 -version, bzw. Xorg 6.7 # Xorg -version o Kernel modutils 2.1.121 # insmod -V Wenn Sie eine Build des NVIDIA-Kernelmoduls erstellen müssen: o binutils 2.9.5 # size --version o GNU make 3.77 # make --version o gcc 2.91.66 # gcc --version o glibc 2.0 # /lib/libc.so.6 Wenn Sie die Build aus Quell-RPMs erstellen: o spec-helper rpm # rpm -qi spec-helper Es werden alle offiziellen stabilen Kernelversionen ab 2.2.12 und höher unterstützt, Vorabversionen wie "2.4.3-pre2" werden nicht unterstützt, auch keine Kernel aus Entwicklungsserien wie 2.3.x oder 2.5.x. Der Linux- Kernel kann von www.kernel.org oder einem der Mirrors bezogen werden. binutils und gcc sind über www.gnu.org oder einen der Mirrors erhältlich. Wenn Sie XFree86 verwenden, aber keine Datei /var/log/XFree86.0.log haben, so haben Sie wahrscheinlich eine 3.x-Version von XFree86 und müssen upgraden. Wenn Sie XFree86 4 zum ersten Mal konfigurieren, ist es oftmals einfacher, zunächst einen der Open-Source-Treiber zu verwenden, der mit XFree86 ausgeliefert wird ('nv', 'vga' oder 'vesa'). Wenn XFree86 einmal ordnungsgemäß mit dem Open-Source-Treiber funktioniert, ist es einfacher, auf den NVIDIA-Treiber umzustellen. Bitte beachten Sie, dass neuere NVIDIA-GPUs eventuell nicht mit älteren Versionen des "nv"-Treibers funktionieren, der mit XFree86 ausgeliefert wird. Beispielsweise war der "nv"-Treiber von XFree86 Version 4.0.1 nicht in der Lage, GPUs der Familien GeForce2 und Quadro2 MXR zu erkennen. Dies wurde jedoch in XFree86 Version 4.0.2 behoben (XFree86 ist unter www.xfree86.org erhältlich). Diese Softwarepakete können gegebenenfalls auch von Ihrem Linux-Distributor bezogen werden. __________________________________________________________________________ (Anhang C) ANHANG C: INSTALLIERTE KOMPONENTEN __________________________________________________________________________ Das Accelerated Linux Driver Set von NVIDIA besteht aus den folgenden Komponenten (die Datei in Klammern bezeichnet den vollständigen Namen der Komponente nach der Installation; "x.y.z" beschreibt die aktuelle Version - in diesen Fällen werden entsprechende Symlinks während der Installation erstellt). o Ein X-Treiber (/usr/X11R6/lib/modules/drivers/nvidia_drv.o); dieser Treiber wird vom X-Server zur Verwendung Ihrer NVIDIA-Hardware benötigt. Der Treiber nvidia_drv.o ist mit XFree86 4.0.1 und höher sowie mit dem x.org-Server binärkompatibel. o Ein GLX-Erweiterungsmodul für X (/usr/X11R6/lib/modules/extensions/libglx.so.x.y.z); dieses Modul wird vom X-Server verwendet, um serverseitige GLX-Unterstützung zu bieten. o Eine OpenGL-Bibliothek (/usr/lib/libGL.so.x.y.z); diese Bibliothek enthält die API-Einsprungstellen für alle OpenGL- und GLX- Funktionsaufrufe. OpenGL-Anwendungen erstellen zur Laufzeit entsprechende Verweise auf diese Bibliothek. o Eine OpenGL-Kernbibliothek (/usr/lib/libGLcore.so.x.y.z); diese Bibliothek wird implizit von libGL und libglx verwendet. Sie enthält die Kernfunktionen für beschleunigte 3D-Grafik. Sie sollten diese Datei nicht explizit in Ihrer X-Konfigurationsdatei laden -- dies wird von libglx erledigt. o Zwei Bibliotheken für XvMC (X-Video Motion Compensation): eine statische sowie eine gemeinsam genutzte Bibliothek (/usr/X11R6/lib/libXvMCNVIDIA.a, /usr/X11R6/lib/libXvMCNVIDIA.so.x.y.z); nähere Details finden Sie in ANHANG P: XVMC-UNTERSTÜTZUNG. o Ein Kernelmodul (/lib/modules/`uname -r`/video/nvidia.o oder /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o). Dieses Kernelmodul bietet allen oben genannten Komponenten Low-Level-Zugriff auf Ihre NVIDIA-Hardware. Es wird beim Start des X-Servers in den Kernel geladen und vom X-Treiber sowie OpenGL verwendet. nvidia.o besteht aus zwei Teilen: dem Binärkern und einer Kernelschnittstelle, die eigens für Ihre Kernelversion kompiliert werden muss. Bitte beachten Sie, dass der Linux-Kernel anders als der X-Server nicht über eine einheitliche binäre Schnittstelle verfügt; es ist daher wichtig, dass diese Kernelschnittstelle mit der Kernelversion übereinstimmt, die Sie verwenden. Dies können Sie erreichen, indem Sie entweder selbst kompilieren oder aber die vorkompilierten Binaries verwenden, die für die Kernels einiger gebräuchlicher Linux-Distributionen mitgeliefert werden. o OpenGL- und GLX-Headerdateien (/usr/share/doc/NVIDIA_GLX-1.0/include/GL/gl.h und /usr/share/doc/NVIDIA_GLX-1.0/include/GL/glx.h). Diese Dateien können auch nach /usr/include/GL/ installiert werden, indem Sie der .run- Datei bei der Installation die Option "--opengl-headers" übergeben. o Die nvidia-tls Bibliotheken (/usr/lib/libnvidia-tls.so.x.y.z und /usr/lib/tls/libnvidia-tls.so.x.y.z). Diese Dateien stellen die TLS-Unterstützung (Thread Local Storage) für die NVIDIA OpenGL- Bibliotheken (libGL, libGLcore und libglx) bereit. Jede nvidia-tls Bibliothek unterstützt dabei ein bestimmtes TLS-Modell (wie z. B. ELF TLS). Die passende Bibliothek für Ihr System wird zur Laufzeit automatisch geladen. o Die Anwendung nvidia-installer (/usr/bin/nvidia-installer) ist NVIDIAs Tool zum Installieren und Aktualisieren von NVIDIA-Treibern. Eine detailliertere Beschreibung finden Sie in (Abschnitt 02) INSTALLIEREN DES NVIDIA-TREIBERS. Probleme können auftreten, wenn Anwendungen die falsche Version einer Bibliothek verwenden. Dies kann der Fall sein, wenn entweder alte libGL- Bibliotheken oder tote Symlinks vorhanden sind. Wenn Sie vermuten, dass mit Ihrer Installation etwas nicht stimmt, so überprüfen Sie, ob die folgenden Dateien vorhanden sind (dies sind alle Dateien des Accelerated Linux Driver Sets von NVIDIA plus deren Symlinks): /usr/X11R6/lib/modules/drivers/nvidia_drv.o /usr/X11R6/lib/modules/extensions/libglx.so.x.y.z /usr/X11R6/lib/modules/extensions/libglx.so -> libglx.so.x.y.z /usr/lib/libGL.so.x.y.z /usr/lib/libGL.so.x -> libGL.so.x.y.z /usr/lib/libGL.so -> libGL.so.x /usr/lib/libGLcore.so.x.y.z /usr/lib/libGLcore.so.x -> libGLcore.so.x.y.z /lib/modules/`uname -r`/video/nvidia.o, or /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o Bei der Installation werden ebenfalls die /dev-Dateien erstellt: crw-rw-rw- 1 root root 195, 0 Feb 15 17:21 nvidia0 crw-rw-rw- 1 root root 195, 1 Feb 15 17:21 nvidia1 crw-rw-rw- 1 root root 195, 2 Feb 15 17:21 nvidia2 crw-rw-rw- 1 root root 195, 3 Feb 15 17:21 nvidia3 crw-rw-rw- 1 root root 195, 255 Feb 15 17:21 nvidiactl Wenn es andere Bibliotheken gibt, deren "soname" mit denen der NVIDIA- Bibliotheken in Konflikt steht, ist es möglich, dass ldconfig die falschen Symlinks erstellt. Wir empfehlen, dass Sie diese in Konflikt stehenden Bibliotheken manuell entfernen oder umbenennen (Sie sollten diese immer so umbenennen, dass ldconfig sie übergeht -- z. B. mit einem dem Bibliotheksnamen vorangestellten "XXX"). Führen Sie dann 'ldconfig' erneut aus und überprüfen sie, ob die korrekten Symlinks erstellt wurden. Zwei Beispiele für Bibliotheken, die häufig Konflikte erzeugen, sind "/usr/X11R6/lib/libGL.so*" und "/usr/X11R6/lib/libGLcore.so*". Wenn das Problem nicht bei den Bibliotheken liegt, stellen Sie sicher, dass die Anwendung die korrekten Bibliotheken verwendet. Um zum Beispiel zu überprüfen, ob die Anwendung /usr/X11R6/bin/gears die NVIDIA- Bibliotheken verwendet, ist das folgende Procedere erforderlich: $ ldd /usr/X11R6/bin/gears libglut.so.3 => /usr/lib/libglut.so.3 (0x40014000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x40046000) libGL.so.1 => /usr/lib/libGL.so.1 (0x40062000) libc.so.6 => /lib/libc.so.6 (0x4009f000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4018d000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40196000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x401ac000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401c0000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401cd000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401d6000) libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x402ab000) libm.so.6 => /lib/libm.so.6 (0x4048d000) libdl.so.2 => /lib/libdl.so.2 (0x404a9000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x404ac000) Achten Sie auf die für libGL und libGLcore verwendeten Dateien -- wenn dies nicht die NVIDIA-Bibliotheken sind, müssen Sie entweder die störenden Bibliotheken entfernen oder Ihren ld-Suchpfad anpassen. Wenn Sie sich in Bezug auf die vorangegangenen Ausführungen nicht ganz im Klaren sind, sollten Sie die Man-Pages zu "ldconfig" und "ldd" lesen, die Ihnen die nötige Starthilfe geben werden. __________________________________________________________________________ (Anhang D) ANHANG D: X-KONFIGURATIONSOPTIONEN __________________________________________________________________________ Der NVIDIA-X-Treiber unterstützt folgende Treiberoptionen, die in der X-Konfigurationsdatei in den Abschnitten "Screen" bzw. "Device" angeben werden können: Option "NvAGP" "integer" AGP-Unterstützung konfigurieren. Das Integer-Argument kann eines der folgenden sein: 0 : AGP deaktivieren 1 : wenn möglich, NVIDIAs interne AGP-Unterstützung nutzen 2 : wenn möglich, AGPGART nutzen 3 : jede mögliche AGP-Unterstützung nutzen (zunächst AGPGART, dann NVIDIAs AGP) Bitte beachten Sie, dass NVIDIAs interne AGP-Unterstützung nicht funktioniert, wenn AGPGART entweder statisch in Ihren Kernel kompiliert wurde oder als ein Modul erstellt, dann aber in Ihren Kernel geladen wurde (einige Distributionen laden AGPGART beim Booten in den Kernel). Standard: 3 (bis nach 1.0-1251 war der Standard 1). Option "NoLogo" "boolean" Anzeige des NVIDIA-Logobildschirms beim Starten von X deaktivieren. Standard: das Logo wird dargestellt. Option "RenderAccel" "boolean" Aktivieren oder Deaktivieren der Hardwarebeschleunigung der RENDER-Erweiterung. DIESE OPTION BEFINDET SICH IM EXPERIMENTALSTADIUM -- AKTIVIERUNG AUF EIGENE GEFAHR. Da für die RENDER-Erweiterung keine Testpläne zur Bestimmung der formalen Korrektheit existieren, kann NVIDIA nicht prüfen, ob die RENDER-Beschleunigung ordnungsgemäß funktioniert. Standard: Keine Hardwarebeschleunigung der RENDER-Erweiterung. Option "NoRenderExtension" "boolean" Deaktivieren der RENDER-Erweiterung. Abgesehen vom Neukompilieren des X-Servers scheint es in XFree86 keine andere Möglichkeit geben, diese Erweiterung zu deaktivieren. Glücklicherweise können wir diese Option aus dem Treiber heraus steuern und legen sie daher offen. Diese Option ist beispielsweise bei der Farbtiefe 8 nützlich, wenn RENDER ansonsten einen Großteil der Standard-Palette beanspruchen würde. Standard: RENDER wird wenn möglich aktiviert. Option "UBB" "boolean" Unified Back Buffer auf Quadro-Chipsätzen (außer Quadro4 NVS) aktivieren oder deaktivieren; eine Beschreibung des UBB finden Sie in Anhang M. Auf andere Chipsätze als den Quadro hat diese Option keine Auswirkungen. Standard: UBB ist für Quadro-Chipsätze aktiviert. Option "NoFlip" "boolean" Deaktiviert OpenGL-Flipping. Eine ausführlichere Beschreibung finden Sie in Anhang M. Standard: OpenGL verwendet wenn möglich Flipping. Option "DigitalVibrance" "integer" Aktiviert Digital Vibrance Control. Der gültige Wertebereich ist 0 bis 255. Auf älteren Produkten als der GeForce2-GPU ist diese Funktion nicht verfügbar. Standard: 0. Option "Dac8Bit" "boolean" Die meisten Quadro-Chips verwenden standardmäßig eine 10-Bit-Farbtabelle (Look-Up Table - LUT); wenn Sie diese Option auf TRUE setzen, verwenden diese Grafikchips zwingend eine 8-Bit-LUT. Standard: falls möglich wird eine 10-Bit-LUT verwendet. Option "Overlay" "boolean" Aktiviert RGB-Workstation-Overlaygrafik. Diese Funktion wird nur auf Quadro4 und QuadroFX (außer dem Quadro4 NVS) unterstützt. Mit dieser Option stellt der Server die Basisfenstereigenschaft SERVER_OVERLAY_VISUALS zur Verfügung und GLX gibt Z-gepufferte 16-Bit-Overlaygrafik mit Einfach- oder Doppelpufferung an. Der Transparenz-Key ist Pixel 0x0000 (Hex). Gammakorrektur wird in der Overlay-Ebene nicht unterstützt. Diese Funktion benötigt XFree86 Version 4.1.0 oder höher bzw. den x.org-Server. NV17/18-basierte Quadro-Modelle (d. h. 500/550 XGL) haben weitere Beschränkungen; insbesondere werden im TwinView- Modus sowie bei virtuellen Desktops, die höher oder breiter als 2046x2047 Pixel sind, keine Overlays unterstützt (im Modus 2048x1536 funktioniert diese Option also beispielsweise nicht). Chips der Reihen Quadro 7xx/9xx und Quadro FX bieten in diesen Modi zwar Overlaygrafik (TwinView oder virtuelle Desktops mit höheren Auflösungen als 2046x2047), die Overlay-Emulation ist jedoch mit deutlichen Leistungseinbußen verbunden. Standard: aus. Option "CIOverlay" "boolean" Aktiviert Farbindex-Workstation-Overlaygrafik. Es gelten dieselben Einschränkungen wie bei der oben stehenden Option "Overlay". Der Server bietet Grafik mit oder ohne Transparenz-Key. Es handelt sich hierbei um PseudoColor- Grafik mit Farbtiefe 8. Wenn Sie Farbindex-Overlays auf einem X-Server aktivieren, der eine frühere XFree86-Version als 4.3 verwendet, so wird die RENDER-Erweiterung zwangsweise deaktiviert (Grund hierfür sind Fehler in der Implementierung der RENDER-Erweiterung in älteren X- Servern). Standard: aus. Option "TransparentIndex" "integer" Wenn Farbindex-Overlays aktiviert sind, kann der Anwender mit dieser Option wählen, welcher Pixel als Transparenzpixel für Darstellungen mit transparenten Pixeln verwendet wird. Der gültige Wertebereich ist 0 bis 255. (Hinweis: Für manche Anwendungen wie z. B. Maya von Alias/Wavefront muss dieser Wert 0 sein, um eine korrekte Funktionsweise zu gewährleisten.) Standard: 0. Option "OverlayDefaultVisual" "boolean" Bei der Verwendung von Overlays setzt diese Option die Standardgrafik als Overlay-Grafik, sodass das Basisfenster in die Overlay-Ebene gelangt. Diese Option empfiehlt sich nicht für RGB-Overlays. Standard: aus. Option "SWCursor" "boolean" Software-Rendering des X-Cursors aktivieren oder deaktivieren. Standard: aus. Option "HWCursor" "boolean" Hardware Rendering des X-Cursors aktivieren oder deaktivieren. Standard: ein. Option "CursorShadow" "boolean" Schattens für den hardwarebeschleunigten Cursor aktivieren oder deaktivieren. Hiermit ist ein schwarzes, durchsichtiges Abbild der Cursorform gemeint, das in einem gegebenen Abstand zum echten Cursor steht. Diese Option ist für Hardware beginnend beim GeForce 2 MX oder höher verfügbar (d. h. alle Chipsätze außer TNT/TNT2, GeForce 256, GeForce DDR und Quadro). Standard: kein Cursorschatten. Option "CursorShadowAlpha" "integer" Der für den Cursorschatten zu verwendende Alphawert. Er ist nur bei aktiviertem CursorShadow relevant. Der Wert muss zwischen [0, 255] liegen - 0 ist vollständig durchsichtig; 255 vollständig opak. Standard: 64. Option "CursorShadowXOffset" "integer" Der Versatz in Pixel, um den das Schattenbild nach rechts von der echten Cursorabbildung versetzt wird. Diese Option ist nur bei aktiviertem CursorShadow relevant. Der Wert muss im Bereich zwischen [0, 32] liegen. Standard: 4. Option "CursorShadowYOffset" "integer" Der Versatz in Pixel, um den das Schattenbild nach unten von der echten Cursorabbildung versetzt wird. Diese Option ist nur bei aktiviertem CursorShadow anwendbar. Der Wert muss im Bereich zwischen [0, 32] liegen. Standard: 2. Option "ConnectedMonitor" "string" Ermöglicht es Ihnen, die vom NVIDIA-Kernelmodul automatisch erkannte Einstellung für das an die Grafikkarte angeschlossene Gerät zu übergehen. Dies kann zum Beispiel hilfreich sein, wenn Sie einen KVM-Umschalter (Tastatur-/Grafik-/Mausumschalter) einsetzen und dieser gerade nicht auf den Rechner geschaltet ist, auf dem X gestartet wird. In einer derartigen Situation kann das NVIDIA-Kernelmodul nicht feststellen, welche Bildschirmgeräte angeschlossen sind; der NVIDIA X-Treiber nimmt dann an, dass ein einzelner Röhrenmonitor angeschlossen ist. Gültige Werte für diese Option sind "CRT" (Röhrenmonitor), "DFP" (digitaler Flachbildschirm) oder "TV" (Fernseher). Wenn TwinView verwendet wird, kann diese Option auch eine kommagetrennte Aufzählung enthalten, z. B. "CRT, CRT" oder "CRT, DFP". HINWEIS: Alle Geräte, die über einen 15-Pin-VGA-Stecker angeschlossen sind, gelten für den Treiber als "CRT". "DFP" sollten Sie nur für Flachbildschirme verwenden, die über einen DVI-Anschluss angeschlossen sind. Standard: String ist NULL. Option "UseEdidFreqs" "boolean" Diese Option lässt den X-Server die HorizSync- und VertRefresh-Werte einsetzen, die gegebenenfalls in den EDID eines Anzeigegeräts angegeben sind. Die in den EDID angegebenen Informationen haben Vorrang vor den im Bereich "Monitor" gesetzten Werte für HorizSync und VertRefresh. Werden vom Anzeigegerät keine EDID angeboten oder enthalten diese keine Angaben zu HorizSync und VertRefresh, so verwendet der X-Server als Standard die Bereiche für HorizSync und VertRefresh, die im Abschnitt "Monitor" gesetzt sind. Option "IgnoreEDID" "boolean" Abfrage der EDID (Extended Display Identification Data - Erweiterte Bildschirm-Identifikationsdaten) von Ihrem Monitor deaktivieren. Angeforderte Modi werden mit den Werten verglichen, die (gegebenenfalls) von Ihren Monitor- EDIDs bei der Modusvalidierung bezogen wurden. Es ist bekannt, dass einige Bildschirm-Leistungsangaben etwas übertrieben sind. Das Ignorieren der Werte, die Ihr Bildschirm angibt, kann bei der Validierung eines bestimmten Modus hilfreich sein. Auf der anderen Seite ist es aber auch gefährlich, wenn Sie nicht genau wissen, was Sie dort tun. Standard: EDIDs verwenden. Option "NoDDC" "boolean" Synonym für "IgnoreEDID" Option "FlatPanelProperties" "string" Fordert bestimmte Eigenschaften eines angeschlossenen Flachbildschirms an, die als kommagetrennte Liste von Paaren im Format Eigenschaft=Wert übergeben werden. Momentan sind ausschließlich die beiden Eigenschaften "Scaling" und "Dithering" verfügbar. Die möglichen Werte für "Scaling" sind "default" (der Treiber verwendet den aktuellen Skalierstatus), "native" (der Treiber verwendet falls vorhanden die Skalierfunktionen des Bildschirms), "scaled" (der Treiber verwendet falls möglich die NVIDIA- Skalierfunktionen), "centered" (der Treiber zentriert falls möglich das Bild) und "aspect-scaled" (der Treiber skaliert mit den NVIDIA-Skalierfunktionen, bewahrt jedoch das korrekte Seitenverhältnis). Die möglichen Werte für "Dithering" (Rasterfarbmischung) sind "default" (der Treiber entscheidet, wann gedithert wird), "enabled" (der Treiber dithert wann immer möglich) und "disabled" (der Treiber dithert nie). Wird eine Eigenschaft nicht angegeben, so wird für sie der Wert "default" angenommen. Eine Beispielzeichenfolge für Eigenschaften könnte wie folgt aussehen: "Scaling = centered, Dithering = enabled" Option "UseInt10Module" "boolean" Aktiverung des X-Int10-Moduls zum Warmstart aller Sekundärkarten, anstatt einen POST der Karten durch das NVIDIA-Kernelmodul durchzuführen. Standard: aus (POST wird durch das NVIDIA-Kernelmodul vorgenommen). Option "TwinView" "boolean" TwinView aktivieren oder deaktivieren. Details finden Sie in ANHANG I. Standard: TwinView ist deaktiviert. Option "TwinViewOrientation" "string" Steuert die Beziehung zwischen den beiden Bildschirmgeräten beim Einsatz von TwinView. Verwendet einen der folgenden Werte: "RightOf" (rechts), "LeftOf" (links), "Above" (über), "Below" (unter), "Clone" (klonen). Details finden Sie in ANHANG I. Standard: String ist NULL. Option "SecondMonitorHorizSync" "range(s)" Diese Option entspricht dem Eintrag HorizSync im Abschnitt "Monitor", gilt jedoch für den zweiten Bildschirm beim Einsatz von TwinView. Details finden Sie in ANHANG I. Standard: keiner. Option "SecondMonitorVertRefresh" "range(s)" Diese Option entspricht dem Eintrag VertSync im Abschnitt "Monitor", gilt jedoch für den zweiten Bildschirm beim Einsatz von TwinView. Details finden Sie in ANHANG I. Standard: keiner. Option "MetaModes" "string" Diese Option beschreibt die Moduskombination, die bei Einsatz von TwinView auf jedem Bildschirm eingesetzt werden soll. Details finden Sie in ANHANG I. Standard: String ist NULL. Option "NoTwinViewXineramaInfo" "boolean" Im TwinView-Modus bietet der NVIDIA-X-Treiber normalerweise eine Xinerama-Erweiterung, mit der X-Clients (wie Fenstermanager) die aktuelle TwinView-Konfiguration abfragen können. Manche Fenstermanager geraten hierbei durcheinander, weshalb dieses Verhalten über diese Option abgeschaltet werden kann. Standard: TwinView-Xinerama- Informationen werden bereitgestellt. Option "TVStandard" "string" Siehe (Anhang J) ANHANG J: TV-OUT KONFIGURIEREN. Option "TVOutFormat" "string" Siehe (Anhang J) ANHANG J: TV-OUT KONFIGURIEREN. Option "TVOverScan" "Dezimalwert zwischen 0.0 und 1.0" Gültige Werte sind 0.0 bis 1.0; siehe (Anhang J) ANHANG J: TV-OUT KONFIGURIEREN. Option "Stereo" "integer" Aktiviert auf Quadro-Chips Stereografikausgabe mit Quad- Buffering. Der Integerwert gibt an, was für eine Stereobrille verwendet wird: 1 - DDC-Brille. Das Sync-Signal wird über das DDC- Monitorsignal an die Brille geschickt. Hierzu wird üblicherweise ein durchgeschleiftes Kabel zwischen Monitor und Grafikkarte verwendet. 2 - "Blueline"-Brille. Hierzu wird üblicherweise ein durchgeschleiftes Kabel zwischen Monitor und Grafikkarte verwendet. Die Brille weiß anhand einer blauen Linie am unteren Bildrand, welches Auge angezeigt werden soll. In diesem Modus ist das Basisfenster einen Pixel weniger hoch als angefordert. Dieser Modus funktioniert nicht mit virtuellen Basisfenstern, die größer als das sichtbare Basisfenster sind (Desktop-Schwenkmodus). 3 - Onboard-Stereounterstützung. Diese Option findet sich normalerweise nur auf Karten für den professionellen Einsatz. Die Brille wird über einen DIN-Anschluss an der Rückseite der Grafikkarte angeschlossen. 4 - TwinView-Klonmodus-Stereo ("passives Stereo"). Auf Grafikkarten mit TwinView-Unterstützung wird das linke Auge auf dem ersten und das rechte Auge auf dem zweiten Bildschirm angezeigt. Diese Option wird normalerweise in Verbindung mit speziellen Projektoren verwendet, um so zwei polarisierte Bilder zu erzeugen, die dann mit polarisierten Brillen betrachtet werden. Um diesen Stereomodus zu nutzen, müssen Sie auch TwinView für den Klonmodus mit derselben Auflösung, demselben Schwenkversatz und denselben Schwenkbereichen für beide Bildschirme konfigurieren. Die Stereoanzeige ist nur auf Quadro-Karten verfügbar. Die Stereooptionen 1, 2 und 3 ("aktives" Stereo) können in Verbindung mit TwinView verwendet werden, wenn alle Modi in den jeweiligen Metamodi identische Timing-Parameter aufweisen. Einige diesbezügliche Tipps finden Sie in ANHANG L: PROGRAMMIERMODI. Für die Stereooption 4 ("passives" Stereo) gilt diese Einschränkung nicht. Auf dem ursprünglichen Quadro-Chip (NV10) ist der Stereobetrieb momentan manchmal noch etwas "eigenwillig", und es können Fehler bei der Links-Rechts-Umschaltung auftreten. Wir arbeiten daran, dieses Problem in einer zukünftigen Version zu beheben. Standard: Stereoanzeige ist deaktiviert. Die Stereooptionen 1 bis 3 ("aktive" Stereoanzeige) werden auf digitalen Flachbildschirmen nicht unterstützt. Option "AllowDFPStereo" "boolean" Standardmäßig deaktiviert der NVIDIA X-Treiber die aktive Stereofunktionalität (Optionen 1, 2 und 3), wenn erkannt wird, dass über den entsprechenden X-Bildschirm ein DFP angesteuert wird. Mit der Option "AllowDFPStereo" lässt sich diese Prüfung umgehen und die Deaktivierung vermeiden. Option "NoBandWidthTest" "boolean" Bei der Modusvalidierung prüft der X-Treiber unter anderem, ob der gegebene Modus den Speicherbandbreiten- Beschränkungen der Hardware entspricht. Dieser Test kann mit der vorliegenden Option deaktiviert werden. Standard: die Speicherbandbreiten-Überprüfung wird durchgeführt. Option "IgnoreDisplayDevices" "string" Diese Option befiehlt dem NVIDIA-Kernelmodul, die angegebenen Bildschirmklassen bei der Erkennung der angeschlossenen Anzeigegeräte komplett zu ignorieren. Sie können hier eine kommagetrennte Liste mit einer beliebigen Kombination der Einträge "CRT", "DFP" und "TV" angeben. Beispiel: Option "IgnoreDisplayDevices" "DFP, TV" So versucht der NVIDIA-Treiber nicht, angeschlossene Flachbildschirme oder Fernsehgeräte zu erkennen. Diese Option wird normalerweise nicht benötigt; manche BIOS-Versionen enthalten jedoch unzutreffende Angaben zu den potenziell angeschlossenen Bildschirmen oder zum i2c- Port für die Erkennung. Solche Fehler können zu langen Verzögerungen beim X-Start führen. Wenn bei Ihnen derartige Verzögerungen auftreten, so können Sie sie eventuell vermeiden, indem Sie dem NVIDIA-Treiber befehlen, Anzeigegeräte, die sowieso nicht angeschlossen sind, zu ignorieren. HINWEIS: Alle Geräte, die über einen 15-Pin-VGA-Stecker angeschlossen sind, gelten für den Treiber als "CRT". "DFP" sollten Sie nur für Flachbildschirme verwenden, die über einen DVI-Anschluss angeschlossen sind. Option "MultisampleCompatibility" "boolean" Aktiviert bzw. deaktiviert separate Front- und Back-Buffer beim Multisampling. Diese Option hat einen höheren Speicherbedarf zur Folge, ist jedoch für eine korrekte Ausgabe unerlässlich, wenn bei Multisamples oder FSAA- Grafikobjekten sowohl in den Front- als auch in den Back-Buffer gerendert werden soll. Für den störungsfreien Betrieb von SoftImage XSI muss diese Option aktiviert sein. Standard: Front- und Back-Buffer teilen sich einen gemeinsamen Multisample-Puffer. Option "NoPowerConnectorCheck" "boolean" Wenn der NVIDIA X-Treiber feststellt, dass ein Grafikchip verwendet wird, der eine externe Stromversorgung benötigt, eine solche jedoch nicht angeschlossen ist, wird die X-Server-Initialisierung abgebrochen. Mit dieser Option kann diese Prüfung übersprungen werden. Standard: Prüfung findet statt. Option "XvmcUsesTextures" "boolean" Zwingt die XvMC, für XvMCPutSurface-Vorgänge statt des Video-Overlay die 3D-Engine zu verwenden. Standard: Falls verfügbar, wird das Video-Overlay verwendet. __________________________________________________________________________ (Anhang E) ANHANG E: EINSTELLUNGSMÖGLICHKEITEN FÜR DIE OPENGL- UMGEBUNGSVARIABLE __________________________________________________________________________ VOLLBILD-ANTIALIASING Antialiasing ist eine Technik, die eingesetzt wird, um die Ränder von Objekten zu glätten und den "Treppenstufen"-Effekt, der manchmal auftritt, zu reduzieren. Vollbild-Antialiasing wird ab der GeForce-GPU unterstützt. Durch das Setzen der entsprechenden Umgebungsvariable können Sie auf diesen GPUs in jeder beliebigen OpenGL-Anwendung Vollbild-Antialiasing aktivieren. Es sind verschiedene Antialiasing-Methoden verfügbar, die Sie durch Setzen der Umgebungsvariable __GL_FSAA_MODE auswählen können. Bitte beachten Sie, dass ein Erhöhen der Samplezahl während des Rendering mit aktiviertem Vollbild-Antialiasing zu Leistungseinbußen führen kann. __GL_FSAA_MODE GeForce, GeForce2, Quadro und Quadro2 Pro ----------------------------------------------------------------------- 0 Vollbild-Antialiasing deaktiviert 1 Vollbild-Antialiasing deaktiviert 2 Vollbild-Antialiasing deaktiviert 3 1.5 x 1.5 Supersampling 4 2 x 2 Supersampling 5 Vollbild-Antialiasing deaktiviert 6 Vollbild-Antialiasing deaktiviert 7 Vollbild-Antialiasing deaktiviert __GL_FSAA_MODE GeForce4 MX, GeForce4 4xx Go, Quadro4 380, 550, 580 XGL und Quadro4 NVS ----------------------------------------------------------------------- 0 Vollbild-Antialiasing deaktiviert 1 2x Bilinear Multisampling 2 2x Quincunx Multisampling 3 Vollbild-Antialiasing deaktiviert 4 2 x 2 Supersampling 5 Vollbild-Antialiasing deaktiviert 6 Vollbild-Antialiasing deaktiviert 7 Vollbild-Antialiasing deaktiviert __GL_FSAA_MODE GeForce3, Quadro DCC, GeForce4 Ti, GeForce4 4200 Go und Quadro4 700, 750, 780, 900, 980 XGL ----------------------------------------------------------------------- 0 Vollbild-Antialiasing deaktiviert 1 2x Bilinear Multisampling 2 2x Quincunx Multisampling 3 Vollbild-Antialiasing deaktiviert 4 4x Bilinear Multisampling 5 4x Gaussian Multisampling 6 4x Bilinear Multisampling / 4x Supersampling 7 Vollbild-Antialiasing deaktiviert __GL_FSAA_MODE GeForce FX, Quadro FX ----------------------------------------------------------------------- 0 Vollbild-Antialiasing deaktiviert 1 2x Bilinear Multisampling 2 2x Quincunx Multisampling 3 Vollbild-Antialiasing deaktiviert 4 4x Bilinear Multisampling 5 4x Gaussian Multisampling 6 2x Bilinear Multisampling / 4x Supersampling 7 4x Bilinear Multisampling / 4x Supersampling ANISOTROPE TEXTURFILTERUNG Die automatische anisotrope Texturfilterung kann über die Umgebungsvariable __GL_DEFAULT_LOG_ANISO aktiviert werden. Zulässige Werte sind: __GL_DEFAULT_LOG_ANISO GeForce/GeForce2/GeForce4 MX Beschreibung ----------------------------------------------------------------------- 0 Keine anisotrope Filterung 1 Automatische anisotrope Filterung aktivieren __GL_DEFAULT_LOG_ANISO GeForce3/GeForce4 Ti/GeForce FX Beschreibung ----------------------------------------------------------------------- 0 Keine anisotrope Filterung 1 Niedrige anisotrope Filterung 2 Mittlere anisotrope Filterung 3 Maximale anisotrope Filterung VBLANK-SYNCHRONISIERUNG Indem Sie die Umgebungsvariable __GL_SYNC_TO_VBLANK ungleich null setzen, können Sie erzwingen, dass sich glXSwapBuffer mit der vertikalen Wiederholrate Ihres Bildschirms synchronisiert. Der Swap-Vorgang darf nur während einer vertikalen Austastung erfolgen. Wird __GL_SYNC_TO_VBLANK in Verbindung mit TwinView eingesetzt, so kann sich OpenGL nur an einem der beiden Anzeigegeräte synchronisieren. Dies kann zu Flackerproblemen (Tearing) auf dem jeweils anderen Anzeigegerät führen. Über die Umgebungsvariable __GL_SYNC_DISPLAY_DEVICE können Sie festlegen, an welchem Anzeigegerät die Synchronisierung erfolgen soll. Setzen Sie diese Umgebungsvariable auf den Namen eines Anzeigegeräts wie z. B. "CRT-1". Eine Liste der vorhandenen Anzeigegeräte sowie deren Namen finden Sie in Ihrer X-Logfile unter der Zeile "Connected display device(s):". CPU-SPEZIFISCHE FUNKTIONEN DEAKTIVIEREN Wenn Sie die Umgebungsvariable __GL_FORCE_GENERIC_CPU ungleich null setzen, wird die Nutzung CPU-spezifischer Leistungsmerkmale wie MMX, SSE oder 3DNOW! verhindert. Diese Option führt zu Leistungseinbußen. In Verbindung mit Software wie dem Valgrind-Speicherdebugger kann sie jedoch recht hilfreich sein. __________________________________________________________________________ (Anhang F) ANHANG F: AGP KONFIGURIEREN __________________________________________________________________________ Es gibt mehrere Möglichkeiten für die Konfiguration der AGP-Nutzung durch das NVIDIA-Kernelmodul: Sie können zwischen der Verwendung des AGP- Moduls von NVIDIA (NVAGP) oder des AGP-Moduls, das mit dem Linux-Kernel geliefert wird (AGPGART) wählen. Die jeweilige Verwendung wird durch die Option "NvAGP" in Ihrer X-Konfigurationsdatei gesteuert: Option "NvAgp" "0" ... deaktiviert die AGP-Unterstützung Option "NvAgp" "1" ... wenn möglich, NVAGP verwenden Option "NvAgp" "2" ... wenn möglich, AGPGART verwenden Option "NvAGP" "3" ... versuche AGPGART; wenn dies fehlschlägt, versuche NVAGP Der Standard ist 3 (der Standard war 1 bis nach 1.0-1251). Sie sollten das AGP-Modul aussuchen, das am besten mit Ihrem AGP-Chipsatz funktioniert. Sollten Probleme mit der Stabilität auftreten, können Sie zunächst versuchen, AGP zu deaktivieren, und sehen, ob das Problem dadurch behoben wird. Danach können Sie mit einem der anderen AGP-Module experimentieren. Den aktuellen AGP-Status können Sie jederzeit über die Dateisystem- Schnittstelle /proc abfragen (siehe ANHANG O: PROC-SCHNITTSTELLE). Um das Linux-AGPGART-Modul zu nutzen, muss es mit Ihrem Kernel kompiliert werden, entweder statisch gelinkt oder als Modul-Build. Die NVIDIA-AGP- Unterstützung kann nicht verwendet werden, wenn AGPGART in den Kernel geladen ist. Es wird empfohlen, dass Sie AGPGART als Modul kompilieren und sicherstellen, dass es bei der Ausführung von NVIDIA AGP nicht geladen wird. Bitte beachten Sie, dass ein Ändern der AGP-Treiber im Allgemeinen einen Neustart erfordert, bevor die Änderungen wirksam werden. Die folgenden AGP-Chipsätze werden von NVIDIAs AGP unterstützt; für alle anderen Chipsätze empfehlen wir die Verwendung des AGPGART-Moduls. o Intel 440LX o Intel 440BX o Intel 440GX o Intel 815 ("Solano") o Intel 820 ("Camino") o Intel 830 o Intel 840 ("Carmel") o Intel 845 ("Brookdale") o Intel 845G o Intel 850 ("Tehama") o Intel 855 ("Odem") o Intel 860 ("Colusa") o Intel 865G ("Springdale") o Intel 875P ("Canterwood") o Intel E7205 ("Granite Bay") o Intel E7505 ("Placer") o AMD 751 ("Irongate") o AMD 761 ("IGD4") o AMD 762 ("IGD4 MP") o AMD 8151 ("Lokar") o VIA 8371 o VIA 82C694X o VIA KT133 o VIA KT266 o VIA KT400 o VIA P4M266 o VIA P4M266A o VIA P4X400 o RCC CNB20LE o RCC 6585HE o Micron SAMDDR ("Samurai") o Micron SCIDDR ("Scimitar") o NVIDIA nForce o NVIDIA nForce2 o NVIDIA nForce3 o ALi 1621 o ALi 1631 o ALi 1647 o ALi 1651 o ALi 1671 o SiS 630 o SiS 633 o SiS 635 o SiS 645 o SiS 646 o SiS 648 o SiS 648FX o SiS 650 o SiS 655FX o SiS 730 o SiS 733 o SiS 735 o SiS 745 o ATI RS200M Bei AGP-Stabilitätsproblemen sollten Sie folgende Punkte im Hinterkopf behalten: o Unterstützung für die Seitengrößen-Erweiterung auf Athlon-Prozessoren Manche Linux-Kernel haben einen Fehler in Zusammenhang mit gegensätzlichen Cache-Attributen, der durch das Advanced Speculative Caching in neueren Prozessoren der AMD Athlon-Familie (AMD Athlon XP, AMD Athlong 4, AMD Athlon MP und AMD Duron Modell 6 oder höher) zutage tritt. Dieser Kernelfehler macht sich üblicherweise bemerkbar, wenn eine AGP-Grafikkarte eingesetzt wird und die beschleunigte 3D-Grafik stark beansprucht wird. In Linux-Distributionen auf Basis des Kernels 2.4.19 oder neuer *sollte* dieser Fehler behoben sein. Bei älteren Kernels muss der Anwender jedoch etwas nachhelfen und sicherstellen, dass ein kleiner Teil des Advanced Speculative Caching deaktiviert wird (was üblicherweise durch einen Kernelpatch geschehen wird) und eine Bootoption gesetzt wird. Der NVIDIA-Treiber deaktiviert auf betroffenen AMD-Prozessoren automatisch den fraglichen Teil des Advanced Speculative Caching, ohne dass hierfür ein Kernelpatch nötig wäre; der Treiber kann sogar mit Kernels verwendet werden, in denen der Fehler bereits behoben ist. Auf älteren Kernels muss der Anwender dann noch seinen Teil zur Problemlösung beisteuern und über eine Boot-Option 4 MB-Seiten explizit deaktivieren. Dies kann in der Boot-Befehlszeile mit folgendem Befehl geschehen: mem=nopentium Ebenso kann folgende Zeile in etc/lilo.conf eingefügt werden: append = "mem=nopentium" o BIOS-Einstellung "AGP Drive Strength" (Via-basierte Mainboards) Bei vielen Via-basierten Mainboards können Sie die AGP-Signalstärke (AGP Drive Strength) im System-BIOS einstellen. Diese Option hat direkte Auswirkungen auf die Systemstabilität; für NVIDIA-Hardware hat sich der Bereich von 0xEA bis 0xEE bewährt. Wird eines der Halbbytes auf 0xF gesetzt, so hat dies meist schwer wiegende Stabilitätsprobleme zur Folge. Wenn Sie mit dieser Einstellung experimentieren möchten, sollten Sie immer daran denken, dass dies auf Ihr eigenes Risiko geschieht und falsche Einstellungen zu einem System führen können, das sich nicht mehr starten lässt. In so einem Fall müssen Sie die Einstellung auf einen funktionierenden Wert zurücksetzen (mit einer PCI-Grafikkarte oder indem Sie das BIOS auf die Standardwerte zurücksetzen). o System-BIOS-Version Stellen Sie sicher, dass Sie das neueste System-BIOS vom Mainboard- Hersteller haben. o AGP-Rate Wenn sich das System aufhängt, kann es helfen, die AGP-Rate auf einen niedrigeren Wert zu setzen. Entpacken Sie hierzu zunächst die .run- Datei: sh NVIDIA-Linux-x86-1.0-6106-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-6106-pkg1/usr/src/nv/ Öffnen Sie dann os-registry.c in einem Editor und nehmen Sie folgende Änderungen vor: - static int NVreg_ReqAGPRate = 7; + static int NVreg_ReqAGPRate = 4; /* AGP-Rate = 4x */ oder + static int NVreg_ReqAGPRate = 2; /* AGP-Rate = 2x */ oder + static int NVreg_ReqAGPRate = 1; /* AGP-Rate = 1x */ Anschließend aktivieren Sie den Parameter "ReqAGPRate": - { NULL, "ReqAGPRate", &NVreg_ReqAGPRate, 0 }, + { NULL, "ReqAGPRate", &NVreg_ReqAGPRate, 1 }, Kompilieren Sie das Kernelmodul dann neu und laden Sie die neue Version. Auf Athlon-Motherboards mit dem VIA KX133- oder 694X-Chipsatz (wie dem ASUS K7V-Motherboard) setzen die NVIDIA-Treiber den AGP 2x-Modus als Standard, um eine unzureichende Stärke eines der Signale zu umgehen. Sie können AGP 4x erzwingen, indem Sie NVreg_EnableVia4x auf 1 setzen. Bitte beachten Sie, dass das System dadurch instabil werden kann. Auf den Chipsätzen ALi1541 und ALi1647 deaktivieren die NVIDIA-Treiber AGP, um Probleme mit dem Timing und der Signalintegrität zu umgehen. Sie können die Verwendung von AGP erzwingen, indem Sie NVreg_EnableALiAGP auf 1 setzen. Bitte beachten Sie, dass das System dadurch instabil werden kann. Auf Motherboards des Typs ASUS A7V8X-X KT400 kann es bei der Verwendung älterer SBIOS-Versionen vorkommen, dass der Chipsatz falsch konfiguriert wird, wenn eine AGP 2.x-Grafikkarte installiert ist. Wenn Sie ein ASUS KT400-System verwenden und X beim Starten mit aktiviertem Linux AGPGART oder NvAGP hängt, so sollten Sie sicherstellen, dass Sie eine aktuelle SBIOS-Version verwenden. (Bei AGP 8X-Karten tritt dieses Problem nicht auf.) __________________________________________________________________________ (Anhang G) ANHANG G: ALI-SPEZIFISCHE PROBLEME __________________________________________________________________________ Die folgenden Tipps können dabei helfen, problematische ALi-Systeme zu stabilisieren: o TURBO AGP MODE im BIOS deaktivieren. o Bei Verwendung eines P5A: Upgrade auf BIOS Revision 1002 BETA 2. o Bei Verwendung eines 1007, 1007A oder 1009: Anpassen der IO Recovery Time 4 Takte. o AGP ist auf einigen ALi-Chipsätzen standardmäßig deaktiviert (ALi1541, ALi1647), um schwer wiegende Systemstabilitätsprobleme mit diesen Chipsätzen zu umgehen. Bitte beachten Sie die Kommentare in Bezug auf NVreg_EnableALiAGP in os-registry.c, um AGP trotzdem zu erzwingen. __________________________________________________________________________ (Anhang H) ANHANG H: TNT-SPEZIFISCHE PROBLEME __________________________________________________________________________ Die meisten Problemfälle, die auf TNT-Karten mit SGRAM/SDRAM aufgetaucht sind, konnten behoben werden. Es gibt jedoch die geringfügige Möglichkeit, dass auf Ihrer Grafikkarte das falsche BIOS installiert ist und dieser Treiber bei Ihnen weiterhin nicht funktioniert. Versagt der Treiber bei Ihnen, schlagen wir folgende Vorgehensweise vor: o Beobachten Sie Ihren Monitor beim Systemstart. Der allererste, kurz erscheinende Bildschirm zeigt den Typ des Grafikspeichers an, über den Ihre Karte verfügt. Dies ist entweder SGRAM oder SDRAM. o Editieren Sie die Datei "os-registry.c" aus den Kernelmodul-Quellen. Achten Sie auf die Variable "NVreg_VideoMemoryTypeOverride". Setzen Sie den Wert der Variablen auf die Speicherart, die Sie haben (numerisch, siehe die Zeile direkt oberhalb). o Da wir normalerweise diese Variable nicht verwenden, ändern Sie bitte das "#if 0", das sich ungefähr 10 Zeilen oberhalb der Variable befindet, in "#if 1". o Erstellen und reinstallieren Sie den neuen Treiber ("make") __________________________________________________________________________ (Anhang I) ANHANG I: KONFIGURIEREN VON TWINVIEW __________________________________________________________________________ Die TwinView-Funktion wird nur von NVIDIA-Grafikprozessoren unterstützt, die über Multidisplay-Funktionen verfügen, so z. B. der GeForce2 MX, GeForce2 Go, Quadro2 MXR, Quadro2 Go sowie alle Modelle der Familien GeForce4, Quadro4, GeForce FX und Quadro FX. Bitte setzen Sie sich mit dem Hersteller Ihrer Grafikkarte in Verbindung, um herauszufinden, ob TwinView auf Ihrer Karte unterstützt wird. TwinView ist ein Betriebsmodus, in dem zwei Anzeigegeräte (digitale Flachbildschirme, Röhrenmonitore und Fernseher) den Inhalt eines einzelnen X-Bildschirms in einer beliebigen Konfiguration darstellen können. Diese Art des Mehrbildschirmbetriebs hat einige klare Vorteile gegenüber anderen Techniken (wie z.B. Xinerama): o Es wird ein einzelner X-Bildschirm verwendet. Der NVIDIA Treiber hält alle Informationen über mehrere Anzeigegeräte vom X-Server fern; was X betrifft, gibt es nur einen Bildschirm. o Beide Anzeigegeräte teilen sich einen Framebuffer. Damit ist die gesamte Funktionalität, die auf einem einzelnen Bildschirm vorhanden ist (z.B. beschleunigtes OpenGL), auch in TwinView verfügbar. o Es ist kein zusätzlicher Aufwand erforderlich, um einen einzelnen gemeinsamen Desktop zu emulieren. Wenn Sie sich dafür interessieren, jedes Anzeigegerät als separaten X- Bildschirm zu verwenden, lesen Sie bitte (Anhang R) ANHANG R: MEHRERE X-BILDSCHIRME AUF EINER KARTE. TWINVIEW-OPTIONEN IN DER X-KONFIGURATIONSDATEI Um TwinView zu aktivieren, müssen Sie die folgenden Optionen im Abschnitt "Device" Ihrer X-Konfigurationsdatei angeben: Option "TwinView" Option "MetaModes" "" Darüber hinaus müssen Sie entweder Option "SecondMonitorHorizSync" "" Option "SecondMonitorVertRefresh" "" oder Option "HorizSync" "" Option "VertRefresh" "" angeben. Sie können auch eine der folgenden Optionen verwenden, obwohl diese nicht erforderlich sind: Option "TwinViewOrientation" "" Option "ConnectedMonitor" "" Nachfolgend finden Sie detaillierte Beschreibungen jeder einzelnen Option: o TwinView Diese Option ist für die Aktivierung von TwinView erforderlich; ohne diese Option werden alle anderen mit TwinView in Beziehung stehenden Optionen ignoriert. o SecondMonitorHorizSync, SecondMonitorVertRefresh Mit diesen Optionen werden die Grenzbedingungen des zweiten Monitors spezifiziert. Die gegebenen Werte sollten der gleichen Konvention wie die Einträge "HorizSync" und "VertRefresh" im Abschnitt "Monitor" folgen. Wie die Man-Page zu XF86Config erklärt: Die Bereiche können eine kommagetrennte Liste verschiedener Werte und/oder Wertebereiche sein, in denen ein Bereich durch zwei unterschiedliche Werte, getrennt durch einen Bindestrich gegeben ist. Die HorizSync ist in kHz angegeben und die VertRefresh ist in Hz angegeben. Wenn Sie den EDIDs Ihrer Bildschirmgeräte trauen, können Sie die Option "UseEdidFreqs" statt dieser Optionen verwenden (eine Beschreibung der Option "UseEdidFreqs" finden Sie in ANHANG D.) o HorizSync, VertRefresh Oft ist unklar, welcher Bildschirm als "erstes" und welcher als "zweites" Anzeigegerät verwendet wird. Daher können statt der SecondMonitor-Versionen auch die folgenden Optionen verwendet werden. Mit ihnen wird eine strichkommagetrennte Liste von Frequenzbereichen übergeben, denen optional jeweils ein Anzeigegerätename vorangestellt werden kann. Beispiel: Option "HorizSync" "CRT-0: 50-110, DFP-0: 40-70" Option "VertRefresh" "CRT-0: 60-120, DFP-0: 60" Nähere Informationen finden Sie im Anhang zu Anzeigegerätenamen. o MetaModes Ein einzelner MetaMode beschreibt, welcher Modus auf welchem Anzeigegerät zu einer gegebenen Zeit verwendet werden soll. Mehrere MetaModes führen die Kombination der Modi und die Sequenz auf, in der diese eingesetzt werden sollen. Wenn der NVIDIA-Treiber X darüber informiert, welche Modi verfügbar sind, wird nur das kleinste Begrenzungsrechteck des MetaMode an X übergeben, während der Modus "pro Bildschirmgerät" intern im NVIDIA-Treiber verbleibt. In der MetaMode-Syntax werden Modi innerhalb eines MetaMode durch ein Komma getrennt und mehrere MetaModes durch ein Semikolon. Zum Beispiel: ", ; , " ist der Name des Modus, der auf Anzeigegerät 0 verwendet wird - gleichzeitig mit auf Anzeigegerät 1. Ein Moduswechsel bewirkt dann, dass auf Anzeigegerät 0 und auf Anzeigegerät 1 verwendet wird. Nachfolgend finden Sie einen realen MetaMode-Eintrag aus der Beispiel-X- Konfigurationsdatei: Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768" Wenn Sie nicht möchten, dass ein Anzeigegerät für einen bestimmten MetaMode aktiv ist, können Sie den Modusnamen "Null" verwenden oder den Modusnamen ganz auslassen: "1600x1200, NULL; NULL, 1024x768" oder "1600x1200; , 1024x768" Optional können den Modinamen Versatzangaben (Offsets) zur Positionierung der Anzeigegeräte innerhalb des virtuellen Bildschirms folgen, so z. B.: "1600x1200 +0+0, 1024x768 +1600+0; ..." Die Versatzangaben folgen den Konventionen, die in der X-Befehlszeilenoption "-geometry" verwendet werden; d. h. sowohl positive als auch negative Versatzwerte sind gültig - negative Werte sind jedoch nur erlaubt, wenn eine virtuelle Bildschirmgröße explizit in der X-Konfigurationsdatei angegeben ist. Sind für den MetaMode keine Versatzwerte angegeben, werden diese entsprechend dem Wert der Option TwinViewOrientation (siehe weiter unten) berechnet. Bitte beachten Sie: Sobald die Versatzwerte für einen beliebigen Modus in einem bestimmten MetaMode gegeben sind, werden für alle Modi innerhalb dieses MetaMode Versatzangaben erwartet; in einem solchen Fall wird angenommen, dass der Versatz +0+0 entspricht, wenn nichts anderes angegeben wird. Dort, wo sie nicht explizit vorgegeben ist, wird die virtuelle Bildschirmgröße als das Begrenzungsrechteck aller MetaMode- Begrenzungsrechtecke berechnet. MetaModes mit einem Begrenzungsrechteck, das größer als eine explizit vorgegebene virtuelle Bildschirmgröße ist, werden als ungültig verworfen. Ein MetaMode-String kann weiters mit einer "Schwenkbereich"-Angabe ("Panning Domain") ergänzt werden, z. B.: "1024x768 @1600x1200, 800x600 @1600x1200" Der Schwenkbereich ist der Bereich, in dem der Bildausschnitt des Bildschirms verschoben wird, um der Maus zu folgen. Mit TwinView erfolgt dieser Schwenk auf zwei Ebenen: Zunächst wird der Bildausschnitt eines einzelnen Anzeigegerätes innerhalb des entsprechenden Schwenkbereichs verschoben, und zwar so lange, wie der Bildausschnitt im Begrenzungsrechteck des MetaMode liegt. Sobald der Mauszeiger das Begrenzungsrechteck des MetaMode verlässt, wird der gesamte MetaMode (d. h. alle Anzeigegeräte) verschoben, um der Maus innerhalb des virtuellen Bildschirms zu folgen. Bitte beachten Sie, dass die jeweiligen Schwenkbereiche der Anzeigegeräte als Standard an die Position der Bildausschnitte der Anzeigegeräte gebunden sind; standardmäßig bleiben die Bildausschnitte also miteinander "verbunden" und führen nur die zweite Schwenkart aus. Schwenkbereiche können sicherlich am besten genutzt werden, um tote Bereiche - Bereiche des virtuellen Bildschirms, die aufgrund von Anzeigegeräten mit unterschiedlichen Auflösungen nicht genutzt werden können - zu eliminieren. Zum Beispiel: "1600x1200, 1024x768" Diese Angabe erzeugt einen Bereich unterhalb des 1024x768- Bildschirms, auf den nicht zugegriffen werden kann. Die Angabe eines Schwenkbereichs für das zweite Anzeigegerät: "1600x1200, 1024x768 @1024x1200" ermöglicht den Zugriff auf diesen toten Bereich, indem der 1024x768-Bildausschnitt innerhalb des 1024x1200-Schwenkbereichs nach oben und unten verschoben werden kann. In Verbindung mit Schwenkbereichen können Sie Versatzangaben einsetzen, um die Schwenkbereiche im virtuellen Bildschirmbereich zu positionieren (bitte beachten Sie, dass der Versatz den Schwenkbereich beschreibt und den Bildausschnitt nur insoweit betrifft, als dieser innerhalb des Schwenkbereichs liegen muss). Nachfolgend werden zum Beispiel zwei Modi beschrieben, von denen jeder einen Schwenkbereich mit einer Breite von 1900 Pixeln hat und in denen der zweite Bildschirm unterhalb des ersten positioniert wird. "1600x1200 @1900x1200 +0+0, 1024x768 @1900x768 +0+1200" Da oft unklar ist, welcher MetaMode-Modus auf welchem Bildschirm verwendet wird, kann den Modusbeschreibungen ein Anzeigegerätename vorangestellt werden. Beispiel: "CRT-0: 1600x1200, DFP-0: 1024x768" Wird kein MetaMode-String angegeben, so verwendet der X-Treiber die Modi, die im relevanten Unterabschnitt "Display" aufgeführt sind, um entsprechende passende Modi für jedes Anzeigegerät zu verwenden. o TwinViewOrientation Diese Option steuert die Positionierung des zweiten Bildschirms in Relation zum ersten Bildschirm innerhalb des virtuellen X-Bildschirms, wenn in den MetaModes keine Versatzwerte explizit angegeben werden. Die möglichen Werte sind: "RightOf" (Standard) "LeftOf" "Above" "Below" "Clone" Bei "Clone" (Klonen) wird beiden Anzeigegeräten ein Versatz von 0,0 zugewiesen. Da oft unklar ist, welcher Bildschirm als "erstes" und welcher als "zweites" Anzeigegerät verwendet wird, kann diese Einstellung etwas verwirrend sein. Sie können daher Anzeigegerätenamen verwenden, um die Positionierung der Bildschirme eindeutig im Klartext anzugeben. Beispiel: "CRT-0 LeftOf DFP-0" o ConnectedMonitor Diese Option ermöglicht es Ihnen, die vom NVIDIA-Kernelmodul automatisch erkannte Einstellung für das an die Grafikkarte angeschlossene Gerät zu übergehen. Dies kann zum Beispiel dann nützlich sein, wenn eines Ihrer Anzeigegeräte die Erkennung über Display Data Channel-Protokolle (DDC) nicht unterstützt. Diese Option erwartet eine kommagetrennte Liste von Anzeigegerätenamen, so zum Beispiel: "CRT-0, CRT-1" "CRT" "CRT-1, DFP-0" ACHTUNG! Diese Option überschreibt die automatische Erkennung der angeschlossenen Anzeigegeräte durch das NVIDIA Kernelmodul. Sie wird nur in sehr wenigen Fällen tatsächlich gebraucht, etwa wenn der Bildschirm keine DDC-Informationen liefert oder wenn er an einen KVM-Umschalter angeschlossen ist. In den meisten anderen Fällen sollte diese Option besser nicht angegeben werden. Wie bei allen XF86Config-Einträgen werden Leerzeichen ignoriert und alle Einträge sind unabhängig von der Groß-/Kleinschreibung. TWINVIEW FAQS - HÄUFIG GESTELLTE FRAGEN F: Auf meinem zweiten Bildschirm erscheint keine Anzeige. Was ist nicht in Ordnung? A: Bildschirme, die keine Bildschirmerkennung über Display Data Channel (DDC)-Protokolle unterstützen (was die meisten älteren Monitore einschließt), können von Ihrer NVIDIA-Karte nicht erkannt werden. Der NVIDIA X-Treiber muss über die Option "ConnectedMonitor" explizit darüber informiert werden, welche Anzeigegeräte angeschlossen sind, so z. B.: Option "ConnectedMonitor" "CRT, CRT" F: Sind die Fenstermanager in der Lage, Fenster ordnungsgemäß zu platzieren (kann es zum Beispiel vermieden werden, die Fenster auf beiden Anzeigegeräten aufzuteilen oder Fenster in Bereiche des virtuellen Desktops zu setzen, die nicht zugänglich sind)? A: Ja. Der NVIDIA X-Treiber bietet eine Xinerama-Erweiterung, mit der X-Clients (wie die Fenstermanagern) die aktuelle TwinView-Konfiguration ermitteln können. Bitte beachten Sie dabei, dass das Xinerama-Protokoll die Clients nicht darüber informieren kann, wenn eine Konfigurationsänderung erfolgt. Wenn Sie also zu einem anderen MetaMode wechseln, nimmt Ihr Fenstermanager immer noch an, dass Sie die vorherige Konfiguration verwenden. Wenn die Xinerama-Erweiterung zusammen mit der XF86VidMode- Erweiterung zur Erzeugung von Moduswechsel-Events verwendet wird, sollten die Fenstermanager in der Lage sein, die entsprechende TwinView-Konfiguration jederzeit zu ermitteln. Leider scheinen manche Fenstermanager durch die von XineramaQueryScreens() gelieferten Daten durcheinander zu geraten; um solche Fenstermanager-Probleme zu umgehen, können Sie die Bekanntgabe des TwinView-Bildschirmlayouts mit der X-Konfigurationsoption "NoTwinViewXineramaInfo" unterbinden (nähere Informationen hierzu finden Sie in Anhang D). Bitte denken Sie daran, dass der NVIDIA-Treiber keine Xinerama- Erweiterung bereitstellen kann, wenn die eigene Xinerama-Erweiterung des X-Servers verwendet wird. Wird Xinerama in der X-Konfigurationsdatei oder in der X-Befehlszeile explizit aufgerufen, so kann NVIDIAs Xinerama-Erweiterung nicht installiert werden. Vergewissern Sie sich daher, dass in der X-Logfile kein Eintrag wie der folgende steht: (++) Xinerama: enabled Ansonsten kann der NVIDIA-Treiber im TwinView-Modus keine Xinerama- Erweiterung bereitstellen. Eine weitere Lösung zur Vermeidung von nicht zugänglichen Bereichen im virtuellen Bildschirms ist die Verwendung von Schwenkbereichen (siehe die MetaMode-Beschreibung weiter oben). Eine dritte Möglichkeit ist die Verwendung zweier separater X- Bildschirme anstelle von TwinView. Bitte lesen Sie hierzu (Anhang R) ANHANG R: MEHRERE X-BILDSCHIRME AUF EINER KARTE. F: Warum kann ich mit einer GeForce2 MX keine Auflösung von 1600x1200 auf dem zweiten Anzeigegerät erzielen? A: Aufgrund der Tatsache, dass bei der GeForce2 MX als zweites Anzeigegerät ein digitaler Flachbildschirm vorgesehen ist, liegt der Pixeltakt für das zweite Anzeigegerät bei nur 150MHz. Dadurch wird die Auflösung für das zweite Anzeigegerät effektiv auf etwa 1280x1024 beschränkt (eine Beschreibung über die Beschränkung der programmierbaren Modi durch Pixeltakt-Frequenzen erhalten Sie im XFree86 Video Timings HOWTO). Auf GeForce4- oder GeForce FX-Chips gilt diese Beschränkung nicht -- hier haben beide Schirme denselben Pixeltakt. F: Funktionieren Video-Overlays auf beiden Anzeigegeräten? F: Hardware-Video-Overlays funktionieren nur auf dem ersten Anzeigegerät. Die aktuelle Lösung besteht darin, dass Blitted Video statt TwinView eingesetzt wird. F: Wie werden die virtuellen Bildschirmabmessungen in TwinView ermittelt? A: Nach der Validierung aller angeforderten Modi und der Versatzberechnung für alle MetaMode-Bildausschnitte berechnet der NVIDIA-Treiber das Begrenzungsrechteck der Schwenkbereiche für jeden einzelnen MetaMode. So wird die maximale Breite und Höhe des Begrenzungsrechtecks ermittelt. Bitte beachten Sie, dass ein Nebeneffekt dieses Vorganges ist, dass die virtuelle Breite und die virtuelle Höhe eventuell aus verschiedenen MetaModes erzeugt werden. Wenn wir den folgenden MetaMode String annehmen: "1600x1200,NULL; 1024x768+0+0, 1024x768+0+768" ist die daraus resultierende virtuelle Bildschirmgröße 1600 x 1536. F: Kann ich Vollbildspiele über beide Bildschirme verteilt spielen? A: Ja. Obwohl die Details der Konfiguration von Spiel zu Spiel unterschiedlich sein werden, liegt die grundsätzliche Idee darin, dass ein MetaMode X einen Modus bietet, dessen Auflösung das Begrenzungsrechteck der Bildausschnitte für diesen MetaMode ist. Beispiel: Option "MetaModes" "1024x768,1024x768; 800x600,800x600" Option "TwinViewOrientation" "RightOf" erzeugt zwei Modi: einen mit einer Auflösung von 2024x768 und einen weiteren mit einer Auflösung von 1600x600. Spiele wie Quake 3 Arena verwenden die VidMode-Erweiterung zur Ermittlung der Auflösungen der aktuell verfügbaren Modi. Um Quake 3 Arena so zu konfigurieren, dass der obige MetaMode-String verwendet wird, fügen Sie Ihrer q3config.cfg-Datei die folgenden Einträge hinzu: seta r_customaspect "1" seta r_customheight "600" seta r_customwidth "1600" seta r_fullscreen "1" seta r_mode "-1" Bitte beachten Sie, dass unter Voraussetzung der obigen Konfiguration keinen Modus mit einer Auflösung von 800x600 gibt (bitte denken Sie daran, dass der MetaMode "800x600, 800x600" eine Auflösung von 1600x600 hat) - wenn Sie also die zu verwendende Auflösung für Quake 3 Arena auf 800x600 ändern, wird das Spiel im linken unteren Bereich Ihres Bildschirms angezeigt und der Rest des Bildschirms grau unterlegt. Um zusätzlich auch Einzelbildschirm-Modi bereitzustellen, kann ein geeigneter MetaMode-String zum Beispiel wie folgt aussehen: "800x600,800x600; 1024x768,NULL; 800x600,NULL; 640x480,NULL" Eine genauere Information über die Konfiguration spezifischer Spiele geht über den Bereich dieses Dokumentes hinaus, die obigen Beispiele gekoppelt mit zahlreichen Onlinequellen sollten aber ausreichen, Ihnen eine gewisse "Starthilfe" zu geben. __________________________________________________________________________ (Anhang J) ANHANG J: TV-OUT KONFIGURIEREN __________________________________________________________________________ Grafikkarten auf Basis einer NVIDIA-GPU mit TV-Out- (S-Video)-Buchse können eingesetzt werden, um einen Fernseher genau wie einen normalen Monitor oder einen digitalen Flachbildschirm zu nutzen. Der Fernseher kann (auf geeigneten Videokarten) in Verbindung mit einem weiteren Anzeigegerät in einer TwinView Konfiguration genutzt werden. Ist der Fernseher das einzige mit Ihrer Grafikkarte verbundene Gerät, so wird er als primäres Anzeigegerät benutzt, wenn Sie Ihr System starten (d. h. die Konsole erscheint auf dem Fernseher, als sei er ein normaler Monitor). Wenn Sie Ihren Fernseher zusammen mit X nutzen, gibt es einige Parameter in Ihrer X-Konfigurationsdatei, denen Sie besondere Aufmerksamkeit widmen sollten. o Die Werte VertRefresh und HorizSync im Abschnitt "Monitor"; bitte achten Sie darauf, dass diese für Ihren Fernseher geeignet sind. Die Werte sind im Allgemeinen: HorizSync 30-50 VertRefresh 60 o Die Modi im Abschnitt "Screen"; die gültigen Modi für Ihren TV-Encoder stehen in der X-Logfile, wenn diese im Verbose-Modus (mit 'startx -- -logverbose 5') erzeugt wird und X auf dem Fernseher läuft. Einige Modi sind eventuell auf bestimmte Fernsehstandards beschränkt; sollte dies der Fall sein, wird Ihnen dies in der X-Logfile mitgeteilt. Üblicherweise werden zumindest 800x600 und 640x480 unterstützt. o Die Option "TVStandard" sollte dem Abschnitt "Screen" hinzugefügt werden; gültige Werte sind: "PAL-B" : eingesetzt in Belgien, Dänemark, Finnland, Deutschland, Guinea, Hongkong, Indien, Indonesien, Italien, Malaysia, den Niederlanden, Norwegen, Portugal, Singapur, Spanien, Schweden und der Schweiz "PAL-D" : eingesetzt in China und Nordkorea "PAL-G" : eingesetzt in Dänemark, Finnland, Deutschland, Italien, Malaysia, den Niederlanden, Norwegen, Portugal, Spanien, Schweden und der Schweiz "PAL-H" : eingesetzt in Belgien "PAL-I" : eingesetzt in Hongkong und dem Vereinigten Königreich "PAL-K1" : eingesetzt in Guinea "PAL-M" : eingesetzt in Brasilien "PAL-N" : eingesetzt in Frankreich, Paraguay und Uruguay "PAL-NC" : eingesetzt in Argentinien "NTSC-J" : eingesetzt in Japan "NTSC-M" : eingesetzt in Kanada, Chile, Kolumbien, Costa Rica, Ecuador, Haiti, Honduras, Mexiko, Panama, Puerto Rico, Südkorea, Taiwan, den Vereinigten Staaten von Amerika und Venezuela "HD480i" : 480 Zeilen, Halbbildverfahren (interlaced) "HD480p" : 480 Zeilen, Vollbildverfahren (progressive) "HD720p" : 720 Zeilen, Vollbildverfahren (progressive) "HD1080i": 1080 Zeilen, Halbbildverfahren (interlaced) "HD1080p": 1080 Zeilen, Vollbildverfahren (progressive) "HD576i" : 576 Zeilen, Halbbildverfahren (interlaced) "HD576p" : 576 Zeilen, Vollbildverfahren (progressive) Die Zeile in Ihrer X-Konfigurationsdatei sollte etwa wie folgt aussehen: Option "TVStandard" "NTSC-M" Wenn Sie keinen TVStandard festlegen oder einen ungültigen Wert eingeben, wird der Standard "NTSC-M" verwendet. Bitte beachten Sie: sollte das Land, in dem Sie leben, nicht in der obigen Liste enthalten sein, suchen Sie bitte das Land aus, das am nächsten zu Ihnen gelegen ist. o Die Option "ConnectedMonitor" (angeschlossener Monitor) kann verwendet werden, um X anzuweisen, den Fernseher als Bildschirm zu verwenden. Das sollte nur dann erforderlich sein, wenn Ihr Fernseher nicht von der Grafikkarte erkannt wird oder Sie einen normalen Monitor (oder digitalen Flachbildschirm) nutzen, X jedoch die Anweisung geben wollen, den Fernseher zu verwenden. Die Zeile in Ihrer Config-Datei sollte wie folgt lauten: Option "ConnectedMonitor" "TV" o Die Option "TVOutFormat" kann genutzt werden, um eine SVIDEO- oder COMPOSITE-Ausgabe zu erzwingen. Ohne diese Option erkennt der Treiber das Ausgabeformat automatisch. Leider gelingt dies nicht immer richtig. Das Ausgabeformat kann dann mit den folgenden Optionen erzwungen werden: Option "TVOutFormat" "SVIDEO" oder Option "TVOutFormat" "COMPOSITE" o Mit der Option "TVOverScan" kann, falls unterstützt, Overscan aktiviert werden. Zulässig sind Dezimalwerte zwischen 1.0 (maximaler Overscan: das Bild wird so groß wie möglich) und 0.0 (kein Overscan: das Bild wird so klein wie möglich). Standardmäßig ist Overscan deaktiviert (0.0). Overscan ist momentan nur auf dem GeForce4 oder neueren GPUs in Verbindung mit einem TV-Encoder von NVIDIA oder Conexant möglich. Wenn Sie eine frühere XFree86-Version als 4.3 verwenden und eine Konsole auf einem Fernsehgerät betreiben, so kann der NVIDIA X-Treiber die Konsole unter Umständen nicht ordnungsgemäß wiederherstellen. Grund hierfür ist eine Binärinkompatibilität der Int10-Module von XFree86. Wenn Sie also eine Konsole auf einem Fernsehgerät betreiben möchten, sollten Sie ein Upgrade auf XFree86 4.3 durchführen. __________________________________________________________________________ (Anhang K) ANHANG K: KONFIGURIEREN EINES LAPTOPS __________________________________________________________________________ INSTALLATION UND KONFIGURATION Die Installation und Konfiguration des NVIDIA Accelerated Linux Driver Set unterscheidet sich im Wesentlichen nicht von der Installation in einer Desktop-Umgebung. Es gibt allerdings einige kleine Unterschiede, die im Folgenden beschrieben werden. Ab der Version 1.0-2802 werden die Informationen zum integrierten LCD- Bildschirm, die zur Initialisierung benötigt werden, standardmäßig bei Bedarf aus den im Grafik-BIOS abgelegten Daten erzeugt. Dieses Verhalten kann unterbunden werden, indem die Kerneloption "SoftEDIDs" auf 0 gesetzt wird. Ist "SoftEDIDs" deaktiviert, so werden anhand des Werts der Kerneloption "Mobile" fixe Daten aus einer Tabelle ausgewählt. Die Kerneloption "Mobile" kann auf einen der folgenden Werte gesetzt werden: 0xFFFFFFFF : Automatische Erkennung des korrekten Werts durch das Kernelmodul 1 : Dell-Laptops 2 : Toshiba-Laptops außer Compal 3 : alle sonstigen Laptops 4 : Compal-Toshiba-Laptops 5 : Gateway-Laptops Wie schon gesagt ist die Kerneloption "Mobile" nur erforderlich, wenn "SoftEDIDs" deaktiviert ist; muss sie verwendet werden, so ist es im Allgemeinen am sichersten, den Kernel den korrekten Wert erkennen zu lassen (was dem Standardverhalten entspricht). Wenn Sie eine dieser Optionen ändern müssen, können Sie dies auf eine der folgenden Arten erledigen: o Sie bearbeiten die Datei os-registry.c im Verzeichnis usr/src/nv/ der .run-Datei. o Sie setzen den Wert über die modprobe-Befehlszeile (z. B. 'modprobe nvidia NVreg_SoftEDIDs=0 NVreg_Mobile=3'). o Sie fügen Ihrer Modulkonfigurationsdatei (üblicherweise /etc/modules.conf) eine "options"-Zeile hinzu (z. B.: "options nvidia NVreg_Mobile=5"). WEITERE FUNKTIONEN TWINVIEW Alle NVIDIA-Mobilchipsätze unterstützen TwinView. TwinView kann auf einem Laptop genauso wie auf einem Desktop-Computer konfiguriert werden (siehe Anhang I weiter oben); bitte beachten Sie, dass in einer Notebook- Konfiguration, die den internen Flachbildschirm des Laptops und einen externen Monitor nutzt, der Monitor das primäre Anzeigegerät ist (geben Sie HorizSync und VertRefresh im Abschnitt "Monitor" Ihrer X-Konfigurationsdatei an) und der Flachbildschirm das sekundäre Anzeigegerät (geben Sie HorizSync und VertRefresh über die Optionen SecondMonitorHorizSync und SecondMonitorVertRefresh an). Darüber hinaus können Sie die Option UseEdidFreqs nutzen, um die Angaben zu HorizSync und VertRefresh aus den EDID jedes Anzeigegerätes auszulesen. Auf diese Weise müssen Sie sich keine Gedanken machen, wie diese in Ihrer X-Konfigurationsdatei gesetzt werden können. (Dies sollte aber nur dann geschehen, wenn Sie den von Ihrem Bildschirm gemeldeten EDIDs vertrauen -- weitere Details erhalten Sie in der Beschreibung der Option UseEdidFreqs in ANHANG D). UMSCHALTEN ZWISCHEN ANZEIGEGERÄTEN MITTELS HOTKEY Abgesehen von TwinView können mobile NVIDIA-Chips auch auf einen LCD/CRT- Hotkey-Event reagieren, um zwischen den angeschlossenen Anzeigegeräten und jeder möglichen Kombination der angeschlossenen Anzeigegeräte hin- und herzuschalten (bitte beachten Sie, dass nur zwei Geräte gleichzeitig aktiv sein können). Die Konfiguration von TwinView in Ihrer X-Konfigurationsdatei und die Hotkeyfunktion schließen sich gegenseitig aus - wenn Sie TwinView in Ihrer X-Konfigurationsdatei aktivieren, ignoriert der NVIDIA X-Treiber die LCD/CRT-Hotkey-Events. Ein weiterer wichtiger Aspekt der Hotkeyfunktion ist die Möglichkeit, Anzeigegeräte dynamisch mit dem Laptop zu verbinden und von diesem entfernen zu können und dann per Hotkey zu ihnen zu wechseln, ohne X neu zu starten. Ein wichtiger Punkt ist die Bestätigung und Festlegung der auf jedem Anzeigegerät zu programmierenden Modi. Es ist zunächst einmal äußerst hilfreich, UseEdidFreqs zu verwenden, so dass Hsync und Vrefresh für jedes Gerät aus den EDID gezogen werden können - die Semantik über die Bedeutung der Inhalte des Abschnitts "Monitor" verändert sich sonst mit jedem Hotkey- Event. Sobald X gestartet wird oder eine Veränderung in der Liste der angeschlossenen Anzeigegeräte auftritt, wird eine neue Hotkey-Sequenz konstruiert - in dieser Sequenz wird aufgeführt, welche Anzeigegeräte bei jedem Hotkey-Event eingesetzt werden. Tritt ein Hotkey-Event ein, wird der nächste Hotkey-Status in der Sequenz ausgewählt. Jeder Modus, der in der X-Konfigurationsdatei angefragt wird, wird in Anbetracht der Grenzbedingungen jedes Anzeigegerätes bestätigt und die resultierenden Modi werden für das entsprechende Anzeigegerät zur Verfügung gestellt. Sollen mehrere Bildschirme gleichzeitig aktiv sein, werden die Modi der einzelnen Anzeigegeräte paarweise abgeglichen. Kann keine genaue Übereinstimmung gefunden werden (gleiche Auflösung), wird das nächstgelegene Element gefunden und das Anzeigegerät mit der geringeren Auflösung wird in der Auflösung des anderen Anzeigegerätes verschoben. Erfolgt vt-Switching außerhalb von X, wird die VGA-Konsole immmer auf dem Anzeigegerät wiederhergestellt, auf der sie beim X-Start vorhanden war. Erfolgt vt-Switching wieder zurück zu X, wird die gleiche Anzeigegerätekonfiguration genutzt, die beim Verlassen von X verwendet wurde - unabhängig davon, welche Hotkeyaktivitäten in der Zwischenzeit erfolgt sind. SONDERMODI AUF LCD-DISPLAYS Einige Benutzer hatten Probleme, den Modus 1400x1050 zu programmieren (die native Auflösung einiger Laptop-LCDs). In der Version 4.0.3 wurden der Datenbank der Standardmodi von XFree86 mehrere 1400x1050-Modi hinzugefügt. Nachfolgend finden Sie eine Moduszeile, die Sie verwenden können, wenn Sie eine ältere Version von XFree86 verwenden: # -- 1400x1050 -- # 1400x1050 @ 60Hz, 65.8 kHz hsync Modeline "1400x1050" 129 1400 1464 1656 1960 1050 1051 1054 1100 +HSync +VSync BEKANNTE PROBLEME IM ZUSAMMENHANG MIT LAPTOPS o LCD/CRT-Hotkey-Umschaltung funktioniert gegenwärtig nicht auf Toshiba-Laptops der Satellite 2800-Reihe. o TwinView funktioniert gegenwärtig nicht auf Toshiba-Laptops der Satellite 2800-Reihe. o Der Video-Overlay funktioniert nur auf dem ersten Anzeigegerät, auf dem X gestartet wird. Wird X zum Beispiel auf dem internen LCD gestartet und Sie starten zunächst eine Videoanwendung, die Video-Overlay verwendet (über den "Video Overlay"-Adapter, der durch die XV-Erweiterung bereitgestellt wird) und schalten dann per Hotkey ein zweites Anzeigegerät hinzu, so wird das Video nicht auf dem zweiten Anzeigegerät erscheinen. Um dies zu umgehen, können Sie entweder die Videoanwendung so konfigurieren, dass sie den "Video Blitter"-Adapter verwendet, der durch die XV-Erweiterung bereitgestellt wird (diese Option ist immer verfügbar), oder vor dem Start von X per Hotkey zu dem Anzeigegerät wechseln, auf dem Sie das Video-Overlay nutzen wollen. __________________________________________________________________________ (Anhang L) ANHANG L: PROGRAMMIEREN VON MODI __________________________________________________________________________ Das Accelerated Linux Driver Set von NVIDIA unterstützt alle Standard-VGA- und VESA-Modi und darüber hinaus die meisten benutzerdefinierten Moduszeilen für Sondermodi; Dualscan-Modi werden auf der gesamten Hardware unterstützt. Interlaced-Modi werden auf allen Grafikprozessoren ab dem GeForce FX/Quadro FX sowie auf bestimmten älteren Modellen unterstützt. Ob die Interlaced-Modi unterstützt werden, lässt sich der X-Logfile entnehmen; wenn Unterstützung vorhanden ist, enthält diese den Eintrag "Interlaced video modes are supported on this GPU". Im Allgemeinen wird das Anzeigegerät (Monitor/Flachbild/Fernseher) engere Beschränkungen hinsichtlich der verwendbaren Modi aufweisen als Ihre Grafikkarte mit NVIDIA Grafikchip bzw. das Accelerated Linux Driver Set von NVIDIA. Um einen oder mehrere Standardmodi zur Verwendung in X anzufordern, können Sie dem entsprechenden "Display"-Unterabschnitt Ihrer X-Konfigurationsdatei ganz einfach eine "Modes"-Zeile wie die folgende hinzufügen: Modes "1600x1200" "1024x768" "640x480" (Details hierzu finden Sie auf der Man-Page XF86Config(4/5) bzw. xorg.conf(5x).) Die folgenden Ausführungen sind primär dann von Interesse, wenn Sie Ihre eigenen angepassten Moduszeilen erstellen, mit xvidtune(1) experimentieren oder ganz einfach daran interessiert sind, mehr zu erfahren. Bitte beachten Sie, dass diese Ausführungen weder eine Erklärung noch eine Richtlinie für die hohe Kunst des Erstellens von angepassten Moduszeilen für X sind. Wir überlassen diese detaillierten Beschreibungen Dokumentationen wie dem XFree86 Video Timings HOWTO (das unter www.tldp.org gefunden werden kann). FARBTIEFE, BIT PRO PIXEL UND PITCH Obwohl sie bei der Programmierung von Modi nicht direkt relevant sind, sind die pro Pixel verwendeten Bits bei der Berücksichtigung der maximal programmierbaren Auflösung ein Thema; aus diesem Grunde ist es sinnvoll, auf die Begriffe "Farbtiefe" ("depth") und "Bit pro Pixel" ("bits per pixel", bpp) einzugehen. Die Farbtiefe gibt an, wie viele Datenbits pro Pixel gespeichert werden. Unterstützte Farbtiefen sind 8, 15, 16 und 24. Die meisten Grafikhardwaregeräte speichern die Pixeldaten jedoch in jeweils 8, 16 oder 32 Bit; dies ist die Speichermenge, die pro Pixel zugewiesen wird. Wenn Sie die Farbtiefe angeben, wählt X die Bit pro Pixel (bpp)- Größe, in der die Daten gespeichert werden sollen. Nachfolgend finden Sie eine Tabelle, wie viele bpp für jede mögliche Farbtiefe verwendet werden. Tiefe bpp ===== ===== 8 8 15 16 16 16 24 32 Der "Pitch" (Abstand) gibt an, wie viele Byte im linearen Framebuffer zwischen den Daten eines Pixels und den Daten des nächsten direkt darunterliegenden Pixels liegen. Sie können sich diesen Wert als horizontale Auflösung multipliziert mit den Byte pro Pixel (Bit pro Pixel geteilt durch 8) vorstellen. In der Praxis kann der Pitch mehr als dieses Produkt sein, da die Grafikhardware hier oftmals organisatorische Beschränkungen auferlegt. MAXIMALE AUFLÖSUNGEN Das Accelerated Linux Driver Set von NVIDIA und Grafikkarten auf Basis von NVIDIA-GPUs unterstützen Auflösungen bis zu 2048x1536. Dabei ist jedoch zu beachten, dass die maximal durch Ihr System unterstützte Auflösung auch durch die Größe des Grafikspeichers (Details finden Sie in NÜTZLICHE FORMELN) und der maximal durch Ihr Anzeigegerät (Monitor/Flachbildschirm/ Fernseher) unterstützten Auflösung beschränkt ist. Bitte beachten Sie auch, dass die Verwendung eines Video-Overlays die maximale Auflösung oder die Bildwiederholfrequenz zwar nicht einschränkt; die Video-Speicherbandbreite, die von einem programmierten Modus verwendet wird, wirkt sich jedoch sehr wohl auf die Qualität des Overlays aus. NÜTZLICHE FORMELN Die maximale Auflösung ist sowohl eine Funktion der Grafikspeichermenge als auch der Bit pro Pixel, die Sie zur Verwendung auswählen: HA * VA * (bpp/8) = verwendeter Videospeicher Mit anderen Worten entspricht die Menge des verwendeten Videospeichers der horizontalen Auflösung (HA) multipliziert mit der vertikalen Auflösung (VA) multipliziert mit den Byte pro Pixel (Bit pro Pixel geteilt durch 8). Technisch gesehen stellt der verwendete Videospeicher tatsächlich den Pitch multipliziert mit der vertikalen Auflösung dar; der Pitch kann dabei geringfügig größer als (HA * (bpp/8)) sein, um ggf. Hardwareanforderungen zu entsprechen, dass der Pitch stets ein Vielfaches eines bestimmten Wertes sei. Bitte beachten Sie, dass dies nur die Speicherverwendung für den Framebuffer darstellt; der Grafikspeicher wird auch noch für andere Zwecke wie OpenGL oder Pixmap-Caching verwendet. Eine weitere wichtige Beziehung besteht zwischen der Auflösung, dem Pixeltakt (alias Punkttakt) und der vertikalen Bildwiederholfrequenz: WF = PT / (HFL * VFL) In anderen Worten ist die Bildwiederholfrequenz (WF) gleich dem Pixeltakt (PT) geteilt durch die Gesamtzahl der Pixel: die horizontale Framelänge (HFL) multipliziert mit der vertikalen Framelänge (VFL). Bitte beachten Sie, dass dies die Framelängen und nicht unbedingt nur die sichtbaren Auflösungen sind. Wie im XFree86 Video Timings HOWTO beschrieben, kann die obige Formel wie folgt umgeschrieben werden: PT = WF * HFL * VFL Sie können bei einem gegebenen maximalen Pixeltakt die WF, HFL und VFL wie gewünscht anpassen, solange das Produkt der drei konstant ist. Der Pixeltakt ist in der Logdatei aufgeführt, wenn Sie X mit Verbose-Logging ausführen: 'startx -- -logverbose 5'. Ihre X-Logfile sollte mehrere Zeilen wie etwa die folgenden enthalten: (--) NVIDIA(0): Display Device 0: maximum pixel clock at 8 bpp: 350 MHz (--) NVIDIA(0): Display Device 0: maximum pixel clock at 16 bpp: 350 MHz (--) NVIDIA(0): Display Device 0: maximum pixel clock at 32 bpp: 300 MHz welche den maximalen Pixeltakt bei jeder bpp-Größe anzeigen. BESTÄTIGEN VON MODI Während der Vorinitialisierungs-Phase des X-Servers überprüft der NVIDIA X-Treiber alle angeforderten Modi durch das folgende Procedere: o Feststellen der Schittmenge aus den HorizSync- und VertRefresh- Bereichen, die vom Benutzer in der X-Konfigurationsdatei angegeben wurden, und der Bereiche, die vom Monitor in den EDID (Exteded Display Identification Data - Erweiterte Bildschirm-Identifikationsdaten) gemeldet werden. Dieses Verhalten kann durch die Verwendung der Option "IgnoreEDID" (EDID ignorieren) deaktivert werden. In diesem Fall übernimmt der X-Server blind die vom Benutzer eingegebenen HorizSync- und VertRefresh-Bereiche. o Aufrufen der Hilfsfunktion xf86ValidateModes(), die Modi mit den Namen findet, die der Benutzer in der X-Konfigurationsdatei angegeben hat, und dabei diejenigen Modi entfernt, die ungültige HorizSync-Frequenzen bzw. VertRefresh-Raten, Pixeltakte, die größer sind als der maximale Pixeltakt für die Grafikkarte, oder Auflösungen, die größer sind als die virtuelle Bildschirmgröße (wenn eine virtuelle Bildschirmgröße in der X-Konfigurationsdatei festgelegt wurde), aufweisen. Es werden mehrere Grenzbedingungen eingesetzt; siehe: xc/programs/Xserver/hw/xfree86/common/xf86Mode.c:xf86ValidateModes(). o Alle von xf86ValidateModes() zurückgegebenen Modi werden dann überprüft, um sicherzustellen, dass ihre Auflösungen nicht höher sind als der größte Modus, der von den EDID gemeldet wird (dies kann durch die Option "IgnoreEDID" deaktiviert werden. Wenn der Bildschirm ein Fernseher ist, wird jeder Modus überprüft, um sicherzustellen, dass die Auflösung vom TV-Encoder unterstützt wird (in der Regel werden nur 800x600 und 640x480 vom Encoder unterstützt). o Daraufhin werden alle Modi überprüft, um zu bestätigen, dass sie innerhalb der Hardwarebeschränkungen für die Speicherbandbreite liegen. Dieser Test kann mit der X-Konfigurationsoption NoBandWidthTest deaktiviert werden. o Alle verbleibenden Modi werden dann überprüft, damit sichergestellt ist, dass sie die weiter unten in WEITERE MODUS-GRENZBEDINUNGEN beschriebenen Grenzbedingungen einhalten. Die letzten drei Schritte werden auch durchgeführt, wenn jeder einzelne Modus programmiert wird, damit potentiell falsche Modi vermieden werden, die durch die XF86VidModeExtension (z.B. xvidtune(1)) eingebracht werden. Für TwinView wird die obige Bestätigung für die von jedem einzelnen Anzeigegerät angeforderten Modi durchgeführt. WEITERE MODUS-GRENZBEDINGUNGEN Nachfolgend finden Sie eine Liste weiterer Grenzbedingungen für die Modusparameter, die eingehalten werden müssen. o Die horizontale Auflösung (HA) muss ein Vielfaches von 8 und kleiner oder gleich den Werten aus der unten stehenden Tabelle sein. o Die horizontale Breite der Austastung (das Maximum der horizontalen Framelänge und des Horizontal Sync End minus dem Minimum der horizontalen Auflösung und des Horizontal Sync Start (max(HFL,HSE) - min(HR,HSS)) muss ein Vielfaches von 8 und kleiner oder gleich den Werten aus der unten stehenden Tabelle sein. o Der Horizontal Sync Start (HSS) muss ein Vielfaches von 8 und kleiner oder gleich den Werten aus der unten stehenden Tabelle sein. o Die Horizontal Sync Width (Horizontal Sync End minus Horizontal Sync Start (HSE-HSS)) muss ein Vielfaches von 8 und kleiner oder gleich den Werten aus der unten stehenden Tabelle sein. o Die horizontale Framelänge (HFL) muss ein Vielfaches von 8, größer oder gleich 40 sowie kleiner oder gleich den Werten aus der unten stehenden Tabelle sein. o Die vertikale Auflösung (VA) muss kleiner oder gleich den Werten aus der unten stehenden Tabelle sein. o Die vertikale Breite der Austastung (das Maximum der vertikalen Framelänge und des Vertical Sync End minus dem Minimum der vertikalen Auflösung und der Vertical Sync Start (max(VFL,VSE) - min(VR,VSS)) muss kleiner oder gleich den Werten aus der unten stehenden Tabelle sein. o Der Vertical Sync Start (VSS) muss kleiner oder gleich den Werten aus der unten stehenden Tabelle sein. o Die Vertical Sync Width (Vertical Sync End minus Vertical Sync Start (VSE - VSS)) muss kleiner oder gleich den Werten aus der unten stehenden Tabelle sein. o Die vertikale Framelänge (VFL) muss größer oder gleich 2 sowie kleiner oder gleich den Werten aus der unten stehenden Tabelle sein. Maximale DAC-Werte ------------------ | GeForce/TNT Geforce2 & 3 Geforce4 oder neuer ______|_________________________________________________ | HA | 4096 4096 8192 HBA | 1016 1016 2040 HSS | 4088 4088 8224 HSW | 256 256 512 HFL | 4128 4128 8224 VA | 2048 4096 8192 VBA | 128 128 256 VSS | 2047 4095 8192 VSW | 16 16 16 VFL | 2049 4097 8192 Nachstehend finden Sie eine Beispielzeile, welche die Verwendung jeder der oben verwendeten Abkürzungen demonstriert: # Eigene Moduszeile für den SGI 1600SW-Flachbildschirm # Name PT HA HSS HSE HFL VA VSS VSE VFL Modeline "sgi1600x1024" 106.9 1600 1632 1656 1672 1024 1027 1030 1067 ANGLEICHEN DER MODUS-TIMINGEINSTELLUNGEN Einige Funktionen wie z. B. die Kombination aus aktiver Stereoanzeige und TwinView stellen etwas höhere Anforderungen an die genauen Modus- Timingeinstellungen. Hierfür gibt es mehrere Möglichkeiten: o Wenn Sie nur sicherstellen möchten, dass beide Anzeigegeräte dieselben Modi verwenden, müssen Sie bei der Modus-Validierung lediglich darauf achten, dass beide dieselben HorizSync- und VertRefresh-Werte verwenden. Die Werte für HorizSync und SecondMonitorHorizSync müssen also ebenso wie die Werte für VertRefresh und SecondMonitorVertRefresh jeweils übereinstimmen. o Zur genaueren Definition können Sie auch explizit die gewünschte Moduszeile angeben und diese mit einem eindeutigen Namen versehen. (Bei der Erstellung der Moduszeile kann einer der verschiedenen im Internet verfügbaren Moduszeilengeneratoren hilfreich sein.) Wenn Sie beispielsweise im TwinView-Modus und mit aktiver Stereoanzeige auf beiden Monitoren eine Auflösung von 1024x768 bei 120 Hz verwenden möchten, könnte die Moduszeile wie folgt aussehen: # 1024x768 @ 120.00 Hz (GTF) hsync: 98.76 kHz; pclk: 139.05 MHz Modeline "1024x768_120" 139.05 1024 1104 1216 1408 768 769 772 823 -HSync +Vsync Im Monitor- und Screen-Abschnitt Ihrer X-Konfigurationsdatei würden Sie anschließend einen MetaMode wie den folgenden definieren: Option "MetaModes" "1024x768_120, 1024x768_120" SIEHE AUCH: Einen XFree86-Moduszeilengenerator, der dem GTF-Standard entspricht, finden Sie hier: http://gtf.sourceforge.net/ Eine Suche nach weiteren Moduszeilengeneratoren ist mit dem Suchbegriff "modeline" auf freshmeat.net möglich. __________________________________________________________________________ (Anhang M) ANHANG M: FLIPPING UND UBB __________________________________________________________________________ Das Accelerated Linux Driver Set von NVIDIA unterstützt UBB (Unified Back Buffer - Einheitlicher Back Buffer) sowie OpenGL-Flipping. In bestimmten Situationen können diese Leistungsmerkmale zu Performancesteigerungen führen. o Unified Back Buffer (UBB - Einheitlicher Back Buffer): UBB ist nur auf GPUs der Quadro-Familie (außer Quadro4 NVS) verfügbar und wird standardmäßig aktiviert, wenn ausreichend Grafikspeicher zur Verfügung steht. Dies kann mit der in Anhang D beschriebenen X-Konfigurationsoption "UBB" deaktiviert werden. Sobald UBB aktiviert ist, teilen sich alle Fenster den gleichen Back, Stencil und Depth Buffer. Sind viele Fenster geöffnet, überschreitet die Back-, Stencil- und Depth-Nutzung niemals die von einem Vollbildfenster genutzte Größe. Allerdings entspricht die Back-, Stencil- und Depth-Nutzung selbst bei einem einzelnen kleinen Fenster der eines Vollbildfensters, sodass in diesem Fall der Grafikspeicher eventuell weniger effizient genutzt wird als ohne UBB. o Flipping: Bei aktiviertem OpenGL-Flipping kann OpenGL Buffer-Swaps sehr effizient durchführen, indem einfach der vom DAC ausgelesene Puffer gewechselt wird. Somit muss der Inhalt des Back Buffer nicht in den Front Buffer kopiert werden, was zu deutlich höherer Performance führt und verlustfreies Swappen während des Strahlrücklaufs ermöglicht (wenn __GL_SYNC_TO_VBLANK gesetzt ist). Die Bedingungen, unter denen OpenGL-Flipping möglich ist, gestalten sich grob vereinfacht gesagt wie folgt: Auf GeForce- Grafikhardware und neueren Modellen ist Flipping für einzelne OpenGL-Anwendungen möglich, die im Vollbildmodus laufen und nicht von anderen Fenstern überlagert werden; zudem muss __GL_SYNC_TO_VBLANK aktiviert sein. Auf Quadro-Hardware ist Flipping darüber hinaus auch möglich, wenn das OpenGL-Fenster teilweise überlagert wird, nicht im Vollbildmodus läuft oder wenn __GL_SYNC_TO_VBLANK nicht gesetzt ist. __________________________________________________________________________ (Anhang N) ANHANG N: BEKANNTE PROBLEME __________________________________________________________________________ Die folgenden Probleme liegen in dieser Version noch vor und werden momentan behoben. o OpenGL + Xinerama Gegenwärtig kann OpenGL Inhalte in einer Xinerama-Umgebung nur auf dem ersten Bildschirm anzeigen. o OpenGL und dlopen() Es existieren einige Problemfälle mit älteren Versionen des dynamischen Laders glibc (zum Beispiel die Version, die mit RedHat 7.2 ausgeliefert wird) und Anwendungen wie Quake3 und Radiant, die dlopen() verwenden. Weitere Details finden Sie im Abschnitt FAQs - HÄUFIG GESTELLTE FRAGEN. o DPMS und TwinView Die DPMS-Modi "Supend" und "Standby" arbeiten bei der Verwendung von TwinView auf einem zweiten Monitor nicht korrekt. Es erscheint ein leerer Bildschirm, der Monitor wird nicht in den angeforderten DPMS-Status gesetzt. o DPMS mit Flachbildschirm Die DPMS-Modi "Suspend" und "Standby" arbeiten auf Flachbildschirmen nicht ordnungsgemäß. Es erscheint ein leerer Bildschirm, der Flachbildschirm wird nicht in den angeforderten DPMS-Status gesetzt. o Multicard, Multimonitor In einigen Fällen wird die sekundäre Karte nicht korrekt durch das NVIDIA-Kernelmodul initialisiert. Sie können dies durch die Aktivierung des Xfree86-Int10-Moduls umgehen, damit alle sekundären Karten warmgestartet werden. Weitere Details siehe ANHANG D: X-KONFIGURATIONSOPTIONEN. o Laptop Wenn Sie einen Laptop verwenden, lesen Sie bitte die "BEKANNTEN PROBLEME IM ZUSAMMENHANG MIT LAPTOPS" in Anhang D. o FSAA (Vollbild-Antialiasing) Bei aktiviertem FSAA (die Umgebungsvariable __GL_FSAA_MODE ist auf einen Wert gesetzt, der FSAA aktiviert, und es ist eine Multisample- Anzeigeart ausgewählt) können Renderingfehler auftreten, wenn das Fenster skaliert wird. o Interaktion mit pthreads Single-threaded-Anwendungen, die die NVIDIA-libGL-Bibliothek mit dlopen() öffnen und danach eine andere Bibliothek öffnen, die mit pthreads verknüpft ist, erzeugen damit einen Absturz der NVIDIA- libGL-Bibliothek. In den neuen ELF TLS-OpenGL-Bibliotheken von NVIDIA tritt dieses Problem nicht mehr auf (eine Beschreibung der ELF TLS-OpenGL-Bibliotheken finden Sie in (Anhang C) ANHANG C: INSTALLIERTE KOMPONENTEN). Um dieses Problem zu umgehen, bestehen folgende Möglichkeiten: 1) Laden Sie die mit pthreads verknüpfte Bibliothek vor libGL.so. 2) Verknüpfen Sie die Anwendung mit pthreads. HARDWARE-PROBLEME Dieser Abschnitt beschreibt Problemfälle, die nicht behoben werden. In der Regel liegt die Ursache des Problems nicht im Einflussbereich von NVIDIA. Nachfolgend finden Sie eine Liste der Probleme: o Gigabyte GA-6BX Motherboard Dieses Motherbord verwendet einen LinFinity-Regler auf der 3,3V- Rail, der nur für 5 A ausgelegt ist - dies liegt unter der AGP- Spezifikation, die 6 A erfordert. Wenn Diagnoseprogramme oder Anwendungen ausgeführt werden, steigt die Temperatur des Reglers, wodurch die Spannung auf dem NVIDIA-Chip auf bis zu 2,2 V sinkt. Under diesen Umständen ist der Regler nicht in der Lage, auf der 3,3V-Rail den Strom zu liefern, den der NVIDIA-Chip erfordert. Dieses Problem entsteht nicht, wenn die Grafikkarte über einen Schaltregler verfügt oder eine externe Stromversorgung mit der 3,3V-Rail verbunden ist. o VIA KX133 und 694X Chipsätze mit AGP 2x Auf Athlon-Motherboards mit dem VIA KX133- oder 694X-Chipsatz (z. B. das ASUS K7V-Motherboard) setzen die NVIDIA-Treiber den AGP 2x-Modus als Standard, um eine unzureichende Stärke eines der Signale zu umgehen. o Irongate Chipsätze mit AGP 1x Auf Athlon-Motherboards mit dem Irongate-Chipsatz werden AGP 1x- Transfers verwendet, um ein Problem mit der Signalintegrität des Chipsatzes zu umgehen. o ALi Chipsätze, ALi1541 und ALi1647 Auf ALi1541- und ALi1647-Chipsätzen deaktivieren die NVIDIA-Treiber AGP, um Probleme mit Timing und Signalintegrität zu umgehen. Weitere Informationen zu ALi-Chipsätzen finden Sie in "ANHANG G: ALI-SPEZIFISCHE PROBLEME". o I/O APIC (SMP) Wenn auf einem Linux-SMP-Rechner Probleme mit der Stabilität auftreten und der Linux-Kernel I/O APIC-Meldungen ausgibt, können Sie die Systemstabilität merklich steigern, indem Sie den Kernelparameter "noapic" setzen. o Local APIC (UP) Auf manchen Systemen kann sich das Setzen der Kernelkonfigurationsoption "Local APIC Support on Uniprocessors" nachteilig auf die Systemstabilität und Performance auswirken. Wenn Sie auf einem Einzelprozessor-Linux-System Probleme mit der Stabilität haben und diese Option gesetzt ist, versuchen Sie einmal, die lokale APIC-Unterstützung zu deaktivieren. __________________________________________________________________________ (Anhang O) ANHANG O: PROC-SCHNITTSTELLE __________________________________________________________________________ Über die /proc-Dateisystemschnittstelle können Sie zur Laufzeit Informationen zum Treiber, den installierten NVIDIA-Grafikkarten sowie dem AGP-Status abfragen. Diese Informationen werden in verschiedenen Dateien in /proc/driver/nvidia abgelegt: o /proc/driver/nvidia/version Enthält die installierte Treiberversion sowie die Version des GNU C-Compilers, mit dem das Linux-Kernelmodul erstellt wurde. o /proc/driver/nvidia/cards/0...3 Liefert Informationen zu allen installierten NVIDIA-Grafikadaptern (Modell, IRQ, BIOS-Version, Bustyp). Bitte beachten Sie, dass die BIOS-Version nur verfügbar ist, solange X läuft. o /proc/driver/nvidia/agp/card Informationen zu den AGP-Fähigkeiten der installierten Karte. o /proc/driver/nvidia/agp/host-bridge Informationen zur Host-Bridge (Modell und AGP-Unterstützung). o /proc/driver/nvidia/agp/status Der aktuelle AGP-Status. Wenn auf Ihrem System die AGP- Unterstützung aktiviert ist, werden hier der verwendete AGP- Treiber, die AGP-Rate sowie Angaben zum Status von AGP Fast Writes und Side Band Addressing (SBA) angezeigt. Der AGP-Treiber ist entweder "NVIDIA" (NVIDIAs eingebauter AGP- Treiber) oder AGPGART (der agpgart.o-Treiber des Linux-Kernels). Wenn neben AGPGART "inactive" steht, so bedeutet dies, dass der AGP-Chipsatz von AGPGART programmiert wurde, jedoch gegenwärtig nicht verwendet wird. SBA und Fast Writes geben an, ob die jeweiligen Funktionen gegenwärtig verwendet werden. Bitte beachten Sie, dass die Unterstützung dieser Funktionen von mehreren Faktoren beeinflusst wird. Zunächst müssen sowohl die AGP-Karte als auch die Host-Bridge die jeweilige Funktion unterstützen. Auch wenn die Unterstützung auf beiden Seiten gegeben ist, kann sich der Treiber immer noch gegen ihre Verwendung entscheiden, um eine höhere Systemstabilität zu gewährleisten. Dies ist besonders bei AGP Fast Writes der Fall. __________________________________________________________________________ (app-p) APPENDIX P: XVMC-Unterstützung __________________________________________________________________________ Diese Treiberversion beinhaltet Unterstützung für die X-Video Motion Compensation (XvMC)-API Version 1.0 (ausschließlich auf GeForce4- und GeForce FX-basierter Hardware). Es werden eine statische Bibliothek "libXvMCNVIDIA.a" sowie eine für dlopen() geeignete dynamische Bibliothek "libXvMCNVIDIA_dynamic.so" bereitgestellt. Hardware auf Basis des GeForce4 MX oder GeForce FX unterstützt die beiden XvMC-Beschleunigungsebenen "IDCT" und "motion-compensation" gleichermaßen. GeForce4 Ti-basierte Hardware unterstützt nur die Ebene "motion-compensation". AI44- und IA44-Unterbilder werden unterstützt. 4:2:0-Oberflächen werden bis zu 2032x2032 unterstützt. libXvMCNVIDIA beobachtet die Umgebungsvariable XVMC_DEBUG; ist diese auf einen geeigneten Integer-Wert gesetzt, so liefert die Bibliothek gewisse Debug-Informationen an stderr. '0' deaktiviert die Debug-Ausgabe. '1' aktiviert die Debug-Ausgabe für Fehlerbedingungen. '2' oder höher aktiviert die Ausgabe von Warnmeldungen. __________________________________________________________________________ (Anhang Q) ANHANG Q: GLX-UNTERSTÜTZUNG __________________________________________________________________________ Diese Version unterstützt GLX 1.3 mit folgenden Erweiterungen: GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_ARB_get_proc_address Eine Beschreibung dieser Erweiterungen finden Sie in der OpenGL- Erweiterungsregistry unter http://oss.sgi.com/projects/ogl-sample/registry/index.html . Einige der oben angeführten Erweiterungen gehören in GLX 1.3 zur Kernfunktionalität, werden zu Zwecken der Abwärtskompatibilität jedoch als Erweiterungen exportiert. __________________________________________________________________________ (Anhang R) ANHANG R: MEHRERE X-BILDSCHIRME AUF EINER KARTE __________________________________________________________________________ Grafikchips mit TwinView-Unterstützung (siehe (Anhang I) ANHANG I: KONFIGURIEREN VON TWINVIEW) können auch so konfiguriert werden, dass sie jedes angeschlossene Anzeigegerät als separaten X-Bildschirm behandeln. Dieser Ansatz hat gegenüber TwinView zwar einige Nachteile (Fenster können sich nicht über beide X-Bildschirme erstrecken, OpenGL- Hardwarebeschleunigung kann sich nicht über beide Bildschirme erstrecken), er bietet jedoch auch einige Vorteile gegenüber TwinView: o Wenn jedes Anzeigegerät ein eigener X-Bildschirm ist, lassen sich Anzeigeattribute, die für X-Bildschirme einzeln gesetzt werden können, logischerweise auch für die Anzeigegeräte einzeln setzen (z. B. Farbtiefe, Basisfenstergröße usw.) o Hardwarefunktionen, die nur auf einem Anzeigegerät gleichzeitig verwendet können (z. B. Video-Overlays, hardwarebeschleunigte RGB- Overlays) und deren Verwendung daher unter TwinView nicht möglich ist, können bei der Aufteilung in mehrere X-Bildschirme wenigstens auf dem ersten X-Bildschirm genutzt werden. o Die 1-zu-1-Zuordnung von Anzeigegeräten zu X-Bildschirmen kommt dem ursprünglichen Konzept von X näher. Um zwei getrennte X-Bildschirme auf einem Grafikchip zu konfigurieren, müssen Sie folgende Schritte ausführen. Erstellen Sie zunächst zwei getrennte "Device"-Abschnitte, die beide die BusID der zu nutzenden Grafikkarte nennen und den Treiber jeweils als "nvidia" angeben. Weisen Sie jedem dieser Abschnitte dann einen separaten Bildschirm zu: Section "Device" Identifier "nvidia0" Driver "nvidia" # Setzen Sie bei der BusID die entsprechende Angabe für Ihre Karte # ein BusID "PCI:2:0:0" Screen 0 EndSection Section "Device" Identifier "nvidia1" Driver "nvidia" # Setzen Sie bei der BusID die entsprechende Angabe für Ihre Karte # ein BusId "PCI:2:0:0" Screen 1 EndSection Anschließend erstellen Sie zwei "Screen"-Abschnitte, die jeweils einen der "Device"-Abschnitte verwenden: Section "Screen" Identifier "Screen0" Device "nvidia0" Monitor "Monitor0" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1600x1200" "1024x768" "800x600" "640x480" EndSubsection EndSection Section "Screen" Identifier "Screen1" Device "nvidia1" Monitor "Monitor1" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1600x1200" "1024x768" "800x600" "640x480" EndSubsection EndSection (Hinweis: Sie müssen auch einen zweiten "Monitor"-Abschnitt anlegen) Aktualisieren Sie schließlich den Abschnitt "ServerLayout", sodass beide "Screen"-Abschnitte verwendet und positioniert werden: Section "ServerLayout" ... Screen 0 "Screen0" Screen 1 "Screen1" leftOf "Screen0" ... EndSection Nähere Informationen finden Sie in den Manpages XF86Config(5x) bzw. xorg.conf(5x). __________________________________________________________________________ (Anhang S) ANHANG S: UNTERSTÜTZUNG FÜR ENERGIESPARFUNKTIONEN __________________________________________________________________________ Diese Treiberversion unterstützt APM-basierte Energiesparfunktionen sowie eine erste Unterstützung für ACPI. Konkret bedeutet dies, dass der Treiber Suspend-, Resume- und Standby-Funktionen unterstützt. Bitte beachten Sie, dass ACPI erst ab der Kernelversion 2.6 unterstützt wird. Erst das in der Version 2.6 eingeführte neuen Treibermodell unterstützt Suspend/Resume nach ACPI vollständig. Nähere Informationen zur Einrichtung und Nutzung der Energiemanagement- Funktionen Ihres Systems entnehmen Sie bitte der Begleitdokumentation Ihrer Distribution. In manchen Fällen kann es vorkommen, dass die AGP-Konfiguration des Systemchipsatzes beim Eintritt in den Suspend-Modus verloren geht. Nach dem Resume können dann Probleme mit dem Busbetrieb auftreten. Auf diesen Systemen muss der AGP-Treiber die erforderlichen Registerdaten vor dem Eintritt in den Suspend-Modus speichern und später beim Resume wiederherstellen. Der NVIDIA NvAGP-Treiber übernimmt diese Aufgabe automatisch. Der AGPGART-Treiber von Linux 2.4 unterstützt diese Funktion hingegen nicht, der Linux 2.6 AGPGART nur eingeschränkt für einige wenige Chipsätze. Wenn Sie einen dieser Treiber verwenden und Probleme mit den Funktionen Suspend/Resume haben, können Sie versuchsweise einmal den NVIDIA NvAGP- Treiber ausprobieren. Sie können dieses Problem auch umgehen, indem Sie AGP komplett deaktivieren (siehe ANHANG F: AGP KONFIGURIEREN). __________________________________________________________________________ (Anhang T) ANHANG T: ANZEIGEGERÄTENAMEN __________________________________________________________________________ Unter den Begriff "Anzeigegerät" fallen alle Hardwaregeräte zur Grafikanzeige. Dabei lassen sich grob drei Kategorien unterscheiden: analoge Röhrenmonitore (CRT), digitale Flachbildschirme (DFP) und Fernsehgeräte (TV). Analoge Flachbildschirme werden vom Treiber wie ein analoger Röhrenmonitor behandelt. Ein "Anzeigegerätename" ist eine Zeichenfolge, die zur eindeutigen Benennung eines Anzeigegeräts dient. Sie hat das Format "-", also zum Beispiel "CRT-0", "CRT-1", "DFP-0" oder "TV-0". Die Nummer richtet sich dabei nach der internen Schaltung der Bildschirmanschlüsse auf der Grafikkarte. Sie hat also nichts damit zu tun, wie viele Bildschirme tatsächlich angeschlossen sind; Sie können also durchaus ein Anzeigegerät "CRT-1" haben, ohne dass "CRT-0" aktiv ist. Die aktuell angeschlossenen Anzeigegeräte können Sie der X-Logfile entnehmen. Dort finden Sie eine Zeile ähnlich der folgenden: (II) NVIDIA(0): Connected display device(s): CRT-0, DFP-0 Die Anzeigegerätenamen dienen in den X-Konfigurationsoptionen MetaMode, HorizSync und VertRefresh dazu, die Einstellungen den unterschiedlichen Anzeigegeräten zuzuordnen. Dies sieht dann zum Beispiel so aus: Option "MetaModes" "CRT-0: 1600x1200, DFP-0: 1024x768" Option "HorizSync" "CRT-0: 50-110, DFP-0: 40-70" Option "VertRefresh" "CRT-0: 60-120, DFP-0: 60" Die Angabe der Anzeigegerätenamen ist dabei nicht verpflichtend. Wenn kein Gerätename angegeben wird, versucht der Treiber automatisch zu ermitteln, für welches Anzeigegerät die Einstellung gelten soll. Bei der Option "MetaMode" beispielsweise wird dann der erste aufgeführte Modus dem "ersten" Anzeigegerät zugewiesen, der zweite Modus entsprechend dem "zweiten". Allerdings ist oft unklar, welcher Bildschirm nun der "erste" und welcher der "zweite" ist. Daher empfiehlt es sich, stattdessen den Anzeigegerätenamen anzugeben und auf diese Weise Unklarheiten zu vermeiden. Die Angabe der Nummer im Namen kann ebenfalls weggelassen werden. Dies ist natürlich nur dann sinnvoll, wenn nur ein Gerät des betreffenden Typs angeschlossen ist. Wenn beispielsweise ein Monitor (CRT) und ein LCD-Panel (DFP) angeschlossen sind, kann der Verweis im MetaMode wie folgt aussehen: Option "MetaModes" "CRT: 1600x1200, DFP: 1024x768"