README & Installationshinweise für das Accelerated Linux Driver Set von NVIDIA Letztes Update: Datum: 26.11.2001 $ Aktuellster Treiber: 1.0-2313 Das Accelerated Linux Driver Set von NVIDIA bietet für Linux x86 bei Verwendung der Grafikprozessoreinheiten (GPUs) von NVIDIA sowohl eine beschleunigte 2D-Funktionalität, als auch Hochleistungs-OpenGL-Support. Diese Treiber ermöglichen eine optimierte Hardwarebeschleunigung von OpenGL Applikationen über einen Direct Rendering X-Server und unterstützen die folgenden Chipsätze: TNT, TNT2 (M64/Pro/Ultra), GeForce 256, GeForce2 GTS, GeForce2 MX (200/400), GeForce2 Pro, GeForce2 Ti, GeForce 2 Ultra, GeForce2 Go, GeForce3, GeForce3 Ti (200/500), Quadro, Quadro DDC, Quadro2 (MXR/EX), Quadro2 Pro und Quadro2 Go. TwinView, TV-Out und Flachbildschirme werden ebenfalls unterstützt. Diese Datei beschreibt, wie das Accelerated Linux Driver Set von NVIDIA installiert, konfiguriert und eingesetzt wird. Wir haben die Inhalte einiger separater README Dateien in dieses Dokument einbezogen (diese separaten Dateien sind: ALI_USERS_README, TNT_USERS_README, LAPTOP_README, TWINVIEW_README, und TVOUT_README). Diese README Datei erscheint auf der NVIDIA Website und wird mit dem NVIDIA_GLX Paket (installiert in /usr/share/doc/NVIDIA_GLX-1.0/) geliefert. __________________________________________________________________________ INHALT: (Abschnitt 01) WAHL DES GEEIGNETEN NVIDIA PAKETES FÜR IHR SYSTEM (Abschnitt 02) INSTALLIEREN DER NVIDIA_KERNEL UND NVIDIA_GLX PAKETE (Abschnitt 03) EDITIEREN IHRER XF86CONFIG DATEI (Abschnitt 04) PROBLEMBEHANDLUNG (Abschnitt 5) FAQs - HÄUFIG GESTELLTE FRAGEN (Abschnitt 06) KONTAKT (Abschnitt 07) 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: XF86CONFIG OPTIONEN (Anhang E) ANHANG E: EINSTELLUNGSMÖGLICHKEITEN FÜR DIE OPENGL UMGEBUNGSVARIABLE (Anhang F) ANHANG F: AGP KONFIGURIEREN (Anhang G) ANHANG G: ALI SPEZIFISCHE THEMEN (Anhang H) ANHANG H: TNT SPEZIFISCHE THEMEN (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: PROGRAMMIERMODI (Anhang M) ANHANG M: PAGE FLIPPING, WINDOW FLIPPING UND UBB (Anhang N) ANHANG N: BEKANNTE THEMEN Um diese Anweisungen kurz und bündig zu halten werden die meisten Vorbehalte und häufig auftretenden Probleme nicht detailliert in den Installationsanweisungen sondern in der Problembehandlung und in den FAQ Bereichen 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 PAKETES FÜR IHR SYSTEM __________________________________________________________________________ NVIDIA verfügt über ein einheitliches Treiberarchitektur-Modell, d.h. ein Treibersatz kann mit der gesamten unterstützten NVIDIA Hardware verwendet werden. Eine Liste der durch die aktuellen Treiber unterstützten NVIDIA Hardware finden Sie in Anhang A. Das Accelerated Linux Driver Set von NVIDIA besteht aus zwei Paketen, die heruntergeladen und installiert werden müssen: aus dem NVIDIA_GLX Paket, das die OpenGL Bibliotheken und den XFree86 Treiber beinhaltet, und dem NVIDIA_kernel Paket, das das NVDriver Kernelmodul enthält, das vom X-Treiber und den OpenGL Bibliotheken im NVIDIA_GLX Paket benötigt wird (weitere Informationen über die Komponenten jedes einzelnen Pakets erhalten Sie in Anhang C). Es ist wichtig, dass beide Pakete mit übereinstimmenden Versionsnummern installiert werden (z.B. NVIDIA_GLX-0.9-6 soll mit dem NVIDIA_kernel-0.9-6 und nicht dem NVIDIA_kernel-0.9-3 verwendet werden). Die Pakete sind in verschiedenen Formaten erhältlich: RPM, SRPM und Archivdatei. Die Installation jedes einzelnen Pakets wird weiter unten beschrieben. Der Pakettyp hängt vor allem von persönlichen Präferenzen ab; beachten Sie bitte trotzdem, dass die binären RPMs nur für die Verwendung mit dem Kernel, der mit einem speziellen Produkt ausgeliefert wurde, eingesetzt werden dürfen (z.B. NVIDIA_kernel-0.9-6.rh62.i386.rpm soll nur mit dem Uni-Prozessor Kernel verwendet werden, der mit RedHat 6.2 ausgeliefert wird). Wo geeignet, hat NVIDIA separate RPMs für den SMP und den Uni-Prozessor Kernel jedes Produktes mitgeliefert. Wenn Sie Ihren Kernel aktualisiert haben (entweder manuell oder durch ein Produktupgrade) oder keine spezifische NVIDIA_kernel RPM für Ihr Produkt erhältlich ist, verwenden Sie entweder die NVIDIA_kernel SRPM oder die Archivdatei. Dort, wo mehrere Kernels durch den Vertrieb ausgeliefert werden (dies ist häufig bei Uni-Prozessor und SMP Computern der Fall) sind mehrere RPMs erhältlich, d.h.: NVIDIA_kernel-0.9-7.rh62.i386.rpm und NVIDIA_kernel-0.9-7.rh62.smp.i386.rpm. Die NVIDIA_GLX kernel RPM ist jedoch nicht abhängig von der Kernelversion und aus diesem Grunde ist keine SRPM erforderlich. Installieren Sie das NVIDIA _GLX Paket entweder mit einer RPM oder Archivdatei. __________________________________________________________________________ (Abschnitt 02) INSTALLIEREN DER NVIDIA_KERNEL UND NVIDIA_GLX PAKETE __________________________________________________________________________ BEVOR SIE MIT DER INSTALLATION DER TREIBER BEGINNEN Verlassen Sie den X-Server, bevor Sie mit der Installation beginnen. Darüber hinaus ist es empfehlenswert, das Standard Run Level einzustellen, so dass die Konsole bootet, ohne X zu starten (bitte lesen Sie die Dokumentation, die Sie mit Ihrem Linux Produkt erhalten haben, wenn Sie sich nicht sicher sind, wie Sie vorgehen müssen). Das Wiederherstellen ist dann einfacher, wenn ein Problem während der Installation auftritt. Bitte beachten Sie, dass die Paket-Revisionsnummern in den folgenden Anweisungen ausgelassen wurden, um sie so allgemein wie möglich zu halten. Wenn in den Anweisungen z.B. "NVIDIA_kernel.tar.gz" erwähnt wird, können Sie diese Bezeichnung durch die Treiberversion, die Sie installieren, ersetzen: "NVIDIA_kernel.0.9-6.tar.gz". INSTALLATION DURCH RPM Anweisungen für Ungeduldige: $ rpm -ivh NVIDIA_kernel.i386.rpm $ rpm -ivh NVIDIA_GLX.i386.rpm Anweisungen: Bitte achten Sie darauf, dass Sie vor der Installation der RPM die entsprechende NVIDIA_kernel RPM für Ihren Kernel heruntergeladen haben. Nachdem sichergestellt ist, dass es sich um die korrekte RPM handelt, installieren Sie den NVIDIA_kernel wie folgt: $ rpm -ivh NVIDIA_kernel.i386.rpm Installieren Sie danach die NVIDIA_GLX RPM wie folgt: $ rpm -ivh NVIDIA_GLX.i386.rpm UPGRADING DURCH RPM Anweisungen für Ungeduldige: $ rpm -Uvh NVIDIA_kernel.i386.rpm $ rpm -e NVIDIA_GLX $ rpm -ivh NVIDIA_GLX.i386.rpm Anweisungen: Bitte achten Sie darauf, dass Sie vor dem Aktualisieren der RPM die entsprechende NVIDIA_kernel RPM für Ihren Kernel heruntergeladen haben. Nachdem sichergestellt ist, dass es sich um die korrekte RPM handelt, aktualisieren Sie den NVIDIA_kernel wie folgt: $ rpm -Uvh NVIDIA_kernel.i386.rpm Die 'U'-Option sollte nicht verwendet werden, um die NVIDIA_GLX RPM zu aktualisieren, da ein Bug im Deinstallationsbereich älterer NVIDIA RPMs einige Dateien entfernen würde, die nicht entfernt werden sollen. Verwenden Sie stattdessen für die Deinstallation der alten NVIDIA_GLX RPM ‚e' und installieren Sie dann die neue: $ rpm -e NVIDIA_GLX $ rpm -ivh NVIDIA_GLX.i386.rpm INSTALLATION/UPGRADING DURCH SRPM Anweisungen für Ungeduldige: $ rpm --rebuild NVIDIA_kernel.src.rpm $ rpm -ivh /path/to/rpms/RPMS/i386/NVIDIA_kernel.i386.rpm $ rpm -ivh NVIDIA_GLX.i386.rpm Anweisungen: Um eine spezifische NVIDIA_kernel RPM für Ihr System zu erstellen, übergehen Sie die ‚Rebuild' Flag: $ rpm --rebuild NVIDIA_kernel.src.rpm Achten Sie auf eine Zeile, die ähnlich wie die folgende aussieht (der Pfad kann ein anderer sein): Wrote: /usr/src/redhat/RPMS/i386/NVIDIA_kernel.i386.rpm und verwenden Sie dies als Eingabe für die RPM zur Installation: $ rpm -ivh /usr/src/redhat/RPMS/i386/NVIDIA_kernel.i386.rpm oder Upgrade: $ rpm -Uvh /usr/src/redhat/RPMS/i386/NVIDIA_kernel.i386.rpm Zur Installation des NVIDIA_GLX Paketes, folgen Sie den obigen Anweisungen, um NVIDIA_GLX aus RPM entweder zu installieren oder zu aktualisieren. INSTALLATION/UPGRADING DURCH ARCHIVDATEI Anweisungen für Ungeduldige: $ tar xvzf NVIDIA_kernel.tar.gz $ tar xvzf NVIDIA_GLX.tar.gz $ cd NVIDIA_kernel $ make install $ cd ../NVIDIA_GLX $ make install Anweisungen: Entpacken Sie jede Datei, um aus der Archivdatei zu installieren: $ tar xvzf NVIDIA_kernel.tar.gz $ tar xvzf NVIDIA_GLX.tar.gz cd in das NVIDIA_kernel Verzeichnis. Geben Sie 'make install' ein. Durch diese Eingabe wird das Kernel Interface in den NVdriver kompiliert, der NVdriver verbunden, der NVdriver an den richtigen Ort kopiert und versucht, den NVdriver in den Running Kernel einzubinden: $ cd NVIDIA_kernel $ make install Gehen Sie danach in das NVIDIA_GLX Verzeichnis. Geben Sie ‚make install' ein - hierdurch werden die benötigten OpenGL und XFree86 Dateien an den richtigen Ort kopiert. $ cd ../NVIDIA_GLX $ make install Bitte beachten Sie, dass die Eingabe "make install" für jedes Paket alle vorher installierten NVIDIA Treiber entfernen wird. __________________________________________________________________________ (Abschnitt 03) EDITIEREN IHRER XF86CONFIG DATEI __________________________________________________________________________ Bei der Einführung von Xfree86 4.0 verwendete diese eine geringfügig andere XF86Confic Dateisyntax als die 3er Version. Damit die 3.x und 4.x Versionen 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 Handbuchseite, um eine vollständige Beschreibung des Suchpfades zu erhalten). Bitte achten Sie darauf, dass Sie wissen, welche Konfigurationsdatei XFree86 verwendet. Wenn Sie sich nicht sicher sind, schauen Sie nach einer Zeile, die mit "(==) Using config file:" in Ihrer Xfree86 Log File ("/var/log/XFree86.0.log") beginnt. Diese README verwendet unabhängig von dem tatsächlichen Namen die Bezeichnung "XF86Config", um sich auf Ihre Konfigurationsdatei zu beziehen. Wenn Sie nicht über eine funktionierende XF86Config Datei verfügen, gibt es mehrere Möglichkeiten, zu beginnen: es gibt eine Sample Config Datei, die mit XFree86 geliefert wird und es gibt eine Sample Config Datei, die im NVIDIA_GLX Paket enthalten ist (wird installiert in /usr/share/doc/NVIDIA_GLX-1.0/). Sie können darüber hinaus ein Programm wie ‚xf86config' verwenden - einige Produkte liefern ihr eigenes Tool zum Generieren einer XF86Config Datei. Weitere Informationen über die XF86Config Dateisyntax erhalten Sie auf der entsprechenden Handbuchseite. Wenn Sie bereits über eine XF86Config Datei verfügen, die mit einem anderen Treiber agiert (wie z.B. ‚nv' Treiber), müssen Sie lediglich die entsprechende Gerätesektion finden und die Zeile: Driver "nv" durch Driver "nvidia" ersetzen Im Modulbereich muss Folgendes erscheinen: Load "glx" Die folgenden Zeilen sollten ebenfalls entfernt werden: Load "dri" Load "GLcore" wenn diese existieren. Es gibt viele Optionen, die der XF86Config Datei hinzugefügt werden können, um Feineinstellungen vorzunehmen. Eine vollständige Liste dieser Optionen finden Sie in Anhang D. Sobald Sie Ihre XFConfig Datei konfiguriert haben, können Sie X neu starten und die beschleunigten OpenGL Bibliotheken nutzen. Nachdem Sie X neu gestartet haben, sollten Sie jede OpenGL Applikationen ausführen können und diese wird automatisch die neuen NVIDIA Bibliotheken nutzen. Möglichkeiten zur Problembeseitigung finden Sie weiter unten im Abschnitt Problembehandlung. __________________________________________________________________________ (Abschnitt 04) PROBLEMBEHANDLUNG __________________________________________________________________________ Nachfolgend finden Sie einige Strategien, die wichtig sind bei der Problembehandlung mit dem Accelerated Linux Driver Set von NVIDIA sind: o Eines der nützlichsten Tools bei der Diagnostizierung von Problemen ist die XFree86 Log File in /var/log (Dateibezeichnung: "/var/log/XFree86.<#>.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 der NVIDIA Treiber statt des ‚nv' Treibers verwendet wird; schauen Sie nach: "(II) LoadModule: "nvidia" und Zeilen des Treibers sollten den folgenden Anfang haben: "(II) NVIDIA(0)". o Als Standard druckt der NVIDIA X-Treiber relativ wenige Mitteilungen an stderr und die XFree86 Log File. Müssen Probleme behoben werden, kann es hilfreich sein, mehr Verbose Output zu aktiveren, indem die XFree86 Befehlszeilenoptionen "-verbose" und "-logverbose" aktiviert werden, die zur Einstellung des Verbosity Levels für die stderr bzw. die Log File Messages verwendet werden können. Der NVIDIA X-Treiber wird mehr Meldungen ausgeben, wenn das Verbosity Level bei 5 oder höher eingestellt ist (XFree86 setzt als Standard ein Verbosity Level 1 für stderr und Level 3 für die Log File). Zur Aktivierung des Verbose Messaging vom NVIDIA X-Treiber zur Log File und stderr kann X durch die folgende Eingabe gestartet werden: 'startx -- -verbose 5 -logverbose 5'. o Es wird keine Funktion ausgeführt werden, wenn das NVdriver Kernelmodul nicht einwandfrei funktioniert. Wenn Sie eine Meldung wie folgt in der X Log File erhalten "(EE) NVIDIA(0): Failed to initialize the NVdriver kernel module!" (Nvdriver Kernelmodul konnte nicht initialisert werden) besteht höchstwahrscheinlich ein Problem mit dem NVdriver Kernelmodul. Wenn Sie aus RPM installiert haben, sollten Sie zunächst überprüfen, dass die 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 worden sein, versuchen Sie es explizit mit 'insmod' oder 'modprobe' zu laden (der X-Server muss vor dem Installieren eines neuen Kernelmoduls verlassen werden). Wenn Sie Fehlermeldungen über nicht aufgelöste Symbole erhalten, ist es wahrscheinlich, dass das Kernelmodul unter Verwendung von Headerdateien für eine andere Kernelrevision als die von Ihnen verwendete, erstellt wurde. Sie können ganz klar überwachen, welche Kernel Headerdateien verwendet werden, indem Sie den NVdriver aus der NVIDIA_kernel Archivdatei erstellen und zwar mit: 'make install SYSINCLUDE=/path/to/kernel/headers'. Bitte beachten Sie, dass sich die Konvention für den Ort der Kernel Headerdatei und der Ort der Kernelmodule in einem Übergangsstadium befinden. Wird das Kernelmodul nicht einwandfrei geladen, kann modprobe/insmod versuchen, ein älteres Kernelmodul zu laden (vorausgesetzt, dass Sie aktualisiert haben). Cd'ing in das Verzeichnis mit dem neuen Kernelmodul unter Ausführung von 'insmod ./NVdriver' kann dabei helfen. Darüber hinaus besteht die Möglichkeit, dass der NVdriver Fehlermeldungen mit Anzeige eines Problems ausgibt - zur Anzeige dieser Meldungen überprüfen Sie bitte /var/log/messages oder ob syslog darauf ausgerichtet ist, Kernelmeldungen zu platzieren. o 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 ist die einzige Notwendigkeit das erneute Ausführen von 'ldconfig'. o Bitte überprüfen Sie auch, ob die korrekten Erweiterungen vorhanden sind - 'xdpyinfo' zeigt die vorhandenen "GLX", "NV-GLX" und "NVIDIA-GLX" Erweiterungen. Sind diese drei Erweiterungen nicht vorhanden, besteht höchstwahrscheinlich ein Problem mit dem Laden des GLX Moduls oder es ist nicht in der Lage, explizit GLcore zu laden. Überprüfen Sie Ihre XF86Config Datei und überprüfen Sie das Laden von GLX (siehe "Bearbeiten Ihrer XF86Config Datei" weiter oben). Wenn Ihre XF86Config Datei korrekt ist, überprüfen Sie die XFree86 Log File auf Warn-/Fehlermeldungen, die GLX betreffen. Überprüfen Sie auch, ob die notwendigen Symlinks vorhanden sind (siehe Anhang C). o Wenn Sie versuchen, eine Installation/ein Upgrade per SRPM durchzuführen und der Befehl: rpm --rebuild NVIDIA_kernel-1.0-2313.src.rpm druckt lediglich eine Liste von RPM Befehlszeilenoptionen, haben Sie wahrscheinlich die RPM Entwicklungspakete nicht installiert. In den meisten Situationen kann dieses Problem durch die Installation des RPM-Devel Paketes für Ihr Produkt behoben werden. Alternativ können Sie die Installation/das Upgrade mit einer Archivdatei durchführen, da Archivdateien RPM nicht erfordern. o Wenn Sie versuchen, eine Installation/ein Upgrade per SRPM auszuführen und der folgende Befehl erscheint: 'rpm --rebuild NVIDIA_kernel-1.0-2313.src.rpm' reports and error of: ' NVIDIA_kernel-.src.rpm:no such file or directory. In diesem Falle müssen Sie das RPM-Build Paket für Ihr Produkt installieren. Alternativ können Sie die Installation/das Upgrade mit einer Archivdatei durchführen, da Archivdateien RPM nicht erfordern. o Wenn bei der Installation des NVIDIA_kernel Moduls eine Fehlermeldung wie die folgende erscheint: #error Modules should never use kernel-headers system headers #error but headers from an appropriate kernel-source muss die Quelle für den Linux Kernel installiert werden. In den meisten Situationen kann dieses Problem durch die Installation des Kernel Quell-Paketes für Ihr Produkt behoben werden. o Wenn Ihre OpenGL Applikationen mit der folgenden Fehlermeldung geschlossen werden: 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) ist es wahrscheinlich, dass ein Sicherheitsmodul für das PAM System die Zugangsberechtigung für die NVIDIA Gerätedateien ändert. In den meisten Fällen funktioniert dieses Sicherheitssystem - es ist jedoch möglich, dass es durcheinandergerät. Zur Behebung dieses Problems wird die Deaktivierung dieses Sicherheits-Leistungsmerkmals empfohlen. Die unterschiedlichen Linux-Produkte verfügen über unterschiedliche Kontrolldateien. Wenn Ihr System über die Datei /etc/security/console.perms verfügt, können Sie diese Datei editieren und die Zeile, die mit "" beginnt, entfernen. Wenn Ihr System aber über die Datei /etc/logindevperms verfügt, kann diese Datei editiert werden und die Zeile, die /dev/nvidiactl aufweist, entfernt werden. Die weiter oben aufgeführten Schritte verhindern, dass das PAM Sicherheitssystem die Permissions der NVIDIA Gerätedateien ändert. Danach müssen die Berechtigungen auf den Gerätedateien wieder auf die ursprünglichen Berechtigungen und den Besitzer zurückgesetzt werden. Dies kann durch die folgenden Befehle erfolgen: chmod 0666 /dev/nvidia* chown root /dev/nvidia* o Wenn Ihre OpenGL Applikationen zusammenbrechen und die folgende Warnmeldung ausgeben: WARNING: Your system is running with a buggy dynamic loader (ACHTUNG: Ihr System läuft mit einem fehlerhaften dynamischen Lader), This may cause crashes in certain applications. If you experience crashes you can try setting the environment variable __GL_SINGLE_THREADED (Hierdurch können Abstürze in bestimmten Applikationen hervorgerufen werden. Sollte dies der Fall sein, können Sie die folgende Umgebungsvariable setzen: __GL_SINGLE_THREADED). For more information please consult (sec-04) TROUBLESHOOTING in the file /usr/share/doc/NVIDIA_GLX-1.0/README (Weitere Informationen erhalten Sie in (Abschnitt 04) PROBLEMBEHANDLUNG in der Datei: /usr/share/doc/NVIDIA_GLX-1.0/README). hat der dynamische Lader in Ihrem System einen Bug, der den Absturz von Applikationen, die mit pthreads verbunden sind und die dlopen() libGL mehrere Male öffnen, hervorruft. Dieser Bug ist in älteren Versionen des dynamischen Laders enthalten. Zu den Produkten, die mit diesem Lader ausgeliefert wurden, gehören unter anderen RedHat Linux 6.2 und Mandrake Linux 7.1. Ist die zusammenbrechende Anwendung single threaded, verhindert ein Setzen der Umgebungsvariable __GL_SINGLE_THREADED auf einen beliebigen Wert diesen Zusammenbruch. Geben Sie in der Bash Shell export __GL_SINGLE_THREADED und in csh und Derivationen verwenden Sie: setenv __GL_SINGLE_THREADED Vorherige Versionen des beschleunigten Treibersets von NVIDIA haben versucht, dieses Problem zu umgehen; dieses Umgehen hat jedoch Probleme mit anderen Applikationen verursacht und wurde nach der Version 1.0-1541 entfernt. o Wenn Quake3 bei einer Veränderung des Videomodus zusammenbricht, haben Sie wahrscheinlich das oben beschriebene Problem. Bitte überprüfen Sie die Textausgabe auf die "ACHTUNG" Meldung, die im vorherigen Hinweis enthalten war. Das Setzen von __GL_SINGLE_THREADED vor dem Ausführen von Quake3, wie oben beschrieben, behebt das Problem. __________________________________________________________________________ (Abschnitt 5) FAQs - HÄUFIG GESTELLTE FRAGEN __________________________________________________________________________ Frage: Wenn ich X starte, funktioniert dieses nicht und meine XFree86 Logdatei hat den folgenden Inhalt: (II) LoadModule: "nvidia" (II) Loading /usr/X11R6/lib/modules/drivers/nvidia_drv.o No symbols found in this module (Es wurden keine Symbole in diesem Modul gefunden) (EE) Failed to load /usr/X11R6/lib/modules/drivers/nvidia_drv.o (II) UnloadModule: "nvidia" (Modul "nvidia" entfernen) (EE) Failed to load module "nvidia" (loader failed, 256) (Modul "nvidia" konnte nicht geladen werden (Laden fehlgeschlagen, 256)) (EE) No drivers available (keine Treiber verfügbar). Antwort: Dem nvidia_drv.o X Treiber wurden einige nötige Symbole entfernt; einige RPM-Versionen haben (fälschlicherweise) Objektdateien bei der Installation entfernt. Ein Upgrade der RPM-Version ist empfehlenswert. Oder Sie können das NVIDIA_GLX Paket aus der Archivdatei installieren. Frage: Mein System läuft zwar, erscheint mit jedoch instabil zu sein. Was ist hier nicht in Ordnung? Antwort: Eventuell verwenden Sie das falsche AGP-Modul. Details über die AGP-Konfiguration finden Sie in Anhang E. Frage: Beim Starten von X wird das Kernelmodul nicht dynamisch geladen; ich muss immer zunächst 'modprobe NVdriver' ausführen. Was ist hier nicht in Ordnung? Antwort: Stellen Sie sicher, dass die Zeile "alias char-major-195 NVdriver" in der Konfigurationsdatei Ihres Moduls erscheint, in der Regel eine der folgenden: "/etc/conf.modules", "/etc/modules.conf" oder "/etc/modutils/alias"; konsultieren Sie die Dokumentation Ihres Produktes, um Details zu erhalten. Frage: Ich kann das NVdriver Kernelmodul nicht erstellen oder ich kann das NVdriver Kernelmodul erstellen aber modprobe/insmod lädt das Modul nicht in meinen Kernel. Was ist hier nicht in Ordnung? Antwort: In der Regel werden diese Probleme dadurch verursacht, dass der Build die falschen Kernel Headerdateien verwendet (d.h., die Headerdateien für eine andere Kernelversion als die, welche Sie verwenden). Üblicherweise ist die Konvention, dass diese Kernel-Headerdateien in "/usr/include/linux/" gespeichert werden, diese wurde jedoch durch "/lib/modules/`uname -r`/build/include" ersetzt. Die NVIDIA_kernel Makefile sollte in der Lage sein, den Ort in Ihrem System zu bestimmen; wenn Sie jedoch ein Problem haben, können Sie den Build zwingen, bestimmte Headerdateien zu verwenden, indem Sie 'make SYSINCLUDE=/path/to/kernel/headers' einsetzen. Damit dies funktionieren kann, müssen die geeigneten Kernel Headerdateien auf Ihrem System installiert sein. Konsultieren Sie die Dokumentation, die Sie mit Ihrem Produkt erhalten haben. Bei einigen Produkten werden die Kernel Headerdateien nicht standardmäßig installiert oder es werden Header installiert, die nicht genau mit dem Kernel, den Sie verwenden, übereinstimmen. Frage: Warum laufen OpenGL Applikationen so langsam? Antwort: Die Applikation 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. Frage: Es entstehen Probleme, wenn ich Quake2 laufen lasse. Antwort: Quake2 erfordert eine geringfügige Konfiguration, 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 jeder Auflösung, die in Quake2 möglich ist, ausführen, um den Vollbildmodus zu emulieren. Frage: Es entstehen Probleme beim Ausführen von Heretic II. Antwort: Heretic II installiert ebenfalls als Standard den Symlink libGL.so in das Applikationsverzeichnis. Sie können diesen Symlink entfernen oder umbenennen, da das System dann den Standard libGL.so (den unsere Treiber in /usr/lib installieren), findet. Aus Heretic II heraus, können Sie dann den Rendermodus zu OpenGL im Videomenü einstellen. Es gibt auf der folgenden Website auch einen Patch von lokigames für Heretic II : http://www.lokigames.com/products/heretic2/updates.php3 Frage: Wo kann ich gl.h oder glx.h zur Kompilierung von OpenGL Programmen erhalten? Antwort: Auf den meisten Systemen sind diese Header vorinstalliert. Vorsichtshalber hat NVIDIA jedoch für den Fall, dass Systeme diese nicht beinhalten oder Sie Ihre eigenen OpenGL Applikationen entwickeln möchten, welche die neuen NVIDIA OpenGL Erweiterungen einsetzen, ihre eigenen gl.h und glx.h Datei mitgeliefert. Um Konflikte mit auf dem System installierten Versionen zu vermeiden, wurden diese in /usr/share/doc/NVIDIA_GLX-1.0/usr/include/GL installiert. Um diese Header zu verwenden, kopieren Sie diese in /usr/include/GL. Frage: Kann ich eine E-Mail-Benachrichtigung über neue Versionen des Accelerated Linux Driver Sets von NVIDIA erhalten? Antwort: Ja. Füllen Sie das Formular auf der folgenden Seite aus: http://www.nvidia.com/view.asp?FO=driver_update Frage: Mein System hängt sich bei vt-switching auf, wenn rivafb aktiviert ist. Antwort: Die Verwendung von rivafb und dem NVdriver Kernelmodul gleichzeitig ist gegenwärtig unterbrochen. Im Allgemeinen ist es keine gute Idee, zwei unahängige Softwaretreiber für die gleiche Hardware zu verwenden. Frage: Das Kompilieren des NVdriver Kernelmoduls erzeugt diese Fehlermeldung. Sie haben wahrscheinlich das NVdriver Kernelmodul mit einen Compiler kompiliert, der nicht mit dem übereinstimmt, der für das Kompilieren des Running Kernel 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. Antwort: Sie sollten das NVdriver Kernelmodul mit der gleichen Compilerversion kompilieren, die 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: ... * Die meisten gcc Versionen haben einen üblen Bug mit leeren Initialisierern. */ #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 aber gcc 3.x wird verwendet, wenn die geöffnete Datei im NVdriver erstellt werden (oder umgekehrt), variiert die Größe von rwlock_t und Dinge wie ioremap schlagen fehl. Wenn Sie checken möchten, welche Version zur Kompilierung Ihres Kernels verwendet wurde, überprüfen Sie die Ausgabe von: cat /proc/version Wenn Sie checken möchten, welche gcc Version in Ihrem$PATH verwendet wurde, überprüfen Sie die Ausgabe von: gcc -v Frage: X versagt mit der Fehlermeldung "Failed to allocate LUT context DMA" (Zuweisung von LUT Kontext DMA fehlgeschlagen) Antwort: Dies ist eine der möglichen Konsequenzen der Kompilierung des NVdriver mit einer anderen gcc Version als der, die zur Verwendung des Linux Kernels eingesetzt wurde (siehe oben). Frage: Es sind keine NVIDIA_kernel RPMs für Release N aus verfügbar. Ich habe versucht, die RPM-Version für N-1 zu installieren, das hat jedoch nicht funktioniert. Was soll ich tun? Antwort: Wie in (Abschnitt 01) VERWENDEN DES GEEIGNETEN NVIDIA PAKETES FÜR IHR SYSTEM beschrieben: wenn "keine spezifische NVIDIA_kernel RPM für Ihr Produkt erhältlich ist, verwenden Sie entweder die NVIDIA_kernel SRPM oder die Archivdatei." Frage: Ich erhalte die folgende Meldung, wenn ich das NVIDIA_GLX Paket installiere: The above file(s) possibly belong to a conflicting MESA rpm (Die obige(n) Datei(en) gehören eventuell zu einer Konflikt MESA RPM). They have been renamed to xxx..RPMSAVE to avoid conflicting with the files contained within this package (Sie wurden in xxx...RPMSAVE umbenannt, um Konflikte mit den Dateien zu vermeiden, die in diesem Paket enthalten sind). Please see /usr/share/doc/NVIDIA_GLX-1.0/README, section (sec-05) FREQUENTLY ASKED QUESTIONS" for more details (Weitere Details finden Sie in /usr/share/doc/NVIDIA_GLX-1.0/README, (Abschnitt 05) "FAQs - Häufig gestellte Fragen"). Was ist hier nicht in Ordnung? Antwort: Wie es die Meldung bereits ausdrückt, wurden die miteinander in Konflikt stehenden Dateien beseitigt, um sicherzustellen, dass Ihre Applikationen die neu installierten OpenGL Bibliotheken finden. Dies ist kein Grund zur Beunruhigung, diese Meldung dient ausschließlich als Information. Sobald Sie das NVIDIA_GLX Paket deinstallieren, werden die ursprünglichen Dateien automatisch wiederhergestellt. __________________________________________________________________________ (Abschnitt 06) KONTAKT __________________________________________________________________________ Es gibt ein neues Webforum für Themen, die den NVIDIA Linux Treiber betreffen! Die URL lautet: http://www.nvnews.net/cgi-bin/ultimatebb.cgi?ubb=forum&f=29 Diese URL ist das zu bevorzugende Tool für benötigte Hilfe; die Benutzer können Fragen versenden, die Fragen anderer Benutzer beantworten und die Archive auf vorherige Problemfälle durchsuchen. Sollte alles andere fehlschlagen, können Sie sich bezüglich Support unter der folgenden E-Mail-Adresse mit NVIDIA in Verbindung setzen: linux-bugs@nvidia.com. Aber bitte beachten Sie, dass diese Adresse die letzte Anlaufstelle ist, nachdem Sie die Problembehandlung in dieser README befolgt haben und im nvnew.net web Forum nach Hilfe gesucht haben. __________________________________________________________________________ (Abschnitt 07) 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.openprojects.net) __________________________________________________________________________ (Anhang A) ANHANG A: UNTERSTÜTZTE NVIDIA GRAFIKCHIPS __________________________________________________________________________ NVIDIA CHIPNAME GERÄTE PCI ID o RIVA TNT 0x0020 o RIVA TNT2 0x0028 o RIVA TNT2 (Ultra) 0x0029 o RIVA TNT2 (Vanta) 0x002C o RIVA TNT2 (M64) 0x002D o RIVA TNT2 (Integrated) 0x00A0 o GeForce 256 0x0100 o GeForce DDR 0x0101 o Quadro 0x0103 o GeForce2 MX 0x0110 o GeForce2 MX 400 0x0110 o GeForce2 MX 200 0x0111 o GeForce2 MX 100 0x0111 o GeForce2 Go 0x0112 o GeForce2 MXR 0x0113 o Quadro2 Go 0x0113 o GeForce2 Pro 0x0150 o GeForce2 GTS 0x0150 o GeForce2 GTS 0x0151 o GeForce2 Ti 0x0151 o GeForce2 Ultra 0x0152 o Quadro2 Pro 0x0153 o Quadro2 Ex 0x0153 o GeForce3 0x0200 o GeForce3 Ti 200 0x0201 o GeForce3 Ti 500 0x0202 o Quadro DDC 0x0203 Bitte beachten Sie, dass die RIVA 128/128ZX Chips vom Open Source ‚nv' Treiber für XFree86 unterstützt werden, aber nicht vom Accelerated Linux Driver Set von NVIDIA. Wenn Sie Ihre Geräte PCI IDs zum Vergleich mit der obigen Tabelle überprüfen möchten, können Sie entweder `cat /proc/pci` oder `lspci -n` verwenden; im letzteren Fall achten Sie auf das Devide mit der Vendor ID "10de", z.B.: 02:00.0 Class 0300:10de:0100 (rev 10) __________________________________________________________________________ (Anhang B) ANHANG B: MINDESTANFORDERUNGEN AN DIE SOFTWARE __________________________________________________________________________ o linux kernel 2.2.12 # cat /proc/version o XFree86 4.0.1 # XFree86 -version o Kernel modutils 2.1.121 # insmod -V Wenn Sie das NVdriver Kernelmodul erstellen müssen: o binutils 2.9.5 # size --version o GNU make 3.77 # make --version o gcc 2.7.2.3 # gcc --version Wenn Sie aus Source RPMs heraus 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 nur erforderlich, wenn Sie das NVIDIA_kernel Paket aus einer SRPM oder einer Archivdatei erstellen und kann von www.gnu.org oder dessen Mirrors bezogen werden. Bitte beachten Sie: Binutils und gcc sind bei binären RPM Installationen nicht erforderlich. Wenn Sie XFree86 verwenden, aber über keine /var/log/XFree86.0.log Datei verfügen, 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, einen der Open Source Treiber zu verwenden, der mit XFree86 (entweder 'nv', 'vga' oder 'vesa') ausgeliefert wird. Sobald XFree86 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, die zusammen mit XFree86 geliefert werden. Der "nv" Treiber zum Beispiel, der mit der XFree86 Version 4.0.1 ausgeliefert wurde, hat die GeForce2 Familie und die Quadro2 MXR GPUs nicht erkannt. Dies wurde jedoch in der XFree86 Version 4.0.2 behoben (XFree86 kann bezogen werden unter: www.xfree86.org). 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 XFree86 Treiber (/usr/X11R6/lib/modules/drivers/nvidia_drv.o); dieser Treiber wird von XFree86 zur Verwendung Ihrer NVIDIA Hardware benötigt. Der nvidia_drv.o Treiber ist binär-kompatibel mit XFree86 4.0.1 und höher. o Ein GLX Erweiterungsmodul für XFree86 (/usr/X11R6/lib/modules/extensions/libglx.so.x.y.z); dieses Modul wird von Free86 verwendet, um GLX-Support von der Serverseite 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. Sie wird während der Laufzeit mit OpenGL Applikationen verbunden. o Eine OpenGL Kernbibliothek (/usr/lib/libGLcore.so.x.y.z); diese Bibliothek wird implizit von libGL und libglx verwendet. Sie beinhaltet die kernbeschleunigte 3D-Funktionalität. Sie sollten diese nicht explizit in Ihre XF86Config Datei laden - dies wird durch libglx erledigt. o Ein Kernelmodul (/lib/modules/`uname -r`/video/NVdriver oder /lib/modules/`uname -r`/kernel/drivers/video/NVdriver). Dieses Kernelmodul bietet Low-Level Access für alle obigen Komponenten zu Ihrer NVIDIA Hardware. Es wird in den Kernel geladen, wenn der X Server gestartet wird und wird vom XFree86 Treiber und OpenGL verwendet. Der NVdriver besteht aus zwei Elementen: dem Nur-Binär Kern und einer Kernelschnittstelle, die spezifisch für Ihre Kernelversion kompiliert werden muss. Bitte beachten Sie, dass der Linux Kernel nicht über eine konsistente binäre Schnittstelle wie XFree86 verfügt, so dass es wichtig ist, dass diese Kernelschnittstelle mit der Version des Kernels übereinstimmt, den Sie verwenden. Dies können Sie erreichen, indem Sie selbst kompilieren oder vorkompilierte Binaries verwenden, die für die Kernels erstellt werden, die mit den gebräuchlicheren Linuxprodukten ausgeliefert werden. o OpenGL und GLX Headerdateien (/usr/share/doc/NVIDIA_GLX-1.0/usr/include/GL/gl.h, /usr/share/doc/NVIDIA_GLX-1.0/usr/include/GL/glx.h). In den meisten Fällen werden die vom System angebotenen /usr/include/GL Header für die OpenGL Entwicklung ausreichen. NVIDIA hat diese Header jedoch mitgeliefert, da sie die aktuellsten Versionen der NVIDIA OpenGL Erweiterungen beinhalten. Wenn Sie diese Header verwenden möchten ist es empfehlenswert, dass Sie diese in /usr/include/GL/ kopieren. Die ersten vier der oben aufgeführten Komponenten (XFree86 Treiber, GLX Modul, libGL und libGLcore) sind im NVIDIA_GLX Paket enthalten. Das NVdriver Kernelmodul ist im NVIDIA_kernel Paket enthalten. Die Dokumentation und die OpenGL und GLX Headerdateien sind ebenfalls Teil des NVIDIA_GLX Pakets und werden in /usr/share/doc/NVIDIA_GLX-1.0 installiert. Es entstehen Probleme, wenn die Applikationen die falschen Versionen einer Bibliothek verwenden. Dies kann der Fall sein, wenn entweder alte libGL Bibliotheken oder tote Symlinks vorhanden sind. Wenn Sie der Auffassung sind, dass etwas in Ihrer Installation nicht korrekt ist, ü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/X11/lib/modules/extensions/libglx.so.x.y.z /usr/X11/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/NVdriver, or /lib/modules/`uname -r`/kernel/drivers/video/NVdriver Bei der Installation des NVIDIA_kernel Pakets 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 Idconfig die falschen Symlinks erstellt. Es wird empfohlen, dass Sie diese im Konflikt stehenden Bibliotheken manuell entfernen oder umbenennen (es ist wichtig, dass diese so umbenannt werden, dass Idconfig diese nicht anschaut - wir haben herausgefunden, dass ein dem Bibliotheksnamen vorgesetztes "XXX" eine gute Möglichkeit ist), führen Sie ‚Idconfig' erneut aus und überprüfen sie, ob die korrekten Symlinks erstellt werden. Zwei Beispiele für Bibliotheken, die häufig Konflikte erzeugen, sind "/usr/X11R6/lib/libGL.so*" und "/usr/X11R6/lib/libGLcore.so*". Wenn die Bibliotheken auschecken, stellen Sie sicher, dass die Applikation die korrekten Bibliotheken verwendet. Um zum Beispiel zu überprüfen, dass die Applikation /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) Bitte beachten Sie, dass die Dateien für libGL und libGLcore verwendet werden - wenn Sie andere als NVIDIA Bibliotheken sind, müssen Sie entweder die störenden Bibliotheken entfernen oder Ihren ID Suchpfad anpassen. Wenn Ihnen diese Ausführungen fremd erscheinen, ist es empfehlenswert, die Handbuchseiten über "Idconfig" und "Idd" in Bezug auf Hinweise zu lesen. __________________________________________________________________________ (Anhang D) ANHANG D: XF86CONFIG OPTIONEN __________________________________________________________________________ Es werden die folgenden Treiberoptionen vom NVIDIA XFree86 Treiber unterstützt: Option "NvAGP" "integer" AGP Support konfigurieren. Integer Argument kann eines der folgenden sein: 0 : disable agp (AGP deaktivieren) 1 : use NVIDIA's internal AGP support, if possible (wenn möglich, NVIDIAs internen AGP Support nutzen) 2 : use AGPGART, if possible (wenn möglich, AGPART nutzen) 3 : use any agp support (try AGPGART, then NVIDIA's AGP) (jeden möglichen AGP Support nutzen (zunächst AGPART, dann NVIDIAs AGP)) Bitte beachten Sie, dass NVIDIAs interner AGP Support nicht funktionieren kann, wenn AGPART entweder statisch in Ihren Kernel kompiliert wurde oder als ein Modul erstellt aber in Ihren Kernel geladen wurde (einige Produkte laden AGPART beim Booten in den Kernel). Default: 3 (der Standard war 1 bis nach 1.0-1251) Option "NoLogo" "boolean" Zeichnen des NVIDIA Logos auf der Splashseite beim Starten von X deaktivieren. Standard: das Logo wird dargestellt. Option "NoRenderAccel" "boolean" Aktivieren oder deaktivieren der Hardwarebeschleunigung der RENDER Erweiterung. Standard: RENDER wird, wenn möglich, beschleunigt Option "UBB" "boolean" Einheitlichen Back Buffer auf Quadro Chipsätzen aktivieren oder deaktivieren; eine Beschreibung des UBB finden Sie in Anhang M. Diese Option hat keine Auswirkungen auf Quadro Chipsätze Standard: UBB ist für Quadro Chipsätze auf ‚ein' gesetzt Option "WindowFlip" "boolean" Window Flipping bei aktiviertem UBB aktivieren oder deaktivieren; eine Beschreibung finden Sie in Anhang M. Diese Option hat bei ausgeschaltetem UBB keine Auswirkungen. Die Leistung für 3D-Applikationen kann durch diese Einstellung erhöht werden. Standard: Window Flipping ist bei aktiviertem UBB als Standard ausgeschaltet. Option "PageFlip" "boolean" Page Flipping aktivieren oder deaktivieren; eine Beschreibung finden Sie in Anhang M. Standard: Page Flipping ist aktiviert. 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" Die Verwendung eines Schattens mit dem Hardware-beschleunigten Cursor aktivieren oder deaktivieren. Hiermit ist ein schwarzes, durchsichtiges Abbild der Cursorform gemeint, das in einem gegebenen Offset zum echten Cursor steht. Diese Option ist für Hardware beginnend beim GeForce 2 MX oder höher verfügbar (d.h. GeForce2 MX (200/400), GeForce2 Pro, GeForce2 Ultra, GeForce2 Go, GeForce3, Quadro, Quadro DDC, Quadro2 (MXR/EX), Quadro2 Pro und Quadro2 Go Chipsätze). Standard: kein Cursorschatten. Option "CursorShadowAlpha" "integer" Der für den Cursorschatten zu verwendende Alphawert. Er ist nur bei aktiviertem CursorShadow einsetzbar. Der Wert muss zwischen [0, 255] liegen - 0 ist vollständig durchsichtig; 255 vollständig opak. Standard: 64. Option "CursorShadowXOffset" "integer" Der Offset in Pixel, in dem das Schattenbild nach rechts von der echten Cursorabbildung versetzt wird. Diese Option ist nur bei aktiviertem CursorShadow anwendbar. Der Wert muss im Bereich zwischen [0, 32] liegen. Standard: 4. Option "CursorShadowYOffset" "integer" Der Offset in Pixel, in dem 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 das außer Kraft setzen der Elemente, die das NVIDIA Kernelmodul als mit Ihrer Videokarte verbunden entdeckt. Das kann zum Beispiel hilfreich sein, wenn Sie einen KVM Switch (Keyboard, Video, Mouse - Tastatur, Video, Maus) einsetzen und sich im abgeschalteten Modus befinden, wenn X gestartet wird. In einer derartigen Situation kann das NVIDIA Kernelmodul nicht feststellen, welche Bildschirmgeräte angeschlossen sind und der NVIDIA X-Treiber nimmt an, dass ein einzelner CRT angeschlossen ist. Wenn Sie jedoch einen digitalen Flachbildschirm anstelle eines CRT verwenden, können Sie diese Option nutzen, um dem NVIDIA X-Treiber explizit mitzuteilen, welches Gerät angeschlossen ist. Gültige Werte für diese Option sind "CRT" (Kathodenstrahlröhre), "DFP" (digitaler Flachbildschirm) oder "TV" (Fernseher). Sobald TwinView verwendet wird, kann diese Option als eine durch ein Komma separat gesetzte Liste erscheinen, wie z.B.: "CRT, CRT" oder "CRT, DFP". 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 Bildschirmgerätes gegeben sind. Die in den EDID gegebenen Informationen übergehen die im Monitorbereich gesetzten Werte für HorizSync und VertRefresh. Werden vom Bildschirmgerät keine EDID angeboten oder spezifizieren die EDID keinen Hsync oder Vrefresh Bereich, setzt der X-Server als Standard die HorizSync und VertRefresh Bereiche, die in der Monitorsektion gesetzt sind. Option "IgnoreEDID" "boolean" Sondieren der EDID (Extended Display Identification Data - Erweiterte Bildschirm-Identifikationsdaten) auf 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 "EDIDs ignorieren" Option "FlatPanelScalingMode" "string" Fordert einen spezifischen Skalierungsmodus für Flachbildschirme an. "String" kann entweder "Centered" (zentriert) oder "Scaled" (skaliert) sein. Ist die Einstellung "Zentriert", werden alle angeschlossenen Flachbildschirme so konfiguriert, dass Sie die Bildschirminhalte zentrieren (z.B.: Einstellung des Modus 800x600 auf einem Flachbildschirm mit einer ursprünglichen Auflösung von 1400x1050 resultiert in 800x600 Pixeln, die vom Flachbildschirm verwendet werden, umgeben von einem schwarzen Rand). Wurde "Skaliert" eingestellt, werden die Bildschirminhalte auf dem gesamten Flachbildschirm skaliert. Option "UseInt10Module" "boolean" Aktiverung des Xfree86 Int10 Moduls zum Warmstart aller Sekundärkarten statt POSTen der Karten durch das NVdriver Kernelmodul. Standard: aus (POSTen wird durch das NVdriver Kernelmodul vorgenommen). Option "TwinView" "boolean" TwinView aktivieren oder deaktivieren. Details finden Sie in ANHANG I. Standard: TwinView ist deaktiviert. Option "TwinViewOrientation" "string" Überwacht die Beziehung zwischen den beiden Bildschirmgeräten beim Einsatz von TwinView. Verwendet einen der folgenden Werte: "RightOf" (nach rechts) "LeftOf" (nach links) "Above" (über) "Below" (unter) "Clone" (klonen). Details finden Sie in ANHANG I. Standard: String ist NULL. Option "SecondMonitorHorizSync" "range(s)" Diese Option ist wie der Eintrag HorizSync in der Bildschirmsektion, ist jedoch bei der Verwendung von TwinView auf den zweiten Bildschirm ausgerichtet. Details finden Sie in ANHANG I. Standard: keiner. Option "SecondMonitorVertRefresh" "range(s)" Diese Option ist wie der Eintrag VertSync in der Bildschirmsektion, ist jedoch bei der Verwendung von TwinView auf den zweiten Bildschirm ausgerichtet. 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. __________________________________________________________________________ (Anhang E) ANHANG E: EINSTELLUNGSMÖGLICHKEITEN FÜR DIE OPENGL UMGEBUNGSVARIABLE __________________________________________________________________________ FULL SCENE ANTIALIASING Antialiasing ist eine Technik, die eingesetzt wird, um die Ränder von Objekten gleichmäßig zu gestalten und den ausgerissenen "Treppenstufen"-Effekt, der manchmal auftritt, zu reduzieren. Full Scene Antialiasing wird auf den folgenden GPUs unterstützt: GeForce2 MX, GeForce 256, GeForce2 Pro, GeForce2 GTS, GeForce 2 Ultra, GeForce3, Quadro, Quadro2 MXR, Quadro2 Pro und Quadro2 Go. Durch das Setzen der entsprechenden Umgebungsvariable können Sie auf jedem dieser GPUs in jeder beliebigen OpenGL Applikation Full Scene Antialiasing aktivieren. Es sind verschiedene Antialiasing Methoden verfügbar; Sie können diese durch ein entsprechendes Einstellen der __GL_FSAA_MODE Umgebungsvariable auswählen. Bitte beachten Sie, dass ein Erhöhen der Samplezahl während des FSAA Rendering die Leistung verringern kann. __GL_FSAA_MODE GeForce/GeForce2/Quadro Description GeForce3 Description ----------------------------------------------------------------------- 0 FSAA disabled FSAA disabled 1 FSAA disabled 2 x 2 oversampling with texture LOD bias 2 FSAA disabled 2 x 2 Quiconx 3 1.5 x 1.5 oversampling FSAA disabled 4 2 x 2 oversampling with 4 x 4 Bilinear no texture LOD bias 5 FSAA disabled 4 x 4 Guassian VBLANK SYNCING Das Setzen der Umgebungsvariable __GL_SYNC_TO_VBLANK ungleich null wird die glXSwap Buffer veranlassen, die vertikale Refresh Rate Ihres Bildschirms auf GeForce2 oder neuerer Hardware zu synchronisieren (d.h. auf allen Produkten außer TNT/TNT2). Führen Sie diese Änderung nur während der Vertical Blanking Period durch. __________________________________________________________________________ (Anhang F) ANHANG F: AGP KONFIGURIEREN __________________________________________________________________________ Es gibt mehrere Möglichkeiten für die Konfiguration der Verwendung von AGP durch das NVdriver Kernelmodul: Sie können zwischen der Verwendung des AGP Moduls von NVIDIA (NVAGP) oder des AGP Moduls, dass mit dem Linuxkernel geliefert wird (AGPART) wählen. Die jeweilige Verwendung wird durch die Option "NvAGP" in Ihrer XF86Config Datei überwacht: Option "NvAgp" "0" ... deaktiviert AGP Support Option "NvAgp" "1" ... wenn möglich, NVAGP verwenden Option "NvAgp" "2" ... wenn möglich, AGPART 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). Es ist wichtig, das AGP-Modul auszusuchen, das am besten mit Ihrem AGP-Chipsatz funktioniert. Sollten Probleme mit der Stabilität auftreten, ist es möglich, zunächst mit der Deaktivierung von AGP anzufangen und zu beobachten, ob dadurch das Problem behoben wird. Danach können Sie mit einem der anderen AGP-Module experimentieren. Sie können den AGP Status wie folgt überprüfen: `cat /proc/nv/card0`. Zur Verwendung des Linux AGPART Moduls wird es mit Ihrem Kernel kompiliert werden müssen: entweder statisch, eingelinkt oder als Modul erstellt. Der NVIDIA AGP Support kann nicht verwendet werden, wenn AGPART in den Kernel geladen ist. Es wird empfohlen, dass Sie AGPART 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 AGPART Moduls. o Intel 440LX o Intel 440BX o Intel 440GX o Intel 815 ("Solano") o Intel 820 ("Camino") o Intel 840 ("Carmel") o Intel 845 ("Brookdale") o Intel 850 ("Tehama") o Intel 860 ("Colusa") o AMD 751 ("Irongate") o AMD 761 ("IGD4") o AMD 762 ("IGD4 MP") o VIA 8371 o VIA 82C694X o VIA KT133 o RCC 6585HE o Micron SAMDDR ("Samurai") o Micron SCIDDR ("Scimitar") o nForce AGP Auf Athlon Motherbords mit dem VIA KX133 oder 694X Chipsatz, wie dem ASUS K7V Motherbord, setzen 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 in os-registry.c aktivieren und das NVIDIA Kernelmodul neu erstellen. Bitte beachten Sie, dass der Treiber dadurch instabil werden kann. Auf ALi1541 und ALi1647 Chipsätzen deaktivieren die NVIDIA Treiber AGP, um Zeitthemen und Signalintegritätsthemen zu umgehen. Sie können AGP erzwingen, indem Sie NVreg_EnableALiAGP in os-registry.c aktivieren und das NVIDIA Kernelmodul neu erstellen. Bitte beachten Sie, dass der Treiber dadurch instabil werden kann. __________________________________________________________________________ (Anhang G) ANHANG G: ALI SPEZIFISCHE THEMEN __________________________________________________________________________ Die folgenden Tipps können dabei helfen, problematische ALI-Systeme zu stabilisieren: o TURBO AGP MODE im BIOS deaktivieren. o Bei Verwendung eines P5A Upgraden auf BIOS Revision 1002 BETA 2. o Bei Verwendung von 1007, 1007A oder 1009 Anpassen der IO Wiederherstellungszeit auf 4 Takte. o AGP ist als Standard auf einigen ALi-Chipsätzen deaktiviert (ALi1541, ALi1647), um schwerwiegende 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 THEMEN __________________________________________________________________________ Die meisten Problemfülle, die auf SGRAM/SDRAM TNT-Karten aufgetaucht sind, konnten behoben werden. Es gibt jedoch die geringfügige Möglichkeit, dass auf Ihrer Videokarte das falsche BIOS installiert ist, und dieser Treiber weiterhin nicht bei Ihnen funktioniert. Versagt der Treiber bei Ihnen, schlagen wir das folgende Procedere vor: o Beobachten Sie Ihren Monitor beim Systemstart. Der allererste, kurz erscheinende Screen zeigt den Typ des Videospeichers an, über den Ihre Karte verfügt. Das ist entweder SGRAM oder SDRAM. o Erwerben Sie die aktuellste NVIDIA_kernel Archivdatei o Editieren Sie die Datei "os-registry.c" aus den Kernelmodul Sources. 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 __________________________________________________________________________ Das Leistungsmerkmal TwinView wird nur von NVIDIA GPUs unterstützt, die über eine Dual-Display Funktionalität verfügen, wie der GeForce2 MX, GeForce2 Go, Quadro2 MXR und Quadro2 Go. Bitte setzen Sie sich mit dem Vertrieb Ihrer Videokarte in Verbindung, um sicherzustellen, dass TwinView auf Ihrer Karte unterstützt wird. TwinView ist ein Operationsmodus, in dem zwei Bildschirmgeräte (digitale Flachbildschirme, CRTs und Fernseher) die Inhalte eines einzelnen X-Screens in jeder beliebigen Konfiguration darstellen können. Diese Art der Verwendung mehrerer Monitore hat gravierende Vorteile (wie z.B. Xinerama) gegenüber anderen Techniken: o Es wird ein einzelner X-Screen verwendet. Der NVIDIA Treiber hält alle Informationen über mehrere Bildschirmgeräte vom X-Server fern; was X betrifft, gibt es nur einen Screen. o Beide Bildschirmgeräte teilen sich einen Frame Buffer. Damit ist die gesamte Funktionalität, die auf einem einzelnen Bildschirm vorhanden ist, (z.B. beschleunigtes OpenGL) auch in TwinView erhältlich. o Es ist kein zusätzlicher Overhead erforderlich, um das Vorhandenseins eines einzelnen Desktops zu emulieren. XF86CONFIG TWINVIEW-OPTIONEN Um TwinView zu aktivieren, müssen Sie die folgenden Optionen in der Bildschirmsektion Ihrer XF86Config Datei spezifizieren: Option "TwinView" Option "SecondMonitorHorizSync" "" Option "SecondMonitorVertRefresh" "" Option "MetaModes" "" 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 "HorizSync" und "VertRefresh" Einträge in der Bildschirmsektion folgen. Wie die Handbuchseite über XF86Config erklärt: die Bereiche können eine durch ein Komma getrennte Liste verschiedener Werte und/oder Wertebereiche sein, in denen ein Bereich durch zwei unterschiedliche Werte, getrennt durch einen Bindestich gegeben ist. Die HorizSync ist in Hz 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 MetaModes Ein einzelner MetaMode beschreibt, welcher Modus auf welchem Bildschirmgerät zu einer gegebenen Zeit verwendet werden soll. Mehrere MetaModi 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, werden nur die unbedingt nötigen MetaMode Daten an X übergeben, während der Modus "per display device" (pro Bildschirmgerät) intern im NVIDIA Treiber verbleibt. In der MetaMode Syntax werden Modi innerhalb eines MetaModus durch ein Komma getrennt und mehrere MetaModi durch ein Semikolon. Zum Beispiel: ", ; , " ist der Name des Modus, der auf Bildschirmgerät 0 verwendet wird - gleichzeitig mit auf Bildschirmgerät 1. Ein Modusswitch veranlasst dann, dass auf Bildschirmgerät 0 und auf Bildschirmgerät 1 verwendet wird. Nachfolgend finden Sie einen realen MetaMode Eintrag aus der XF86Config Sample Config Datei: Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768" Wenn Sie nicht möchten, dass ein Bildschirmgerä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 Modinamen durch das Offset von Informationen zur Kontrolle der Positionierung der Bildschirmgeräte innerhalb des virtuellen Screen Space befolgt werden; z.B.: "1600x1200 +0+0, 1024x768 +1600+0; ..." Offsetbeschreibungen folgen den Konventionen, die in der X "Geometrie" Befehlszeilenoption verwendet werden; d.h. sowohl positive als auch negative Offsets sind gültig - obwohl negative Offsets nur erlaubt werden, wenn eine virtuelle Bildschirmgröße explizit in der XF86Config Datei angegeben ist. Sind für den MetaMode keine Offsets vorgegeben, werden die Offsets entsprechend dem Wert der TwinViewOrientation Option (siehe weiter unten) berechnet. Bitte beachten Sie, dass sobald die Offsets für einen beliebigen Modus in einem einzelnen MetaModus gegeben sind, Offsets für alle Modi innerhalb dieses einzelnen MetaMode erwartet werden; in einem solchen Fall wird angenommen, dass die Offsets +0+0 entsprechen, wenn sie nicht vorgegeben sind. Dort, wo sie nicht explizit vorgegeben ist, wird die virtuelle Bildschirmgröße als das Begrenzungsrechteck aller MetaMode Begrenzungsrechtecke berechnet. Es werden keine MetaModi mit einem Begrenzungsrechteck, das größer ist, als eine explizit vorgegebene virtuelle Bildschirmgröße verwendet. Ein MetaMode String kann mit einer "Panning Domain" Spezifikation weiter modifiziert werden, z.B.: "1024x768 @1600x1200, 800x600 @1600x1200" Eine Panning Domain ist der Bereich, in welcher der Viewport des Bildschirms verschoben wird, um der Maus zu folgen. Mit TwinView erfolgt das Panning auf zwei Ebenen: Zunächst wird der Viewport eines individuellen Bildschirmgerätes in die entsprechende Panning Domain verschoben und zwar so lange, wie der Viewport im Begrenzungsrechteck des MetaMode enthalten ist. Sobald die Maus das Begrenzungsrechteck des MetaMode verlässt, wird der gesamte MetaMode (d.h. alle Bildschirmgeräte) verschoben, um der Maus innerhalb des virtuellen Bildschirms zu folgen. Bitte beachten Sie, dass die individuellen Panning Domains der Bildschirmgeräte als Standard an die Position der Viewports der Bildschirmgeräte gebunden sind, obwohl das Standardverhalten darin liegt, dass die Viewports miteinander "verbunden" bleiben und nur die zweite Art des Panning ausführen. Panning Domains können sicherlich am besten genutzt werden, wenn tote Bereiche - Bereiche des virtuellen Bildschirms, die aufgrund von Bildschirmgeräten mit unterschiedlichen Auflösungen nicht genutzt werden können - eliminiert werden. For example: "1600x1200, 1024x768" erzeugt einen Bereich unterhalb des 1024x768 Displays, auf den nicht zugegriffen werden kann. Spezifikation einer Panning Domain für das zweite Bildschirmgerät: "1600x1200, 1024x768 @1024x1200" ermöglicht den Zugriff auf einen toten Bereich, indem der 1024x768 Viewport in der 1024x1200 Panning Domain nach oben und unten verschoben werden kann. Offsets können in Verbindung mit Panning Domains zur Positionierung der Panning Domains im virtuellen Bildschirmbereich genutzt werden (bitte beachten Sie, dass der Offset die Panning Domain beschreibt und den Viewport nur insoweit betrifft als der Viewport innerhalb der Panning Domain enthalten sein muss). Nachfolgend werden zum Beispiel zwei Modi beschrieben, von denen jeder eine Panning Domain mit einer Breite von 1900 Pixeln hat und das zweite Display unterhalb des ersten positioniert wird. "1600x1200 @1900x1200 +0+0, 1024x768 @1900x768 +0+1200" Wird kein MetaMode String spezifiziert, verwendet der X-Treiber die Modi, die in der relevanten "Bildschirm" Subsection aufgeführt sind, um entsprechende passende Modi für jedes Bildschirmgerät zu platzieren. o TwinViewOrientation Diese Option kontrolliert die Positionierung des zweiten Bildschirms in Relation zum ersten Bildschirm innerhalb des virtuellen X-Screens, wenn in den MetaModi keine Offsets explizit angegeben werden. Die möglichen Werte sind: "RightOf" (der Standard) "LeftOf" "Above" "Below" "Clone" Wird "Clone" (Klonen) spezifiziert, wird beiden Bildschirmgeräten ein Offset von 0,0 zugewiesen. o ConnectedMonitor Diese Option gibt die Möglichkeit, außer Kraft zu setzen, was das NVIDIA Kernelmodul in Verbindung mit Ihrer Videokarte feststellt. Das kann zum Beispiel dann nützlich sein, wenn eines Ihrer Bildschirmgeräte eine Erkennung unter Verwendung von Display Data Channel Protokollen (DDC) nicht unterstützt. Gültige Werte für diese Option sind "CRT" (Kathodenstrahlröhre), "DFP" (digitaler Flachbildschirm) oder "TV" (Fernseher). Sobald TwinView verwendet wird, kann diese Option als eine durch ein Komma separat gesetzte Liste erscheinen, wie z.B.: "CRT, CRT" oder "CRT, DFP". 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 Frage: Auf meinem Bildschirm erscheint keine Anzeige. Was ist nicht in Ordnung? Antwort: Bildschirme, die keine Bildschirmerkennung unter Verwendung von Display Data Channel (DDC) Protokollen unterstützen (dazu gehören die meisten älteren Monitore) können von Ihrer NVIDIA Karte nicht erkannt werden. Der NVIDIA XFree86 Treiber muss unter Verwendung der "Connected Monitor" (angeschlossener Monitor) Option explizit darüber informiert werden, welcher Bildschirm angeschlossen ist; z.B.: Option "ConnectedMonitor" "CRT, CRT" Frage: Sind die Window Manager in der Lage, Windows ordnungsgemäß zu platzieren (kann es zum Beispiel vermieden werden, die Fenster auf beiden Bildschirmgeräten aufzuteilen oder Fenster in Bereiche des virtuellen Desktops zu setzen, die nicht zugänglich sind)? Antwort: Ja. Der NVIDIA X-Treiber bietet eine Xinerama Erweiterung, die den X-Clients (wie den Window Managern) erlaubt, XineramaQueryScreens() aufzurufen, um die aktuelle TwinView Konfiguration zu ermitteln. 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 Window Manager immer noch an, dass Sie die vorherige Konfiguration verwenden. Wenn die Xinerama Erweiterung zusammen mit der XF86VidMode Erweiterung zur Erzeugung von Modeswitch Events verwendet wird, sollten die Window Manager in der Lage sein, die entsprechende TwinView Konfiguration zu jeder Zeit zu ermitteln. Eine weitere Lösung zur Vermeidung von nicht zugänglichen Bereich des virtuellen Bildschirms ist die Verwendung von Panning Domains (MetaMode Beschreibung weiter oben). Frage: Warum kann ich keine Auflösung von 1600x1200 auf dem zweiten Bildschirmgerät erzielen? Antwort: Aufgrund der Tatsache, dass das zweite Bildschirmgerät ein digitaler Flachbildschirm sein sollte, liegt der Pixeltakt für das zweite Bildschirmgerät bei nur 150MHz. Dadurch wird die Auflösung für das zweite Bildschirmgerät effektiv auf einen Bereich von ungefähr 1280x1024 beschränkt (eine Beschreibung über die Beschränkung der programmierbaren Modi durch Pixeltakt-Frequenzen erhalten Sie in XFree86 Video Timings HOWTO). Frage: Arbeiten Video Overlays auf beiden Bildschirmgeräten? Antwort: Hardware Video Overlays arbeiten nur auf dem ersten Bildschirmgerät. Die aktuelle Lösung besteht darin, dass Blitted Video statt TwinView eingesetzt wird. Frage: Wie werden die virtuellen Bildschirmdimensionen in TwinView ermittelt? Antwort: Nachdem alle angeforderten Modi bestätigt wurden und die Offsets für jeden Viewport des MetaModes berechnet wurden, berechnet der NVIDIA Treiber das Begrenzungsrechteck der Panning Domains für jeden einzelnen MetaMode. Die maximale Breite und Höhe des Begrenzungsrechtecks wird dann ermittelt. Bitte beachten Sie, dass ein Nebeneffekt dieses Vorganges ist, dass die virtuelle Breite und die virtuelle Höhe aus verschiedenen MetaModi erzeugt wird. 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. Frage: Kann ich Vollbildspiele über beide Bildschirme verteilt spielen? Antwort: Ja. Obwohl die Details der Konfiguration von Spiel zu Spiel variieren wird, liegt die grundsätzliche Idee darin, dass ein MetaMode X mit einem Modus darstellt, dessen Auflösung das Begrenzungsrechteck der Viewports für diesen MetaMode ist. Zum 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 Elemente 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 kein Modus mit einer Auflösung von 800x600 besteht (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. Damit ebenfalls zwei einzelne Head Modi verfügbar sind, kann ein geeigneter MetaMode 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, in die korrekte Richtung zu weisen. __________________________________________________________________________ (Anhang J) ANHANG J: TV-OUT KONFIGURIEREN __________________________________________________________________________ Videokarten auf Basis eines NVIDIA GPUs mit TV-Out- (S-Video) Stecker können eingesetzt werden, um einen Fernseher genau wie einen CRT oder einen digitalen Flachbildschirm zu nutzen. Der Fernseher kann (auf geeigneten Videokarten) in Verbindung mit einem weiteren Bildschirmgerät in einer TwinView Konfiguration genutzt werden. Ist der Fernseher das einzige mit Ihrer Videokarte verbundene Gerät, wird es als primäres Display benutzt, wenn Sie Ihr System neu starten (d.h. die Konsole erscheint auf dem Fernseher als sei er ein CRT).Wenn Sie Ihren Fernseher zusammen mit X nutzen, gibt es einige Parameter in Ihrer XF86Config Datei, denen Sie besondere Aufmerksamkeit widmen sollten. o Den VertRefresh und HorizSync Werten in Ihrer Monitorsektion; bitte achten Sie darauf, dass diese für Ihren Fernseher geeignet sind. Die Werte sind im Allgemeinen: HorizSync 30-50 VertRefresh 60 o Den Modi in Ihrer Screen Section, die einzigen gültigen Werte für den Fernseher sind 640x480 und 800x600 und möglicherweise 1024x768, wenn der TV Encoder auf Ihrer Videokarte ein BrookTree871 ist - Ihre XFree86 Log Datei sollte die Information geben, welchen Encoder Sie haben (achten Sie auf die Zeile: "(--) NVIDIA(0): TV Encoder detected as") (erkannter TV Encoder). o Die Option "TVStandard" sollte der Screen Section 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 Die Zeile in Ihrer XF86Confi Datei 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 Videokarte erkannt wird oder Sie einen CRT (oder digitalen Flachbildschirm nutzen) aber X 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 erzeugen. Ohne diese Option erkennt der Treiber das Ausgabeformat automatisch. Leider tut er das nicht immer richtig. Das Ausgabeformat kann mit den folgenden Optionen erzwungen werden: Option "TVOutFormat" "SVIDEO" oder Option "TVOutFormat" "COMPOSITE" __________________________________________________________________________ (Anhang K) ANHANG K: KONFIGURIEREN EINES LAPTOPS __________________________________________________________________________ INSTALLATION UND KONFIGURATION Die Installation und Konfiguration ist für alle Desktop-Umgebungen gleich. In der Treiberversion 1.0-1251 war es erforderlich, dass die Benutzer die Option "NVreg_Mobile" an das NVdriver Kernelmodul übergeben; dies kann durch die Verwendung des modprobe Befehls erfolgen: modprobe NVdriver NVreg_Mobile=X oder durch das Hinzufügen der folgenden Information zur Kernelmodul Konfigurationsdatei (üblicherweise entweder /etc/conf.modules oder /etc/modules.conf): options NVdriver NVreg_Mobile=X Egal, wie die Option spezifiziert wurde, ihr sollte der Wert zugewiesen werden: "1" bei Verwendung eines GeForce2 Go oder Quadro2 Go in einem Dell Laptop "2" bei Verwendung eines GeForce2 Go oder Quadro2 Go in einem Satellite 2800 Series Toshiba Laptop "4" bei Verwendung eines GeForce2 Go oder Quadro2 Go in einem Satellite 3000 Series Toshiba Laptop "5" bei Verwendung eines GeForce2 Go oder Quadro2 Go in einem Gateway Laptop Versionen nach 1.0-1251 erfordern die Option NVreg_Mobile nicht mehr, obwohl diese die erkannten Informationen übergehen kann. WEITERE FUNKTIONEN TWINVIEW Sowohl der GeForce2 Go als auch der Quadro2 Go unterstützen TwinView. TwinView kann auf einem Laptop genauso wie auf einem Desktop-Computer installiert werden (siehe Anhang I weiter oben); bitte beachten Sie, dass in einer Notebook Konfiguration, die den internen Flachbildschirm des Laptops und einen externen CRT nutzt, der CRT das primäre Bildschirmgerät ist (spezifizieren von HorizSync und VertRefresh in der Bildschirmsektion Ihrer XF86Config Datei) und der Flachbildschirm das sekundäre Bildschirmgerät (spezifizieren von HorizSync und VertRefresh durch die SecondMonitorHorizSync und SecondMonitorVertRefresh Optionen). Darüber hinaus können Sie die Option UseEdidFreqs nutzen, um die HorizSync und VertRefresh aus den EDID jedes Bildschirmgerätes zu erlangen und nicht darüber nachdenken zu müssen, wie diese in Ihre XF86Config Datei gesetzt werden können (das sollte aber nur dann getan werden, wenn Sie den EDIDs, die von Ihrem Bildschirm gemeldet werden, vertrauen) - weitere Details erhalten Sie in der Beschreibung der Option UseEdidFreqs in ANHANG D). HOTKEY SWITCHING VON BILDSCHIRMGERÄTEN Neben TwinView haben Laptops mit dem GeForce2 Go ebenfalls die Möglichkeit auf ein LCD/CRT Hotkeyevent zu reagieren, um zwischen den angeschlossenen Bildschirmgeräten und jeder möglichen Kombination der angeschlossenen Bildschirmgeräte hin und herzuschalten (bitte beachten Sie, dass nur zwei Geräte gleichzeitig aktiv sein können. TwinView in Ihrer XF86Config Datei konfiguriert und die Hotkeyfunktion schließen sich gegenseitig aus - wenn Sie TwinView in Ihrer XF86Config Datei aktivieren, ignoriert der NVIDIA X Treiber LCD/CRT Hotkeyevents. Ein weiterer wichtiger Aspekt der Hotkeyfunktion ist die Möglichkeit der dynamischen Verbindung und Entfernung von Geräten mit/von Ihrem Laptop - und per Hotkey zu ihnen zu wechseln ohne X neu zu starten. Ein wichtiger Punkt ist die Bestätigung und Festlegung der auf jedem Bildschirmgerä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 der Monitor Section verändert sich sonst mit jedem Hotkeyevent. Sobald X gestartet wird oder eine Veränderung in der Liste der angeschlossenen Bildschirmgeräte auftritt, wird eine neue Hotkey-Sequenz konstruiert - in dieser Sequenz wird aufgeführt, welche Bildschirmgerä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 XF86Config Datei angefragt wird, wird in Anbetracht der Grenzbedingungen jedes Bildschirmgerätes bestätigt und die resultierenden Modi werden für das entsprechende Bildschirmgerät zur Verfügung gestellt. Sollen mehrere Bildschirme gleichzeitig aktiv sein, werden die Modi der einzelnen Bildschirmgeräte zusammengelegt. Kann keine genaue Übereinstimmung gefunden werden (gleiche Auflösung), wird das nächstgelegene Element gefunden und das Bildschirmgerät mit der geringeren Auflösung wird in die Auflösung des anderen Bildschirmgerätes verschoben. Erfolgt vt-Switching außerhalb von X, wird die VGA Konsole immmer auf dem Bildschirmgerät wiederhergestellt, auf dem es vorhanden war, als X gestartet wurde. Erfolgt vt-Switching wieder zurück in X hinein, wird die gleiche Bildschirmgerätekonfiguration genutzt, die beim Verlassen von X verwendet wurde - unabhängig davon, welche Hotkeyaktivitäten in der Zwischenzeit erfolgt sind. NICHT-STANDARD MODI AUF LCD DISPLAYS Einige Benutzer haben ein Problem, 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 LAPTOP THEMEN o Power Management wird gegenwärtig nicht unterstützt. o LCD/CRT Hotkey Switching auf den Satellite 2800 Series Laptops von Toshiba funktioniert gegenwärtig nicht. o TwinView auf Satellite 2800 Series Toshiba Laptops funktioniert gegenwärtig nicht. o Der Video Overlay funktioniert nur auf dem ersten Bildschirmgerät, auf dem X gestartet wird. Wird X zum Beispiel auf dem internen LCD gestartet und Sie lassen zunächst eine Videoapplikation laufen, die Video Overlay verwendet (den "Video Overlay" Adapter verwendet, der durch die XV Erweiterung angeboten wird) und nehmen dann einen Hotkeyswitch für das Hinzufügen eines zweiten Bildschirmgerätes vor, wird das Video nicht auf dem zweiten Bildschirmgerät erscheinen. Um dies zu umgehen, können Sie entweder die Videoapplikation so konfigurieren, dass sie den "Video Blitter" Adapter verwendet, der durch die XV Erweiterung angeboten wird (diese ist immer verfügbar) oder per Hotkey Switch zu dem Bildschirmgerät wechseln, auf dem Sie das Video Overlay nutzen wollen, bevor X gestartet wird. __________________________________________________________________________ (Anhang L) ANHANG L: PROGRAMMIERMODI __________________________________________________________________________ Das Accelerated Linux Driver Set von NVIDIA unterstützt alle Standard VGA- und VESA Modi und darüber hinaus die meisten von den Benutzern geschriebenen angepassten Moduszeilen; Dualscan-Modi werden auf der gesamten Hardware unterstützt und Interlace Modi werden unterstützt auf: GeForce 256, GeForce DDR, Quadro, GeForce2 GTS/GeForce2 Pro, GeForce2 Ti, GeForce2 Ultra, Quadro2 Pro und allen TNT Produkten. Im Allgemeinen wird das Bildschirmgerät (Monitor/Flachbild/Fernseher) eine stärkere Einschränkung für die verwendbaren Modi darstellen als Ihr Videobord auf NVIDIA GPU Basis oder das Accelerated Linux Driver Set von NVIDIA. Um einen oder mehrere Standardmodi zur Verwendung in X anzufordern, können Sie ganz einfach eine "Modes" Zeile wie die folgende hinzufügen. Modes "1600x1200" "1024x768" "640x480" und zwar in der entsprechenden Bildschirm Subsection Ihrer XF86Config Datei (Details hierüber finden Sie auf der Handbuchseite XF86Config(4/5). 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 Fine Art des Erstellens von angepassten Moduszeilen für XFree86 sind. Wir überlassen diese detaillierten Beschreibungen Dokumentationen wie der XFree86 Video Timings HOWTO (die unter www.linuxdoc.org gefunden werden kann). TIEFE, BIT PRO PIXEL UND PITCH Obwohl sie bei der Programmierung von Modi keine direkte Belastung darstellen, 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 "depth" (Tiefe) und "bits per pixel" (Bit pro Pixel) einzugehen. Die Tiefe stellt die Menge der Datenbits dar, die pro Pixel gespeichert werden. Unterstützte Tiefen sind 8, 15, 16 und 24. Der Großteil der Videohardware speichert die Pixeldaten in Größen von 8, 16 oder 32 Bit; dies ist die Speichermenge, die pro Pixel zugewiesen wird. Wenn Sie die Tiefe spezifizieren, wählt X die Bit pro Pixel (bpp) Größe, in der die Daten gespeichert werden sollen. Nachfolgend finden Sie eine Tabelle, welche bpp für jede mögliche Tiefe verwendet werden. Tiefe (depth) bpp ===== ===== 8 8 15 16 16 16 24 32 "Pitch" (Druckweite) stellt dar, wie viele Byte im linearen Frame Buffer zwischen den Daten eines Pixels und den Daten des nächsten direkt darunterliegenden Pixels liegen. Sie können sich diese als horizontale Auflösung multipliziert mit den Byte pro Pixel (Bit pro Pixel geteilt durch 8) vorstellen. In der Praxis kann das Pitch mehr als dieses Produkt sein, da die Video Hardware oftmals Anforderungen stellt, dass ein Pitch ein Vielfaches eines Wertes darstellt. MAXIMALE AUFLÖSUNGEN Das Accelerated Linux Driver Set von NVIDIA und Videobords 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 Menge des Videospeichers (Details finden Sie in NÜTZLICHE FORMELN) und der maximal durch Ihr Bildschirmgerä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, dass die Video-Speicherbandbreite, die von einem programmierten Modus verwendet wird, sich aber auf die Qualität des Overlays auswirkt. NÜTZLICHE FORMELN Die maximale Auflösung ist sowohl eine Funktion der Videospeichermenge als auch der Bit pro Pixel, die Sie zur Verwendung auswählen: HR * VR * (bpp/8) = Video Memory Used (verwendeter Videospeicher) Mit anderen Worten entspricht die Menge des verwendeten Videospeichers der horizontalen Auflösung (HR) multipliziert mit der vertikalen Auflösung (VR) multipliziert mit den Byte pro Pixel (Bit pro Pixel geteilt durch 8). Technisch gesehen stellt der verwendete Videospeicher tatsächlich die Pitch Times der vertikalen Auflösung dar und der Pitch kann geringfügig größer als (HR * (bpp/8)) sein, um den Hardwareanforderungen zu entsprechen, dass der Pitch ein Vielfaches eines bestimmten Wertes sei. Bitte beachten Sie, dass dies nur die Speicherverwendung für den Frame Buffer darstellt, der Videospeicher wird auch von anderen Dingen wie OpenGL oder Pixmap Caching verwendet. Eine weitere wichtige Beziehung besteht zwischen der Auflösung, dem Pixeltakt (aka dot clock) und der vertikalen Bildwiederholfrequenz: RR = PCLK / (HFL * VFL) In anderen Worten ist die Bildwiederholfrequenz (RR - Refresh Rate) gleich dem Pixeltakt (PCLK - pixel clock) geteilt durch die Gesamtzahl der Pixel: die horizontale Framelänge (HFL - horizontal frame length) multipliziert mit der vertikalen Framelänge (VFL - vertical frame length). Bitte beachten Sie, dass dies die Framelängen und nicht nur die sichtbaren Auflösungen sind. Wie in den XFree86 Video Timings HOWTO beschrieben, kann die obige Formel umgeschrieben werden: PCLK = RR * HFL * VFL Sie können bei einem gegebenen maximalen Pixeltakt die RR, HFL und VFL wie gewünscht anpassen, solange das Produkt der drei konsistent ist. Der Pixeltakt ist in der Logdatei aufgeführt, wenn Sie X mit Verbose Logging ausführen: `startx -- -logverbose 5`. Ihre XFree86.0log 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 jedem Bit pro Pixelgröße anzeigen. BESTÄTIGEN VON MODI Während der PreInit Phase des X-Servers überprüft der NVIDIA X-Treiber alle angeforderten Modi durch das folgende Procedere: o Nimmt den Schnitt der HorizSync und VertRefresh Bereiche, die vom Benutzer in der XF86Config gegeben wurden und der Bereiche, die vom Monitor in den EDID (Exteded Display Identification Data - Erweiterte Bildschirm-Identifikationsdaten) dargestellt werden. Dieses Verhalten kann durch die Verwendung der Option "Ignore EDID" (EDID ignorieren) deaktivert werden. In diesem Fall aktzeptiert der X-Server blind die vom Benutzer eingegebenen HorizSync und VertRefresh Bereiche. o Aufrufen der xf86ValidateModes() Helferfunktion, die Modi mit den Namen findet, die der Benutzer in der XF86Config Datei spezifiziert hat und Modi mit ungültigen Horizontal Sync Frequenzen oder Vertical Refresh Rates, Pixeltakte, die größer als der maximale Pixeltakt für die Videokarte oder Auflösungen, die größer sind als die virtuelle Bildschirmgröße (wenn eine virtuelle Bildschirmgröße in der XF86 Config Datei festgelegt wurde) entfernt. Es werden mehrere Grenzbedingungen eingesetzt; siehe: xc/programs/Xserver/hw/xfree86/common/xf86Mode.c:xf86ValidateModes(). o Alle von xf86ValidateModes() zurückgesandten Modi werden dann überprüft, um sicherzustellen, dass ihre Auflösungen nicht höher sind als der größte Modus, der von den EDID dargestellt wird (dies kann durch die Option "IgnoreEDID" (EDID ignorieren) 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 Alle verbleibenden Modi werden dann überprüft, damit sichergestellt wird, dass sie die weiter unten in WEITERE MODUS GRENZBEDINUNGEN beschriebenen Grenzbedingungen einhalten. Die letzten beiden Schritte werden auch durchgeführt, wenn jeder einzelne Modus programmiert wird, damit potentiell falsche Modi vermieden werden, die durch XF86VidModeExtension (z.B. xvidtune(1)) eingebracht werden. Für TwinView wird die obige Bestätigung für die von jedem einzelnen Bildschirmgerät angeforderten Modi durchgeführt. WEITERE MODUS GRENZBEDINGUNGEN Nachfolgend finden Sie eine Liste weiterer Grenzbedingungen für die Parameter eines Modus, die eingehalten werden müssen. o Die horizontale Auflösung (HR) muss ein Vielfaches von 4 und kleiner oder gleich 2048 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 der Horizontal Sync Start (max(HFL,HSE) - min(HR,HSS)) muss ein Vielfaches von 4 und kleiner oder gleich 1024 sein. o Der Horizontal Sync Start (HSS) muss ein Vielfaches von 4 und kleiner oder gleich 4088 sein. o Die Horizontal Sync Breite (Horizontal Sync End minus Horizontal Sync Start (HSE-HSS)) muss ein Vielfaches von 4 und kleiner oder gleich 256 sein. o Die horizontale Framelänge (HFL) muss ein Vielfaches von 4 und kleiner oder gleich 4128 und größer oder gleich 40 sein. o Die vertikale Auflösung (VR - Vertical Resolution) muss kleiner oder gleich 2048 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 128 sein. o Der vertikale Sync Start (VSS) muss kleiner oder gleich 2047 sein. o Die Vertical Sync Breite (Vertical Sync End minus Vertical Sync Start (VSE - VSS)) muss kleiner oder gleich 16 sein. o Die vertikale Framelänge (VFL) muss kleiner oder gleich 2049 und größer oder gleich 2 sein. Nachstehend finden Sie eine Beispielzeile, welche die Verwendung jeder der oben verwendeten Abkürzungen demonstriert: # Custom Mode line for the SGI 1600SW Flatpanel # name PCLK HR HSS HSE HFL VR VSS VSE VFL Modeline "sgi1600x1024" 106.9 1600 1632 1656 1672 1024 1027 1030 1067 SIEHE AUCH: Ein XFree86 Moduszeilengenerator, der dem GTF-Standard entspricht, wurde an die XFree86 Xpert Mailing Liste geschickt. http://www.xfree86.org/pipermail/xpert/2001-October/012070.html Eine Suche nach weiteren Moduszeilengeneratoren ist unter "modeline" auf freshmeat.net möglich. __________________________________________________________________________ (Anhang M) ANHANG M: PAGE FLIPPING, WINDOW FLIPPING UND UBB __________________________________________________________________________ Beginnend mit der Treiberversion 1.0-2313 unterstützt das Accelerated Linux Driver Set von NVIDIA UBB (Unified Back Buffer - Einheitlicher Back Buffer), Page Flipping und Window Flipping. In bestimmten Situationen können diese Leistungsmerkmale Performancesteigerungen erzeugen. Nachfolgend finden Sie eine Beschreibung der einzelnen Elemente: o Page Flipping: Dieses Leistungsmerkmal ist auf der gesamten GeForce und neuerer Hardware (d.h.; nicht auf TNT/TNT2 Produkten) verfügbar und wird im Falle einer einzelnen deutlichen Vollbild-OpenGL Applikation beim syncing zu vblank aktiviert. Das Buffer Swapping wird durch das Wechseln des jeweils vom DAC gescannten Buffers und nicht durch das Kopieren des Back Buffers in den Front Buffer erzeugt. Das ist ein Mechanismus mit einer sehr viel höheren Performance und ermöglicht verlustfreies Swappen während des Strahlrücklaufs (wenn __GL_SYNC_TO_VBLANK eingestellt ist). Dieses Leistungsmerkmal kann durch die PageFlip XF86Config Option deaktiviert werden. o Unified Back Buffer (UBB - (Einheitlicher Back Buffer)): UBB ist nur auf dem Quadro verfügbar und wird standardmäßig aktiviert, wenn ausreichend Videospeicher zur Verfügung steht. Dies kann mit der in Anhang D beschriebenen Option UBB XF86Config deaktiviert werden. Sobald UBB aktiviert ist, teilen 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. Jedoch entspricht die Back-, Stencil- und Depth Usage selbst bei einem einzelnen kleinen Fenster der eines Vollbildfensters, so dass in diesem Fall die Video RAM weniger effizient genutzt werden können als bei nicht vorhandenem UBB. o Window Flipping: Dieses Leistungsmerkmal erfordert UBB und ist damit nur auf Quadroprodukten verfügbar. Wenn ein einzelnes OpenGL Window vorliegt, können die Buffer dieses Fensters durch das Verändern, welcher Buffer vom DAC gescannt wird, geswappt werden, so dass die Back Buffer Contents nicht in den Front Buffer geblittet werden müssen. Dies ist dem Page Flipping ähnlich, vermeidet aber die Beschränkung, dass das Window scharf und Vollbild sein muss. Dies funktioniert nur, wenn ein einzelnes OpenGL Window vorliegt. Als Standard ist Window Flipping deaktivert und kann mit der in Anhang D beschriebenen XF86Config Option "WindowFlip" aktiviert werden. __________________________________________________________________________ (Anhang N) ANHANG N: BEKANNTE THEMEN __________________________________________________________________________ Die folgenden Probleme liegen in dieser Version noch vor und sind dabei, behoben zu werden. o OpenGL + Xinerama Gegenwärtig funktioniert OpenGL nicht zusammen mit Xinerama. 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 Applikationen wie Quake3 und Radiant, die dlopen() verwenden. Weitere Details finden Sie im Abschnitt "Problembehandlung". o DPMS und TwinView Die DPMS Modi "supend" (pausieren) und "standby" (Standby) arbeiten bei der Verwendung von TwinView nicht korrekt auf einem zweiten CRT. Es erscheint ein leerer Bildschirm, der Monitor wird nicht in den angeforderten DPMS Status gesetzt. o DPMS und Flachbildschirm Die DPMS Modi "supend" (pausieren) und "standby" (Standby) arbeiten nicht korrekt auf einem Flachbildschirm. 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 NVdriver Kernelmodul erkannt. Sie können dies durch die Aktivierung des Xfree86 Int10 Moduls umgehen, damit alle sekundären Karten warmgestartet werden. Siehe ANHANG D: XF86CONFIG OPTIONEN", um weitere Details zu erhalten. o Laptop Wir möchten Sie auf "Bekannte Laptop Themen" in ANHANG D verweisen, wenn Sie einen Laptop verwenden. HARDWARE THEMEN Dieser Abschnitt beschreibt Problemfälle, die nicht behoben werden. In der Regel liegt die Ursache des Problems außerhalb der Kontrolle von NVIDIA. Nachfolgend finden Sie eine Liste der Probleme: o Gigabyte GA-6BX Motherbord Dieses Motherbord verwendet einen LinFinity Regler auf einer 3,3-V Rail, das nur bis 5 A gerated wird - das liegt unter der AGP-Spezifikation, die 6 A erfordert. Wenn Diagnoseprogramme oder Applikationen 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, den Strom auf dem 3,3-V Rail zu liefern, den der NVIDIA Chip erfordert. Dieses Problem entsteht nicht, wenn das Grafikbord über einen Schaltregler verfügt oder eine externe Stromversorgung mit der 3,3 V Rail verbunden ist. o VIA KX133 und 694X Chipsätze mit AGP 2x Auf Athlon Motherbords mit dem VIA KX133 oder 694X Chipsatz, wie dem ASUS K7V Motherbord, setzen 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 Es werden auf Athlon Motherbords mit dem Irongate Chipsatz 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 Timing Problemfälle und Signalintegritätsthemen zu umgehen. Siehe "ANHANG G: ALI SPEZIFISCHE THEMEN", um weitere Informationen über Ali Chipsätze zu erhalten.