Pilotes accélérés NVIDIA pour Linux - LISEZMOI et Guide d'installation Dernière mise à jour : $Date : 25/02/2005 $ Dernière version du pilote : 1.0-7174 Les pilotes accélérés NVIDIA pour Linux apportent à Linux x86 l'accélération 2D et la prise en charge OpenGL haute performance ainsi que l'utilisation de processeurs graphiques (GPU) NVIDIA. Ces pilotes optimisent l'accélération matérielle des applications OpenGL par le biais d'un serveur X de rendu direct et prennent en charge la majorité des puces graphiques NVIDIA (vous trouverez la liste complète des puces prises en charge dans l'ANNEXE A). Ils sont également compatibles avec TwinView, TV-Out et les écrans plats. Le présent fichier LISEZMOI décrit les procédures d'installation, de configuration et d'utilisation des pilotes accélérés NVIDIA pour Linux. Ce fichier est disponible sur le site Web de NVIDIA (www.nvidia.com) et est installé dans le répertoire /usr/share/doc/nvidia_GLX-1.0/. __________________________________________________________________________ TABLE DES MATIÈRES (sec-01) CHOIX DES PAQUETAGES NVIDIA APPROPRIÉS À VOTRE SYSTÈME (sec-02) INSTALLATION DU PILOTE NVIDIA (sec-03) MODIFICATION DU FICHIER DE CONFIGURATION X (sec-04) FORUM AUX QUESTIONS (FAQ) (sec-05) COMMENT NOUS CONTACTER (sec-06) AUTRES RESSOURCES (app-a) ANNEXE A : PUCES GRAPHIQUES NVIDIA PRISES EN CHARGE (app-b) ANNEXE B : CONFIGURATION LOGICIELLE MINIMALE REQUISE (app-c) ANNEXE C : COMPOSANTS INSTALLÉS (app-d) ANNEXE D : OPTIONS DE CONFIGURATION X (app-e) ANNEXE E : CONFIGURATION DES VARIABLES D'ENVIRONNEMENT OPENGL (app-f) ANNEXE F : CONFIGURATION D'AGP (app-g) ANNEXE G : PROBLÈMES SPÉCIFIQUES DES SYSTÈMES ALI (app-h) ANNEXE H : PROBLÈMES SPÉCIFIQUES DES SYSTÈMES TNT (app-i) ANNEXE I : CONFIGURATION DE TWINVIEW (app-j) ANNEXE J : CONFIGURATION DE TV-OUT (app-k) ANNEXE K : CONFIGURATION D'UN ORDINATEUR PORTABLE (app-l) ANNEXE L : MODES DE PROGRAMMATION (app-m) ANNEXE M : FLIPPING ET UBB (app-n) ANNEXE N : PROBLÈMES CONNUS (app-o) ANNEXE O : INTERFACE PROC (app-p) ANNEXE P : PRISE EN CHARGE DE XVMC (app-q) ANNEXE Q : PRISE EN CHARGE DE GLX (app-r) ANNEXE R : CONFIGURATION DE PLUSIEURS ÉCRANS X SUR UNE CARTE (app-s) ANNEXE S : PRISE EN CHARGE DE LA GESTION D'ÉNERGIE (app-t) ANNEXE T : NOMS DES PÉRIPHÉRIQUES D'AFFICHAGE (app-u) ANNEXE U : L'EXTENSION X COMPOSITE (app-v) ANNEXE V : NVIDIA-SETTINGS (app-w) ANNEXE W : L'EXTENSION X XRANDR Pour éviter de surcharger les instructions d'installation, la plupart des problèmes fréquemment rencontrés ne sont pas détaillés dans les descriptions, mais sont traités dans le forum aux questions (FAQ). Il est toutefois conseillé de lire entièrement le fichier LISEZMOI avant de se lancer dans l'une quelconque des étapes décrites. __________________________________________________________________________ (sec-01) CHOIX DES PAQUETAGES NVIDIA APPROPRIÉS À VOTRE SYSTÈME __________________________________________________________________________ NVIDIA a une architecture de pilote unifiée. En d'autres termes, les pilotes sont compatibles avec toutes les puces graphiques NVIDIA prises en charge. Vous trouverez la liste des puces graphiques NVIDIA prises en charge par les pilotes actuels dans l'annexe A. La version 1.0-4349 des pilotes introduit un nouveau mécanisme de paquetage et d'installation qui simplifie considérablement la procédure d'installation. Désormais, vous ne devrez télécharger qu'un seul fichier : NVIDIA-Linux-x86-1.0-7174-pkg1.run. Ce fichier regroupe tout ce qui se trouvait précédemment dans les anciens paquetages NVIDIA_kernel et NVIDIA_GLX. La version 1.0-7174 des pilotes ajoute un nouveau suffixe ("-pkg#") de paquetage au fichier .run. Cela permet de différencier les paquetages contenant des pilotes identiques, mais des interfaces de noyaux précompilées différentes. Pour éviter toute confusion, téléchargez le fichier .run doté de la version de paquetage la plus récente (le numéro le plus grand). __________________________________________________________________________ (sec-02) INSTALLATION DU PILOTE NVIDIA __________________________________________________________________________ OPÉRATIONS PRÉLIMINAIRES Vous devez quitter le serveur X avant de commencer l'installation du pilote. De plus, vous devez définir votre niveau d'exécution par défaut de manière à amorcer le système sur une console VGA et pas directement dans X (Consultez la documentation fournie avec votre distribution Linux si vous ne savez pas comment procéder ; normalement, vous devez modifier votre fichier /etc/inittab). Cette opération facilitera la restauration en cas de problème au cours de l'installation. Une fois le pilote installé, vous devez modifier le fichier de configuration X avant de pouvoir l'utiliser. Reportez-vous à la section MODIFICATION DU FICHIER DE CONFIGURATION X, ci-après. PRÉSENTATION DU NOUVEAU PROGRAMME D'INSTALLATION DES PILOTES NVIDIA Après avoir téléchargé NVIDIA-Linux-x86-1.0-7174-pkg1.run, commencez l'installation en quittant X, accédez à l'aide de la commande cd au répertoire contenant le fichier téléchargé, puis exécutez : sh NVIDIA-Linux-x86-1.0-7174-pkg1.run Le fichier .run est auto-extractible. Par conséquent, lorsque vous lancez le fichier .run, il extrait le contenu de l'archive et exécute l'utilitaire `nvidia-installer` qui vous guide dans l'installation du pilote NVIDIA. Le fichier .run accepte de nombreuses options de ligne de commande, parmi lesquelles : --info Imprime des infos sur le fichier .run et quitte le programme. --check Vérifie l'intégrité de l'archive et quitte le programme. --extract-only Extrait uniquement le contenu de ./NVIDIA-Linux-x86-1.0-7174.run, sans lancer 'nvidia-installer'. --help Imprime des informations sur l'utilisation des options de ligne de commande les plus courantes et quitte le programme. --advanced-options Imprime des informations sur l'utilisation des options de ligne de commande standard et avancées, puis quitte le programme. Le programme d'installation copie également l'utilitaire `nvidia-installer`, qui permettra ensuite de désinstaller les pilotes, de télécharger automatiquement les mises à jour des pilotes, etc. INTERFACES DE NOYAU Le module de noyau NVIDIA dispose d'une couche d'interface de noyau qui doit être compilée pour la configuration et la version que vous utilisez. NVIDIA distribue le code source à cette couche d'interface noyau, ainsi qu'une version précompilée pour un grand nombre des noyaux disponibles dans les distributions les plus répandues. Au cours de son exécution, le programme d'installation vérifie s'il possède une interface noyau précompilée pour le noyau utilisé. En son absence, il en cherche une sur le site ftp de NVIDIA et la télécharge (à condition que vous disposiez d'une connexion Internet). S'il trouve une interface noyau précompilée correspondant à votre noyau, celle-ci est reliée [1] à la portion binaire du module noyau NVIDIA. Résultat : vous disposez d'un module adapté à votre noyau. S'il ne trouve aucune interface noyau précompilée convenant à votre noyau, il compile l'interface pour vous. Toutefois, il vérifie d'abord que les fichiers d'en-tête correspondant à votre noyau sont bien installés sur votre système. Si le programme d'installation compile l'interface noyau, vous devez installer le paquetage kernel-sources adapté à votre noyau. [1] REMARQUE : vous devez disposer d'un éditeur de liens sur votre système pour pouvoir procéder à l'installation. L'éditeur de liens (habituellement '/usr/bin/ld') fait partie du paquetage binutils ; vérifiez la présence de binutils avant d'installer le pilote NVIDIA. CARACTÉRISTIQUES DE NVIDIA-INSTALLER o Désinstallation : au cours de l'installation du pilote, tout fichier à l'origine de conflits est sauvegardé et les nouveaux fichiers installés sur le système sont enregistrés. Vous pouvez exécuter : nvidia-installer --uninstall pour désinstaller le pilote actuel ; cette commande supprime tous les fichiers installés sur le système et restaure les copies de sauvegarde des fichiers. L'installation de nouveaux pilotes désinstalle implicitement tout pilote antérieur. o Mise à jour automatique : si vous exécutez : nvidia-installer --latest l'utilitaire se connecte au site FTP de NVIDIA et indique la dernière version du pilote ainsi que l'adresse URL à laquelle vous pouvez télécharger le fichier. Si vous exécutez : nvidia-installer --update l'utilitaire se connecte au site FTP de NVIDIA, télécharge la dernière version du pilote et l'installe. o Plusieurs interfaces utilisateur : le programme d'installation fait appel à une interface utilisateur de type ncurses s'il détecte la bibliothèque ncurses appropriée. A défaut, il revient à une interface de type ligne de commande. Pour désactiver l'utilisation de l'interface ncurses, choisissez l'option '--ui=none'. o Interfaces de noyau mises à jour : le programme d'installation peut télécharger des interfaces de noyau précompilées mises à jour à partir du site FTP de NVIDIA (pour les noyaux disponibles après la version du pilote NVIDIA). FORUM AUX QUESTIONS (FAQ) CONCERNANT LE PROGRAMME D'INSTALLATION NVIDIA Q: Comment puis-je extraire le contenu du fichier .run sans installer le pilote ? R: Exécutez la commande : sh NVIDIA-Linux-x86-1.0-7174-pkg1.run --extract-only Vous créerez ainsi le répertoire NVIDIA-Linux-x86-1.0-7174-pkg1, qui contient le fichier .run décompressé. Q: Comment puis-je voir le code source de la couche d'interface noyau ? R: Les fichiers source de la couche d'interface noyau se trouvent dans le répertoire usr/src/nv du fichier .run décompressé. Pour accéder à ces sources, exécutez : sh NVIDIA-Linux-x86-1.0-7174-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-7174-pkg1/usr/src/nv/ Q: Je viens de mettre à jour mon noyau et je ne parviens pas à charger le module du noyau NVIDIA. Que se passe-t-il ? R: La couche d'interface noyau du module du noyau NVIDIA doit être compilée pour la configuration et la version de votre noyau. Si vous mettez à jour le noyau, la meilleure solution est de réinstaller le pilote. POUR LES UTILISATEURS AVANCÉS : vous pouvez installer le module du noyau NVIDIA pour un noyau non utilisé (par exemple, si vous venez de construire et d'installer un nouveau noyau sans avoir redémarré) en utilisant une ligne de commande du type suivant : sh NVIDIA-Linux-x86-1.0-7174-pkg1.run --kernel-name='NOM_NOYAU' où 'NOM_NOYAU' correspond au nom que `uname -r` afficherait si le noyau cible était exécuté. Q: Pourquoi NVIDIA ne fournit-elle plus de RPM ? R: Les distributions Linux n'utilisent pas toutes des RPM et NVIDIA voulait une seule solution pour toutes les distributions Linux. Comme précisé dans la licence d'utilisation des logiciels NVIDIA, les distributions Linux peuvent redistribuer le pilote NVIDIA pour Linux dans le format de paquetage de leur choix. Q: nvidia-installer ne fonctionne pas sur mon ordinateur. Comment puis-je installer le pilote contenu dans le fichier .run ? R: Pour installer le pilote NVIDIA contenu dans le fichier .run sans utiliser nvidia-installer, vous pouvez utiliser le makefile inclus : sh ./NVIDIA-Linux-x86-1.0-7174-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-7174-pkg1 make install Cette méthode d'installation est toutefois déconseillée et ne doit être utilisée qu'en dernier ressort si nvidia-installer ne fonctionne pas correctement sur votre système. Q: nvidia-installer peut-il utiliser un serveur proxy ? R: Oui, parce que le support ftp inclus dans nvidia-installer est basé sur snarf et accepte les variables d'environnement FTP_PROXY, NARF_PROXY et PROXY. Q: Quelle est l'importance du suffixe "pkg#" par rapport au fichier .run ? R: Le suffixe "pkg#" permet de différencier les fichiers .run contenant le même pilote, mais des interfaces de noyau précompilées différentes. Si un nouveau noyau est fourni dans une distribution après la publication d'un pilote NVIDIA, le pilote NVIDIA actuel peut être modifié de manière à inclure une interface de noyau précompilée correspondant à ce nouveau noyau (en plus de toutes les interfaces de noyau précompilées figurant dans le précédent paquetage du pilote). Les fichiers .run ayant le même numéro de version mais des numéros pkg différents se distinguent par les interfaces de noyau précompilées qu'ils contiennent. En outre, les fichiers .run ayant un numéro pkg supérieur ont le même contenu que les fichiers .run dotés d'un numéro .pkg inférieur. Q: J'ai déjà installé NVIDIA-Linux-x86-1.0-7174-pkg1.run, mais je constate que NVIDIA-Linux-x86-1.0-7174-pkg2.run vient d'être mis à disposition sur la page de téléchargement des pilotes NVIDIA pour Linux. Dois-je télécharger et installer NVIDIA-Linux-x86-1.0-7174-pkg2.run ? R: Cela est inutile. Le pilote contenu dans tous les fichiers .run 1.0-7174 est identique. Il est donc inutile de réinstaller le pilote. Q: Puis-je ajouter mes propres interfaces de noyau précompilées au fichier .run ? R: Oui. L'option "--add-this-kernel" du fichier .run décompacte le fichier .run, crée une interface de noyau précompilée pour le noyau en cours d'exécution et reconstitue le fichier .run en ajoutant "-custom" au nom du fichier. Cette opération peut s'avérer nécessaire si vous gérez plusieurs machines Linux exécutant le même noyau. Q: Où puis-je trouver le code source de l'utilitaire nvidia-installer ? R: L'utilitaire nvidia-installer est fourni sous le GPL. Le dernier code source est disponible sur le site suivant : ftp://download.NVIDIA.com/XFree86/nvidia-installer/ REMERCIEMENTS RELATIFS À NVIDIA-INSTALLER nvidia-installer est basé sur l'outil loki_update : http://www.lokigames.com/development/loki_update.php3. La prise en charge ftp et http de nvidia-installer est basée sur snarf 7.0 : http://www.xach.com/snarf/. L'archive auto-extractible (aka "fichier .run") est générée à l'aide de makeself.sh (http://www.megastep.org/makeself/). __________________________________________________________________________ (sec-03) MODIFICATION DU FICHIER DE CONFIGURATION X __________________________________________________________________________ En avril 2004, la Fondation X.org a rendu disponible un serveur X reposant sur le serveur X XFree86. De nombreuses distributions Linux vont adopter le serveur X de X.org à l'avenir au détriment du serveur XFree86. Les différences entre les deux serveurs X ne devraient avoir aucun impact sur les utilisateurs de pilotes NVIDIA pour Linux à deux exceptions près : 1) Le nom du fichier de configuration X.org, bien qu'il utilise la même syntaxe que le fichier XF86Config du serveur XFree86, s'intitule /etc/X11/xorg.conf. Dans le présent document, ces fichiers de configuration sont mentionnés de manière générique sous l'appellation "fichier de configuration X". 2) Le fichier journal X.org, bien que sa sortie soit quasiment identique à celle du fichier journal XFree86.0, est appelé /var/log/Xorg.0.log. Dans le présent document, ces fichiers sont mentionnés de manière générique sous l'appellation "fichier journal X". Dans la version 4.0 de XFree86, la syntaxe du fichier XF86Config était légèrement différente de celle des versions 3.x. Pour permettre la coexistence des versions 3.x et 4.x de XFree86 sur le même système, XFree86 4.x utilise le fichier de configuration "/etc/X11/XF86Config-4" s'il existe, sinon (seulement si ce fichier n'existe pas), il utilise le fichier "/etc/X11/XF86Config" (il s'agit en fait d'une simplification des critères de recherche ; consultez la page man XF86Config pour une description complète de chemin de recherche). Vérifiez le fichier de configuration utilisé par votre serveur X. En cas de doute, recherchez une ligne commençant par "(==) Using config file:" dans le fichier journal X ("/var/log/XFree86.0.log" ou "/var/log/Xorg.0.log"). Si vous ne possédez pas de fichier de configuration X opérationnel, vous pouvez démarrer de plusieurs manières : un modèle de fichier de configuration est fourni avec XFree86 et un autre est inclus dans le paquetage du pilote NVIDIA (ce fichier est installé dans /usr/share/doc/nvidia_GLX-1.0/). Vous pouvez également utiliser un programme, tel que 'xf86config'. Certaines distributions fournissent des outils permettant de générer un fichier de configuration X. Pour de plus amples informations sur la syntaxe de ce fichier, reportez-vous à la page man (`man XF86Config`, ou `man xorg.conf`). Si vous utilisez déjà un fichier de configuration X avec un autre pilote (par exemple, le pilote 'nv' ou 'vesa'), il vous suffit de rechercher la section "Device" correspondante et de remplacer la ligne : Driver "nv" (ou Driver "vesa") par Driver "nvidia" Dans la section "Module", vérifiez la ligne suivante : Load "glx" Le cas échéant, supprimez les lignes suivantes : Load "dri" Load "GLcore" Il est également possible d'ajouter de nombreuses options au fichier de configuration X pour affiner la configuration du pilote X NVIDIA. Vous trouverez une liste complète de ces options dans l'annexe D. Une fois la configuration du fichier de configuration X terminée, vous pouvez redémarrer X et commencer à utiliser les bibliothèques accélérées OpenGL. Après le redémarrage de X, vous devriez pouvoir exécuter une application OpenGL quelconque et utiliser les nouvelles bibliothèques NVIDIA. Si vous rencontrez un problème, reportez-vous au FAQ ci-dessous. __________________________________________________________________________ (sec-04) FORUM AUX QUESTIONS (FAQ) __________________________________________________________________________ Q: Par où dois-je commencer pour le diagnostic de problèmes d'affichage ? R: L'un des outils les plus efficaces pour le diagnostic de problèmes est le fichier journal X situé dans /var/log. (Ce fichier s'intitule "/var/log/XFree86.<#>.log" ou "/var/log/Xorg.<#>.log", où "<#>" correspond au numéro du serveur, généralement 0). Les lignes commençant par "(II)" sont des informations, celles commençant par "(WW)", des avertissements et celles commençant par "(EE)", des erreurs. Assurez-vous que le fichier de configuration utilisé est le bon (c'est-à-dire celui que vous êtes en train de modifier). Recherchez la ligne commençant par "(==) Using config file:". Vérifiez également que vous utilisez le pilote NVIDIA et non le pilote 'nv' ou 'vesa'. Pour cela, recherchez "(II) LoadModule: "nvidia"" et vérifiez que les lignes concernant le pilote commencent par "(II) NVIDIA(0)". Q: Comment puis-je augmenter la quantité de données imprimées dans le fichier journal X ? R: Par défaut, le pilote NVIDIA de X imprime un nombre relativement faible de messages dans stderr et le fichier journal X. En cas d'erreur, il peut s'avérer utile d'activer les options de ligne de commande du serveur X "-verbose" et "-logverbose" pour obtenir un niveau d'affichage plus complet des messages stderr et du fichier journal. Le pilote X de NVIDIA affichera davantage de messages si le mode verbose a été initialisé à 5 ou plus (par défaut, le niveau d'affichage de XFree86 est défini sur 1 pour stderr et sur 3 pour le fichier journal). Si vous voulez activer le mode verbose depuis le pilote X de NVIDIA pour le fichier journal et stderr, vous pouvez démarrer X à entrant : 'startx -- -verbose 5 -logverbose 5'. Q: Le serveur X ne démarre pas et le fichier journal X contient l'erreur suivante : " (EE) NVIDIA(0): Failed to load the NVIDIA kernel module! " R: Le pilote X abandonnera en donnant ce message d'erreur si le module de noyau de NVIDIA ne parvient pas à se charger ou si des fichiers de périphériques ne sont pas présents. Si vous obtenez cette erreur, vous devez examiner si la sortie de " dmesg " ne contient pas de messages d'erreur et/ou essayer de charger le module de noyau explicitement avec " modprobe nvidia ". Si des symboles non-résolus sont rapportés, le module de noyau a très certainement été compilé d'après une arborescence source de noyau (ou d'en-têtes de noyau) pour une révision de noyau ou une configuration qui ne correspond pas au noyau en cours d'exécution. Vous pouvez préciser l'emplacement de l'arborescence source du noyau (ou les en-têtes) quand vous installez le pilote NVIDIA en utilisant l'option de ligne de commande --kernel-source-path (voir " sh NVIDIA-Linux-x86-1.0-7174-pkg1.run --advanced-options " pour plus de détails). Si " lsmod " rapporte qu'un module noyau " nvidia " est chargé, il est possible que des fichiers de périphériques (/dev/nvidiactl, /dev/nvidia0..7) soient manquants. Q: Quand et comment les fichiers de périphériques NVIDIA sont-ils créés ? R: Selon la configuration du système cible, les fichiers de périphériques NVIDIA peuvent être créés de trois façons différentes : de manière statique en utilisant mknod (quand le pilote est installé) ou de manière dynamique, soit via devfs (le système de fichiers de périphériques de Linux) soit via udev (solution d'espace utilisateur remplaçant devfs) ; s'ils sont créés dynamiquement, les fichiers de périphériques ne seront pas présents tant que le module noyau NVIDIA ne sera pas chargé. Q: Le serveur X ne démarre pas et le fichier journal X contient l'erreur suivante : "(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!" R: Rien ne fonctionnera si le module de noyau de NVIDIA ne fonctionne pas correctement. Si le fichier journal de X contient un message du type "(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!", vous avez très probablement un problème avec le module de noyau de NVIDIA. Enfin, le module de noyau de NVIDIA peut générer des messages d'erreur indiquant un problème. Pour visualiser ces messages, examinez la sortie de " dmesg ", /var/log/messages ou tous les emplacements où syslog dirige les messages concernant le noyau. Ces messages sont précédés de " NVRM ". Q: Le serveur X ne démarre pas et le fichier journal X contient l'erreur suivante : "(EE) NVIDIA(0): The NVIDIA kernel module does not appear to be receiving (EE) NVIDIA(0): interrupts generated by the NVIDIA graphics device. (EE) NVIDIA(0): Please see the FREQUENTLY ASKED QUESTIONS section in the (EE) NVIDIA(0): README for additional information." R: Cela peut être dû à toute une variété de problèmes, tels que des erreurs de routage IRQ PCI, des problèmes d'APIC d'E/S ou des conflits avec d'autres périphériques partageant l'IRQ (ou avec leurs périphériques). Si possible, configurez votre système de sorte que votre carte graphique ne partage pas son IRQ avec d'autres périphériques (essayez de mettre la carte graphique dans un autre slot (le cas échéant), déchargez/désactivez le/les pilotes du/des périphériques partageant l'IRQ de la carte, ou retirez/ désactivez le/les périphériques. Selon la nature du problème, l'un des paramètres de noyau (ou une combinaison de ces mêmes paramètres) suivants pourra être utile : pci=noacpi (ne pas utiliser l'ACPI pour le routage IRQ PCI) pci=biosirq (utiliser les appels du BIOS PCI pour récupérer la table de routage IRQ) noapic (ne pas utiliser les APIC d'E/S présents dans le système) acpi=off (désactiver ACPI) Q: X démarre mais les applications OpenGL s'arrêtent immédiatement. R: Si X démarre mais qu'OpenGL cause des problèmes, vous avez probablement un problème avec d'autres bibliothèques ou avec des liens symboliques. Pour plus de détails, consultez l'annexe C. Il suffit parfois de réexécuter 'ldconfig'. Vous devez également contrôler l'exactitude des extensions. 'xdpyinfo' doit renvoyer les extensions " GLX " et " NV-GLX ". Si ces deux extensions sont absentes, le module glx ne se chargera probablement pas ou sera incapable de charger implicitement GLcore. Vérifiez votre fichier de configuration X et assurez-vous de charger glx (reportez-vous à la section " Modification du fichier de configuration X " ci-avant). Si votre fichier de configuration X est correct, regardez si le fichier journal X contient pas de messages d'avertissement ou d'erreur relatifs à GLX. Vérifiez également si tous les liens symboliques nécessaires sont en place (reportez-vous à l'annexe C). Q: L'installation du module de noyau NVIDIA génère un message d'erreur du type : #error Modules should never use kernel-headers system headers #error but headers from an appropriate kernel-source R: Vous devez installer la source pour le noyau Linux. Dans la plupart des cas, il suffit d'installer le paquetage des sources de noyau de votre distribution pour résoudre le problème. Q: Les applications OpenGL se ferment en générant le message d'erreur suivant : Error: Could not open /dev/nvidiactl because the permissions are too restrictive. Please see the FREQUENTLY ASKED QUESTIONS section of /usr/share/doc/nvidia_GLX-1.0/README for steps to correct. R: Un module de sécurité du système PAM a probablement modifié les autorisations sur les fichiers des périphériques NVIDIA. Ce système de sécurité fonctionne généralement bien, mais peut parfois poser problème. Pour résoudre ce problème, il est conseillé de désactiver la fonction de sécurité. Les distributions Linux utilisent différents fichiers pour effectuer ce contrôle ; demandez à votre distributeur comment désactiver cette fonction de sécurité. Par exemple, si votre système contient le fichier /etc/security/console.perms vous devez modifier ce fichier et supprimer la ligne commençant par "". (Il nous a également été signalé que d'autres références à doivent être supprimées dans console.perms, mais ceci n'a pas été vérifié par NVIDIA). En revanche, si votre système contient le fichier /etc/logindevperms vous devez modifier ce fichier et supprimer la ligne contenant /dev/nvidiactl. Ces opérations empêcheront le système de sécurité PAM de modifier les autorisations sur les fichiers des périphériques NVIDIA. Vous devez ensuite réinitialiser les autorisations s'appliquant aux fichiers des périphériques pour rétablir les autorisations et les utilisateurs d'origine. Pour cela, vous pouvez utiliser les commandes suivantes : chmod 0666 /dev/nvidia* chown root /dev/nvidia* Q: Les applications OpenGL se bloquent et génèrent l'avertissement suivant : WARNING: Your system is running with a buggy dynamic loader. This may cause crashes in certain applications. If you experience crashes you can try setting the environment variable __GL_SINGLE_THREADED to 1. For more information please consult the FREQUENTLY ASKED QUESTIONS section in the file /usr/share/doc/nvidia_GLX-1.0/README. R: Le chargeur dynamique installé sur votre système a un bogue qui provoque le blocage des applications liées à pthreads et utilisant dlopen() pour charger les libGL. Ce bogue est présent dans les anciennes versions du chargeur dynamique. Les distributions fournies avec ce chargeur comprennent, entres autres, Red Hat Linux 6.2 et Mandrake Linux 7.1. Les versions 2.2 et suivantes du chargeur dynamique fonctionnent correctement. Si l'application qui se bloque comprend un seul thread, il suffit de définit la variable d'environnement __GL_SINGLE_THREADED sur 1 pour résoudre le problème. Dans le shell bash, entrez : export __GL_SINGLE_THREADED=1 et dans csh et dérivés, utilisez : setenv __GL_SINGLE_THREADED 1 Les versions précédentes des pilotes accélérés NVIDIA pour Linux tentaient de remédier à ce problème, mais la solution causait des problèmes dans d'autres applications et a été supprimée après la version 1.0-1541. Q: Lorsque j'utilise Quake3, il se bloque lorsque je change de mode vidéo. Que se passe-t-il ? R: Vous avez probablement rencontré le problème décrit ci-dessus. Assurez-vous que le message d'avertissement cité ci-dessus s'affiche. Pour corriger le problème, définissez __GL_SINGLE_THREADED sur 1 comme décrit ci-dessus). Q: Mon système fonctionne mais il est instable. Que se passe-t-il ? R: Vos problèmes de stabilité pourraient être liés à l'AGP. Pour plus de détails, reportez-vous à l'annexe F. Q: Je ne parviens pas à construire le module du noyau NVIDIA ou j'y parviens, mais modprobe/insmod ne charge pas le module dans mon noyau. Que se passe-t-il ? R: Ces problèmes surviennent généralement lorsque les fichiers d'en-tête utilisés pour la construction ne correspondent pas au noyau (par ex., les fichiers d'en-tête se réfèrent à une version du noyau différente de celle utilisée). Si l'on respecte la convention, les fichiers d'en-tête du noyau doivent normalement être enregistrés dans "/usr/include/Linux/", mais l'emplacement préféré actuel tend à être "/lib/modules/`uname -r`/build/include". L'utilitaire nvidia-installer devrait déterminer l'emplacement de ces fichiers sur votre système. Toutefois, en cas de problème, vous pouvez forcer l'utilisation de certains fichiers d'en-tête pour la construction à l'aide de l'option --kernel-include-dir. Pour cela, les fichiers d'en-tête du noyau doivent évidemment être installés sur votre système. Consultez la documentation fournie avec votre distribution ; certaines distributions n'installent pas par défaut les fichiers d'en-tête du noyau ou elles installent des fichiers d'en-tête qui ne conviennent pas au noyau utilisé. Q: Pourquoi les applications OpenGL sont-elles si lentes ? R: L'application n'utilise probablement pas la bibliothèque OpenGL fournie par NVIDIA, mais une autre bibliothèque installée sur votre système. Pour de plus amples informations, reportez-vous à l'ANNEXE C. Q: Quake2 ne fonctionne pas correctement. R: Pour fonctionner correctement, Quake2 a besoin de quelques petits réglages. D'abord, l'installation crée dans le répertoire Quake2 un lien symbolique vers libMesaGL.so, appelé libGL.so. Ce lien symbolique doit être supprimé ou renommé. Ensuite, pour exécuter Quake2 en mode OpenGL, vous devez taper 'quake2 +set vid_ref glx +set gl_driver libGL.so'. Quake2 semble ne pas prendre en charge les modes plein écran, mais vous pouvez utiliser votre serveur X avec une résolution prise en charge par Quake2 pour l'émulation du mode plein écran. Q: Heretic II ne fonctionne pas correctement. R: Heretic II installe également par défaut un lien symbolique appelé libGL.so dans le répertoire de l'application . Vous pouvez supprimer ou renommer ce lien symbolique, puisque le système trouvera le fichier libGL.so par défaut (que vos pilotes installent dans /usr/lib). Dans Heretic II, vous pouvez définir le mode de rendu sur OpenGL dans le menu video. Vous pouvez également télécharger un correctif pour Heretic II à partir du site de Lokigames à l'adresse suivante : http://www.lokigames.com/products/heretic2/updates.php3 Q: Où puis-je trouver gl.h ou glx.h pour compiler des programmes OpenGL ? R: Ces fichiers d'en-tête sont préinstallés sur la plupart des systèmes. Toutefois, NVIDIA fournit ses propres fichiers gl.h et glx.h, installés dans /usr/share/doc/NVIDIA_GLX-1.0/include/GL. Pour utiliser ces fichiers, vous devez d'abord les copier manuellement dans /usr/include/GL ou indiquer à l'utilitaire de les installer dans /usr/include/GL en passant l'option '-opengl headers' au fichier NVIDIA-Linux-x86-1.0-7174-pkg1.run pendant l'installation. Q: Puis-je être informé par e-mail de la sortie de nouvelles versions de pilotes accélérés NVIDIA pour Linux ? R: Oui. Il vous suffit de remplir le formulaire d'inscription à l'adresse : http://www.nvidia.com/view.asp?FO=pilote_update Q: Mon système ne répond plus quand j'effectue une commutation VT si rivafb est activé. R: Actuellement, il n'est pas possible d'utiliser rivafb en même temps que le module du noyau NVIDIA. En général, il est déconseillé d'utiliser deux pilotes logiciels indépendants pour le même composant matériel. Q: La compilation du module du noyau NVIDIA génère l'erreur suivante : You appear to be compiling the NVIDIA kernel module with a compiler different from the one that was used to compile the running kernel. This may be perfectly fine, but there are cases where this can lead to unexpected behaviour and system crashes. If you know what you are doing and want to override this check, you can do so by setting IGNORE_CC_MISMATCH. In any other case, set the CC environment variable to the name of the compiler that was used to compile the kernel. R: Vous devez compiler le module du noyau NVIDIA en utilisant la même version du compilateur que celle utilisée pour la compilation de votre noyau. Certaines structures de données du noyau Linux dépendent de la version de gcc utilisée pour sa compilation ; par exemple, dans include/Linux/spinlock.h: ... * Most gcc versions have a nasty bug with empty initializers. */ #if (__GNUC__ > 2) typedef struct { } rwlock_t; #define RW_LOCK_UNLOCKED (rwlock_t) { } #else typedef struct { int gcc_is_buggy; } rwlock_t; #define RW_LOCK_UNLOCKED (rwlock_t) { 0 } #endif Si le noyau est compilé avec gcc 2.x, mais que gcc 3.x est utilisé pour la compilation de l'interface du noyau (ou vice versa), la taille de rwlock_t changera et causera l'échec de fonctions telles que ioremap. Pour connaître la version de gcc utilisée pour compiler votre noyau, observez ce que vous renvoie la commande : cat /proc/version Pour connaître la version de gcc qui se trouve dans votre $PATH, utilisez : gcc -v Q: X échoue en générant l'erreur "Failed to allocate LUT context DMA". R: Ce type d'erreur est l'une des conséquences possibles de la compilation de l'interface du noyau NVIDIA en utilisant une version de gcc différente de celle utilisée pour compiler le noyau Linux (voir ci-dessus). Q: Quelle est la politique de NVIDIA au sujet des noyaux de la série de développement de Linux ? R: NVIDIA ne prend pas officiellement en charge les noyaux de la série de développement de Linux. Toutefois, le code source de tous les modules de noyau qui s'interfacent avec le noyau Linux est disponible dans le répertoire usr/src/nv/ du fichier .run. NVIDIA encourage les membres de la communauté Linux à développer des correctifs pour ces fichiers source de manière à pouvoir prendre en charge les noyaux de la série de développement. Une recherche dans Google permettra probablement de trouver plusieurs correctifs. Q: J'ai récemment mis à jour plusieurs bibliothèques sur mon système à l'aide de l'utilitaire de mise à jour distribué par Linux et le pilote graphique NVIDIA ne fonctionne plus. Que se passe-t-il ? R: Votre utilitaire de mise à jour Linux a probablement installé des bibliothèques entrant en conflit ; pour le diagnostic du problème, reportez-vous à l'ANNEXE C: COMPOSANTS INSTALLÉS. Q: `rpm --rebuild` donne une erreur "unknown option". R: De récentes versions de rpm ne prennent plus en charge l'option "--rebuild" ; si vous possédez l'une de ces versions de rpm, vous devez utiliser la commande `rpmbuild --rebuild`. L'exécutable `rpmbuild` est fourni dans le paquetage rpm-build. Q: J'utilise les processeurs graphiques internes nForce et nForce2 et le fichier journal X contient des avertissements du type : Not using mode "1600x1200" (exceeds valid memory bandwidth usage). R: Les processeurs graphiques intégrés ont une bande passante mémoire limitée qui restreint la résolution et la vitesse de rafraîchissement des modes demandés. Pour corriger ce problème, vous pouvez réduire la vitesse de rafraîchissement maximum en diminuant la valeur supérieure de la plage "VertRefresh" dans la section Monitor de votre fichier de configuration X. Vous pouvez également désactiver le test de la bande passante mémoire à l'aide de l'option "NoBandWidthTest" du fichier de configuration X, bien que cette solution soit déconseillée. Q: J'ai reconstruit le module du noyau NVIDIA, mais quand j'essaie de l'insérer, j'obtiens un message indiquant que certains symboles ne sont pas résolus. A. Si vous disposez de symboles non résolus, il est probable que les sources du noyau ne correspondent pas au noyau utilisé. Les sources doivent correspondre au module du noyau NVIDIA. Vérifiez que les sources du noyau sont installées et configurées pour le noyau utilisé. Q: Comment puis-je savoir si mes sources du noyau sont installées ? R: Si vous exécutez une distribution au format RPM (Red Hat, Mandrake, SuSE, etc), vous pouvez utiliser RPM pour le savoir. À une invite du shell, tapez : `rpm -qa | grep kernel` et observez la réponse. Vous devriez voir un paquetage correspondant à votre noyau (dont le nom est souvent du type kernel-2.4.18-3) et un paquetage des sources du noyau de la même version (dont le nom est souvent du type kernel-source-2.4.18-3). Si aucune des lignes ne correspond à un paquetage de sources, il vous faudra probablement l'installer. Si les versions mentionnées ne correspondent pas (par exemple, kernel-2.4.18-10 et kernel-source-2.4.18-3), vous devrez mettre à jour le paquetage des sources du noyau pour qu'il corresponde au noyau installé. Si plusieurs noyaux sont installés sur votre système, vous devez installer le paquetage des sources du noyau correspondant au noyau *utilisé* (ou vous assurer que le paquetage des sources installé correspond bien au noyau utilisé). Pour cela, faites appel à 'uname -r' et observez si les versions correspondent. Q: Pourquoi m'est-il impossible de charger le module du noyau NVIDIA que j'ai compilé pour le noyau Red Hat Linux 7.3 2.4.18-3bigmem ? R: Les fichiers d'en-tête du noyau Red Hat que Linux distribue pour le noyau Red Hat Linux 7.3 2.4.18-3bigmem sont mal configurés. Il est possible de charger le module du noyau NVIDIA précompilé pour le noyau, mais si vous souhaitez compiler vous-même les fichiers d'interface du noyau NVIDIA pour ce noyau, vous devez taper ce qui suit : ccd /lib/modules/`uname -r`/build/ make mrproper cp configs/kernel-2.4.18-i686-bigmem.config .config make oldconfig dep Remarque : Red Hat Linux fournit des fichiers d'en-tête du noyau qui sont simultanément configurés pour TOUS les noyaux d'une version de distribution particulière. Un fichier d'en-tête généré au moment de l'initialisation configure certains paramètres qui sélectionnent la bonne configuration. La reconstruction des en-têtes de noyau à l'aide des commandes ci-dessus créera uniquement des fichiers d'en-tête pour la configuration du noyau Red Hat Linux 7.3 2.4.18-3bigmem, en éliminant les fichiers d'en-tête pour les autres configurations. Q: X met longtemps (plusieurs minutes)à démarrer. Que puis-je faire ? R: La plupart des problèmes de lenteur au démarrage du serveur X sont dus à des données inexactes dans les BIOS vidéo concernant les types d'écran pouvant être connectés ou le port i2c à utiliser pour la détection. Vous pouvez éliminer ces problèmes en utilisant l'option "IgnoreDisplayDevices" du fichier de configuration X (reportez-vous à la description dans(app-d) ANNEXE D : OPTIONS DE CONFIGURATION X). Q: Pourquoi le serveur X utilise-t-il autant de mémoire ? R: Lorsque vous évaluez la quantité de mémoire utilisée par une application, vous devez faire une distinction entre la RAM physique du système et les mappages virtuels des ressources partagées. Par exemple, la plupart des bibliothèques partagées ne sont présentes qu'une seule fois dans la mémoire physique, mais sont mappées dans plusieurs processus. Cette mémoire ne doit être comptée qu'une seule fois dans le calcul de la mémoire totale utilisée. De même, la mémoire vidéo d'une carte graphique ou la mémoire registre d'un périphérique quelconque peut être mappée à plusieurs processus. Ces mappages ne consomment pas la RAM physique du système. Cette question a fréquemment fait l'objet de discussions dans les listes de diffusion sur XFree86. Consultez, par exemple l'adresse : http://marc.theaimsgroup.com/?l=xfree-xpert&m=96835767116567&w=2 L'utilitaire `pmap` décrit sur cette page et disponible à l'adresse http://web.hexapodia.org/~adi/pmap.c est un outil qui permet de faire la distinction entre les types de mappage de la mémoire. Par exemple, si `top` indique que X utilise plusieurs centaines de Mo de mémoire, la dernière ligne générée par pmap : mapped: 287020 KB writable/private: 9932 KB shared: 264656 KB indique que X utilise effectivement moins de 10 Mo de RAM système (la valeur "writable/private"). Remarquez également que X doit affecter des ressources pour le compte des clients X (le gestionnaire de fenêtres, votre navigateur Internet, etc) ; l'utilisation de la mémoire de X augmente quand davantage de clients demandent des ressources, telles que pixmaps, et diminue à mesure que vous fermez des applications X. Q: Les applications OpenGL causent une perte de mémoire considérable sur mon système ! Que faire ? R: Si votre noyau utilise la VM -rmap, vous pouvez subir une perte de mémoire en raison de l'optimisation de la gestion de la mémoire introduite dans -rmap14a. La VM -rmap a été adoptée par plusieurs distributions courantes et des pertes de mémoire ont été observées dans certains noyaux de distributions. Le problème a été corrigé dans -rmap15e. Si vous pensez que votre système a ce problème, essayez de mettre à jour votre noyau ou faites appel au fournisseur de la distribution. Q: Certains applications OpenGL (telles que Quake3 Arena) se bloquent quand je les démarre sur Red Hat Linux 9.0. R: Certaines versions du paquetage glibc livrées par Red Hat qui prennent en charge TLS ne gèrent pas correctement l'accès via dlopen() aux bibliothèques utilisant certains modèles TLS. Ce problème se manifeste, par exemple, quand Quake3 Arena utilise dlopen() pour charger la bibliothèque libGL de NVIDIA. Vous devez utiliser au moins glibc-2.3.2-11.9, disponible comme mise à jour chez Red Hat. Q: J'ai installé le pilote, mais la case à cocher 'Enable 3D Acceleration' est grisée. Que se passe-t-il ? R: La plupart des applications de configuration fournies avec les distributions ne reconnaissent le pilote accéléré de NVIDIA et ne se mettent donc pas en jour lorsque vous installez le pilote. Si votre pilote a été installé correctement, il devrait fonctionner sans problème. Q: Où puis-je trouver les tarballs ? R: Les tarballs standard ne sont plus disponibles. Le fichier .run est un tarball doté d'un script shell. Vous pouvez exécuter le fichier .run avec l'option '--extract-only' pour décompacter le tarball. Q: Où puis-je trouver des anciennes versions de pilotes ? R: Sur le site ftp://download.nvidia.com/XFree86_40/. Q: X ne restaure pas la console VGA lorsqu'il est exécuté sur un téléviseur. Le message d'erreur suivant s'affiche dans le fichier journal X : Unable to initialize the X int10 module; the console may not be restored correctly on your TV. R: Le pilote NVIDIA X utilise le module X Int10 pour enregistrer et restaurer l'état de la console sur la sortie TV. Il ne peut pas restaurer correctement la console sans faire appel au module Int10. Si vous construisez vous-même le serveur X, assurez-vous que le module Int10 a été créé. Si vous utilisez une version du serveur X fournie par une distribution Linux et que le module Int10 manque, contactez votre distributeur. Q: Lorsque vous modifiez des paramètres dans des jeux comme Quake 3 Arena ou Wolfstein Enemy Territry, le jeu se bloque et l'erreur suivante s'affiche : ...loading libGL.so.1: QGL_Init: dlopen libGL.so.1 failed: /usr/lib/tls/libGL.so.1: shared object cannot be dlopen()ed: static TLS memory too small R: Ces jeux ferment et rouvrent le pilote NVIDIA OpenGL (via dlopen()/dlclose()) dès que des paramètres sont modifiés. Certaines versions de glibc (comme celle qui est livrée avec Red Hat Linux 9) comportent un bogue perdant les entrées TLS statiques. Ce bogue glibc entraîne l'échec des rechargements successifs du pilote OpenGL. Ce problème est résolu dans les dernières versions de glibc. Consultez le bogue Red Hat n°89692 à l'adresse : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89692 Q: X se bloque pendant `startx` et le fichier journal X contient le message d'erreur suivant : (EE) NVIDIA(0): Failed to obtain a shared memory identifier. R: Le pilote OpenGL de NVIDIA et le pilote NVIDIA X ne peuvent communiquer sans mémoire partagée. Vous devez activer CONFIG_SYSVIPC dans le noyau. Q: Lorsque je tente d'installer le pilote, le programme d'installation affirme que X est en cours d'exécution alors que je l'ai quitté. Que se passe-t-il ? R: Le programme d'installation détecte la présence d'un serveur X en recherchant des occurrences de fichiers de verrouillage de X : /tmp/.X[n]-lock, où [n] correspond au numéro de l'affichage "X Display" (le programme d'installation vérifie les numéros compris entre 0 et 7). Si vous avez quitté X, mais que l'un de ces fichiers est conservé, vous devez supprimer manuellement le fichier de verrouillage. NE SUPPRIMEZ PAS ce fichier lorsque X est encore en cours d'exécution. Q: La taille des polices est mal définie après l'installation du pilote NVIDIA. R: Le problème de taille de polices est généralement dû à un moniteur indiquant une taille physique incorrecte. Conséquence : diverses applications X génèrent les polices dans un corps inapproprié. Pour vérifier la taille physique de votre moniteur telle que l'a déterminée X, exécutez : xdpyinfo | grep dimensions La taille est indiquée en pixels et en millimètres. Si les valeurs exprimées en millimètres sont très éloignées des tailles exactes, corrigez-les en ajoutant le champ DisplaySize à la section "monitor" du fichier de configuration X (reportez-vous aux pages man de XF86Config ou de xorg.conf pour de plus amples informations). Pour vérifier la valeur de taille physique indiquée par le moniteur, exécutez X en activant l'option verbose du journal : `startx -- -logverbose`. Ouvrez ensuite le fichier journal X et recherchez une ligne de ce type : (II) NVIDIA(0): Max H-Image Size [cm]: horiz.: 36 vert.: 27 (où les valeurs affichées seront différentes). Le pilote NVIDIA utilise ces valeurs pour calculer le paramètre DPI. Q: J'aimerais utiliser Valgrind avec les applications OpenGL, mais ma distribution utilise ELF TLS. Or, Valgrind ne prend pas encore en charge ELF TLS OpenGL de NVIDIA. R: Vous pouvez définir la variable d'environnement LD_ASSUME_KERNEL sur un paramètre inférieur à "2.3.99" (par exemple, `export LD_ASSUME_KERNEL 2.3.98`). Les bibliothèques OpenGL de NVIDIA contiennent une remarque relative à "OS ABI ELF" indiquant la version de noyau minimale requise pour utiliser la bibliothèque. Les bibliothèques ELF TLS OpenGL disposent d'un OS ABI 2.3.99 (le premier noyau Linux prenant en charge LDT pour ELF TLS) tandis que les autres types de bibliothèques disposent d'un OS ABI 2.2.5. Le chargeur run-time ne charge pas les bibliothèques dont le numéro de version OS ABI est supérieur à la version actuelle du noyau. La variable d'environnement LD_ASSUME_KERNEL permet de remplacer la version du noyau utilisée par le chargeur run-time dans ce test. En définissant la variable LD_ASSUME_KERNEL sur toute version de noyau inférieure à 2.3.99, vous pouvez forcer le chargeur à ne pas utiliser les bibliothèques ELF TLS OpenGL et à rétablir les bibliothèques OpenGL standard. Si, pour une raison quelconque, vous devez supprimer la remarque relative à OS ABI des bibliothèques OpenGL de NVIDIA, passez au fichier .run l'option "--no-abi-note" au cours de l'installation. __________________________________________________________________________ (sec-05) COMMENT NOUS CONTACTER __________________________________________________________________________ Un forum de discussion sur les pilotes NVIDIA pour Linux est disponible sur Internet. Pour y accéder, rendez-vous à l'adresse www.nvnews.net et suivez les liens "Forum" et "Linux Discussion Area". Vous y trouverez de précieuses informations. Vous pouvez également poser vos questions, répondre aux questions d'autres utilisateurs et consulter les questions et réponses antérieures. Si vous n'y trouvez pas tout ce dont vous avez besoin, vous pouvez contacter NVIDIA à l'adresse : Linux-bugs@NVIDIA.com. Nous vous prions cependant de lire attentivement la section FAQ figurant dans ce fichier LISEZMOI et de demander de l'aide au forum de discussion nvnews.net avant de nous envoyer un e-mail. Lorsque vous nous adressez un e-mail à l'adresse linux-bugs@nvidia.com, pensez à joindre à votre message le fichier journal nvidia-bug-report.log généré par le script nvidia-bug-report.sh (installé automatiquement avec le pilote). __________________________________________________________________________ (sec-06) AUTRES RESSOURCES __________________________________________________________________________ Linux OpenGL ABI http://oss.sgi.com/projects/ogl-sample/ABI/ NVIDIA Linux HowTo http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html OpenGL www.opengl.org Le projet XFree86 www.xfree86.org #nvidia (irc.freenode.net) __________________________________________________________________________ (app-a) ANNEXE A : PROCESSEURS GRAPHIQUES NVIDIA PRIS EN CHARGE __________________________________________________________________________ NOM DE LA PUCE NVIDIA ID PCI RIVA TNT 0x0020 RIVA TNT2/TNT2 Pro 0x0028 RIVA TNT2 Ultra 0x0029 Vanta/Vanta LT 0x002C RIVA TNT2 Modèle 64/Modèle 64 Pro 0x002D GeForce 6800 Ultra 0x0040 GeForce 6800 0x0041 GeForce 6800 GT 0x0045 Quadro FX 4000 0x004E Aladdin TNT2 0x00A0 GeForce 6800 0x00C1 GeForce 6800 LE 0x00C2 GeForce Go 6800 0x00C8 GeForce Go 6800 Ultra 0x00C9 Quadro FX Go1400 0x00CC Quadro FX Go1400 0x00CC Quadro FX 3450/4000 SDI 0x00CD Quadro FX 1400 0x00CE GeForce 6800/GeForce 6800 Ultra 0x00F0 GeForce 6600/GeForce 6600 GT 0x00F1 GeForce 6600 0x00F2 GeForce 6200 0x00F3 GeForce 6200 0x00F3 Quadro FX 3400 0x00F8 GeForce 6800 Ultra 0x00F9 GeForce PCX 5750 0x00FA GeForce PCX 5900 0x00FB Quadro FX 330/GeForce PCX 5300 0x00FC Quadro NVS 280 PCI-E/Quadro FX 330 0x00FD Quadro FX 1300 0x00FE GeForce PCX 4300 0x00FF GeForce 256 0x0100 GeForce DDR 0x0101 Quadro 0x0103 GeForce2 MX/MX 400 0x0110 GeForce2 MX 100/200 0x0111 GeForce2 Go 0x0112 Quadro2 MXR/EX/Go 0x0113 GeForce 6600 GT 0x0140 GeForce 6600 0x0141 GeForce Go 6600 0x0144 GeForce 6610 XL 0x0145 GeForce Go 6600 TE/6200 TE 0x0146 GeForce Go 6600 0x0148 Quadro FX 540 0x014E GeForce 6200 0x014F GeForce2 GTS/GeForce2 Pro 0x0150 GeForce2 Ti 0x0151 GeForce2 Ultra 0x0152 Quadro2 Pro 0x0153 GeForce 6200 TurboCache(TM) 0x0161 GeForce 6200SE TurboCache(TM) 0x0162 GeForce Go 6200 0x0164 GeForce Go 6250 0x0166 GeForce Go 6200 0x0167 GeForce Go 6250 0x0168 GeForce4 MX 460 0x0170 GeForce4 MX 440 0x0171 GeForce4 MX 420 0x0172 GeForce4 MX 440-SE 0x0173 GeForce4 440 Go 0x0174 GeForce4 420 Go 0x0175 GeForce4 420 Go 32M 0x0176 GeForce4 460 Go 0x0177 Quadro4 550 XGL 0x0178 GeForce4 440 Go 64M 0x0179 Quadro NVS 0x017A Quadro4 500 GoGL 0x017C GeForce4 410 Go 16M 0x017D GeForce4 MX 440 avec AGP8X 0x0181 GeForce4 MX 440SE avec AGP8X 0x0182 GeForce4 MX 420 avec AGP8X 0x0183 GeForce4 MX 4000 0x0185 Quadro4 580 XGL 0x0188 Quadro NVS avec AGP8X 0x018A Quadro4 380 XGL 0x018B Quadro NVS 50 PCI 0x018C GPU GeForce2 intégré 0x01A0 GPU GeForce4 MX intégré 0x01F0 GeForce3 0x0200 GeForce3 Ti 200 0x0201 GeForce3 Ti 500 0x0202 Quadro DCC 0x0203 GeForce 6800 0x0211 GeForce 6800 LE 0x0212 GeForce 6800 GT 0x0215 GeForce4 Ti 4600 0x0250 GeForce4 Ti 4400 0x0251 GeForce4 Ti 4200 0x0253 Quadro4 900 XGL 0x0258 Quadro4 750 XGL 0x0259 Quadro4 700 XGL 0x025B GeForce4 Ti 4800 0x0280 GeForce4 Ti 4200 avec AGP8X 0x0281 GeForce4 Ti 4800 SE 0x0282 GeForce4 4200 Go 0x0286 Quadro4 980 XGL 0x0288 Quadro4 780 XGL 0x0289 Quadro4 700 GoGL 0x028C GeForce FX 5800 Ultra 0x0301 GeForce FX 5800 0x0302 Quadro FX 2000 0x0308 Quadro FX 1000 0x0309 GeForce FX 5600 Ultra 0x0311 GeForce FX 5600 0x0312 GeForce FX 5600XT 0x0314 GeForce FX Go5600 0x031A GeForce FX Go5650 0x031B Quadro FX Go700 0x031C GeForce FX 5200 0x0320 GeForce FX 5200 Ultra 0x0321 GeForce FX 5200 0x0322 GeForce FX 5200LE 0x0323 GeForce FX Go5200 0x0324 GeForce FX Go5250 0x0325 GeForce FX 5500 0x0326 GeForce FX 5100 0x0327 GeForce FX Go5200 32M/64M 0x0328 Quadro NVS 280 PCI 0x032A Quadro FX 500/FX 600 0x032B GeForce FX Go53xx 0x032C GeForce FX Go5100 0x032D GeForce FX 5900 Ultra 0x0330 GeForce FX 5900 0x0331 GeForce FX 5900XT 0x0332 GeForce FX 5950 Ultra 0x0333 GeForce FX 5900ZT 0x0334 Quadro FX 3000 0x0338 Quadro FX 700 0x033F GeForce FX 5700 Ultra 0x0341 GeForce FX 5700 0x0342 GeForce FX 5700LE 0x0343 GeForce FX 5700VE 0x0344 GeForce FX Go5700 0x0347 GeForce FX Go5700 0x0348 Quadro FX Go1000 0x034C Quadro FX 1100 0x034E __________________________________________________________________________ (app-b) ANNEXE B : CONFIGURATION LOGICIELLE MINIMALE REQUISE __________________________________________________________________________ o Noyau linux 2.4.0 # cat /proc/version o XFree86 4.0.1 # XFree86 -version ou Xorg 6.7 # Xorg -version o Noyau modutils 2.1.121 # insmod -V Si vous devez construire le module du noyau NVIDIA : o binutils 2.9.5 # size --version o GNU make 3.77 # make --version o gcc 2.91.66 # gcc --version o glibc 2.0 # /lib/libc.so.6 Si vous faites la construction à partir de rpms : o spec-helper rpm # rpm -qi spec-helper Toutes les versions stables de noyaux officiels à partir de la 2.4.0 sont prises en charge. Les versions préliminaires telles que 2.4.3-pre2 ne sont pas prises en charge, à l'instar des noyaux de la série de développement, comme 2.3.x ou 2.5.x. Vous pouvez télécharger le noyau Linux sur le site www.kernel.org ou l'un de ses miroirs. binutils et gcc sont disponibles sur www.gnu.org ou l'un de ses miroirs. Si vous utilisez XFree86, mais que vous n'avez pas de fichier /var/log/XFree86.0.log, vous disposez probablement d'une version 3.x de XFree86 que vous devez mettre à jour. Si vous configurez XFree86 4.x pour la première fois, il est souvent plus facile de commencer avec l'un des pilotes disponibles en open-source avec XFree86 ('nv', 'vga' ou 'vesa'). Une fois que XFree86 fonctionne correctement avec le pilote open-source, il est simple de passer au pilote NVIDIA. Toutefois, les derniers GPU NVIDIA pourraient ne pas fonctionner avec les anciennes versions du pilote "nv" fourni avec XFree86. Par exemple, le pilote "nv" fourni avec la version 4.0.1 de XFree86 ne reconnaissait pas les processeurs de la famille GeForce2 ni la Quadro2 MXR. Ce problème a toutefois été résolu dans la version 4.0.2 de XFree86 (XFree86 est disponible sur le site www.xfree86.org). Ces paquetages de logiciels sont également disponibles auprès de votre distributeur Linux. __________________________________________________________________________ (app-c) ANNEXE C : COMPOSANTS INSTALLÉS __________________________________________________________________________ Les pilotes accélérés NVIDIA pour Linux comprennent les composants suivants (le fichier entre parenthèses est le nom complet du composant après l'installation ; "x.y.z" représente la version actuelle -- des liens symboliques appropriés sont créés pendant l'installation) : o Un pilote X (/usr/X11R6/lib/modules/drivers/nvidia_drv.o) ; le serveur X a besoin de ce pilote pour utiliser votre matériel NVIDIA. Le pilote nvidia_drv.o a une compatibilité binaire avec les versions 4.0.1 et ultérieures de XFree86 ainsi qu'avec le serveur X Xorg. o Un module d'extension GLX pour X (/usr/X11R6/lib/modules/extensions/libglx.so.x.y.z) ; le serveur X utilise ce module pour la prise en charge de glx côté serveur. o Une bibliothèque OpenGL (/usr/lib/libGL.so.x.y.z) ; cette bibliothèque fournit les points d'entrée des API pour tous les appels de fonctions OpenGL et GLX. Elle est reliée à un run-time par les applications OpenGL. o Une bibliothèque principale OpenGL (/usr/lib/libGLcore.so.x.y.z); cette bibliothèque est implicitement utilisée par libGL et libglx. Elle contient la fonctionnalité d'accélération 3D. Vous ne devez pas la charger explicitement dans votre fichier de configuration X - libglx le fait pour vous. o Deux bibliothèques XvMC (X-Video Motion Compensation) : une bibliothèque statique et une bibliothèque partagée (/usr/X11R6/lib/libXvMCNVIDIA.a, /usr/X11R6/lib/libXvMCNVIDIA.so.x.y.z) ; pour de plus amples informations, reportez-vous à (app-p) ANNEXE P : PRISE EN CHARGE DE XVMC. o Un module de noyau (/lib/modules/`uname -r`/video/nvidia.o ou /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o). Ce module de noyau permet un accès de bas niveau à votre matériel NVIDIA pour tous les composants ci-dessus. Il est généralement chargé dans le noyau au démarrage du serveur X et est utilisé par le pilote X et OpenGL. nvidia.o comporte deux parties : le coeur uniquement binaire et une interface noyau qui doit être spécialement compilée pour la version de noyau utilisée. Remarquez que le noyau Linux ne possède pas d'interface binaire homogène à l'instar du serveur X ; il est donc important que cette interface de noyau corresponde à la version du noyau utilisé. Vous pouvez soit la compiler vous-même, soit utiliser les binaires précompilés fournis pour les noyaux inclus dans certaines des distributions Linux les plus courantes. o Fichiers d'en-tête OpenGL et GLX (/usr/share/doc/NVIDIA_GLX-1.0/include/GL/gl.h, et /usr/share/doc/NVIDIA_GLX-1.0/include/GL/glx.h). Ces fichiers peuvent également être installés dans /usr/include/GL/ en passant l'option "--opengl-headers" dans le fichier .run pendant l'installation. o Les bibliothèques nvidia-tls (/usr/lib/libnvidia-tls.so.x.y.z et /usr/lib/tls/libnvidia-tls.so.x.y.z). Ces fichiers offrent la prise en charge du stockage local des threads pour les bibliothèques NVIDIA OpenGL (libGL, libGLcore, et libglx). Chaque bibliothèque nvidia-tls assure la prise en charge d'un modèle de stockage de threads particulier (ELF TLS, par exemple) et celle qui est adaptée à votre système est chargée lors de l'exécution. o L'application nvidia-installer (/usr/bin/nvidia-installer) est un outil NVIDIA pour l'installation et la mise à jour des pilotes NVIDIA. Vous trouverez une description détaillée de cet outil dans (sec-02) INSTALLATION DU PILOTE NVIDIA. Des problèmes surviendront si des applications utilisent une version de bibliothèque erronée. Ceci est le cas lorsque d'anciennes bibliothèques libGL ou que des liens symboliques obsolètes sont conservés. Si vous pensez que votre installation ne fonctionne pas correctement, vérifiez la présence des fichiers suivants (ce sont tous les fichiers des pilotes accélérés NVIDIA pour Linux, accompagnés de leurs liens symboliques) : /usr/X11R6/lib/modules/drivers/nvidia_drv.o /usr/X11R6/lib/modules/extensions/libglx.so.x.y.z /usr/X11R6/lib/modules/extensions/libglx.so -> libglx.so.x.y.z /usr/lib/libGL.so.x.y.z /usr/lib/libGL.so.x -> libGL.so.x.y.z /usr/lib/libGL.so -> libGL.so.x /usr/lib/libGLcore.so.x.y.z /usr/lib/libGLcore.so.x -> libGLcore.so.x.y.z /lib/modules/`uname -r`/video/nvidia.o, or /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o L'installation créera également les fichiers /dev : 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 ldconfig peut créer des liens symboliques incorrects lorsque le "nom .so" d'autres bibliothèques entre en conflit avec celui de bibliothèques NVIDIA. Il est conseillé de supprimer ou de renommer manuellement les bibliothèques causant des conflits (n'oubliez pas de renommer les bibliothèques pour être sûr que ldconfig ne les verra pas -- en général, l'ajout initial de "XXX" au nom d'une bibliothèque suffit), de réexécuter 'ldconfig' et de vérifier que les liens symboliques ont été correctement créés. Les bibliothèques à l'origine de conflits sont souvent "/usr/X11R6/lib/libGL.so*" et "/usr/X11R6/lib/libGLcore.so*". Après la vérification des bibliothèques, assurez-vous que l'application utilise les bonnes bibliothèques. Par exemple, dans le cas de /usr/X11R6/bin/gears, vérifiez que les bibliothèques NVIDIA sont utilisées en tapant : $ 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) Vous observerez que les fichiers utilisés pour libGL et libGLcore -- si certains d'entre eux ne correspondent pas à des bibliothèques NVIDIA, vous devez soit supprimer ces bibliothèques soit modifier votre chemin d'accès. Si vous ne savez pas à quoi correspondent certains fichiers, lisez les parties consacrées aux pointeurs dans les pages man de "ldconfig" et "ldd". __________________________________________________________________________ (app-d) ANNEXE D : OPTIONS DE CONFIGURATION X __________________________________________________________________________ Les options de pilote suivantes sont prises en charge par le pilote X NVIDIA. Vous pouvez les configurer dans les sections Screen (Écran) ou Device (Périphérique) du fichier de configuration X : Option "NvAGP" "entier" Configurez la prise en charge AGP. Argument entier possible : 0 : agp désactivé 1 : utilisation, dans la mesure du possible, de la prise en charge AGP interne de NVIDIA 2 : utilisation d'AGPGART, dans la mesure du possible 3 : utilisation de toute prise en charge agp (essayez AGPGART, puis l'AGP NVIDIA) Notez toutefois que la pris en charge d'AGP interne de NVIDIA ne peut pas fonctionner si AGPGART est compilé statiquement dans votre noyau ou est construit comme un module, mais chargé dans votre noyau (certaines distributions chargent AGPGART dans le noyau lors du démarrage). Valeur par défaut: 3 (valeur 1 jusqu'à la version 1.0-1251). Option "NoLogo" "booléen" Désactive l'apparition du logo NVIDIA au démarrage de X. Par défaut : le logo apparaît. Option "RenderAccel" "booléen" Active ou désactive l'accélération matérielle de l'extension RENDER. CETTE OPTION EST EN PHASE D'EXPÉRIMENTATION. VOUS PRENEZ DES RISQUES EN L'ACTIVANT. Il n'existe aucune suite de tests d'exactitude pour l'extension RENDER ; en conséquence, NVIDIA ne peut vérifier que l'accélération de l'extension RENDER fonctionne correctement. Par défaut : accélération matérielle de l'extension RENDER désactivée. Option "NoRenderExtension" "booléen" Désactive l'extension RENDER. Il semble que XFree86 n'offre aucune méthode de désactivation de RENDER, à part la recompilation du serveur X. Heureusement, nous pouvons contrôler ceci depuis le pilote en exportant cette option. C'est utile en profondeur 8 lorsque RENDER utiliserait grande partie de la colormap par défaut. Par défaut : RENDER est activé dans la mesure du possible. Option "UBB" "booléen" Active ou désactive Unified Back Buffer sur tout GPU Quadro (à l'exception de Quadro4 NVS) ; reportez-vous à l'annexe M pour une description d'UBB. Cette option n'a aucun effet sur les chipsets non Quadro. Par défaut : UBB est activé pour les chipsets Quadro. Option "NoFlip" "booléen" Désactive le retournement OpenGL ; reportez-vous à l'annexe M pour une description. Par défaut : OpenGL permute par retournement dans la mesure du possible. Option "DigitalVibrance" "entier" Active le contrôle de vibrance numérique (DVC). Valeurs comprises entre 0 et 255. Cette fonctionnalité n'est pas disponible sur les produits antérieurs au GeForce2. Valeur par défaut : 0. Option "Dac8Bit" "booléen" Par défaut, la plupart des chipsets Quadro utilisent une table de conversion des couleurs (LUT) de 10 bits ; en définissant cette option sur TRUE, vous pouvez forcer l'utilisation d'une LUT de 8 bits. Par défaut, utilisation d'une LUT de 10 bits, si elle est disponible. Option "Overlay" "booléen" Active le recouvrement RGB sur le moniteur de la station de travail. Cette option est uniquement prise en charge sur les Quadro4 et Quadro FX (Quadro4 NVS exclu) en profondeur 24. Si elle est activée, le serveur indique la propriété de la fenêtre racine SERVER_OVERLAY_VISUALS et GLX rapporte simple et double buffer, recouvrement 16 bits avec Z-buffer. La transparence est donnée par 0x0000 (hex). Aucune prise en charge de correction gamma n'existe dans le plan de recouvrement. Cette fonctionnalité est disponible à partir de la version 4.1.0 de XFree86 (ou (du serveur X Xorg). Les Quadro NV17/18 (c.-à-d. 500/550 XGL) présentent des restrictions supplémentaires, à savoir le recouvrement n'est pas pris en charge en mode TwinView ni avec des bureaux virtuels de taille supérieure à 2046x2047 en longueur ou en largeur (par exemple : il ne fonctionnera pas en mode 2048x1536). Les Quadro 7xx/9xx et Quadro FX offrent la fonction de recouvrement dans ces modes (TwinView ou bureaux virtuels de taille supérieure à 2046x2047), mais le recouvrement entraîne une baisse substantielle des performances. Le recouvrement sur les stations de travail RGB n'est pas pris en charge quand l'extension Composite est activée. Par défaut : désactivée. Option "CIOverlay" "booléen" Active l'affichage de l'index des couleurs sur le moniteur de la station de travail, avec les mêmes restrictions que pour l'option "Overlay" ci-dessus. Le serveur permettra l'affichage avec et sans un facteur de transparence. Modes PseudoColor de profondeur 8. L'activation du recouvrement Color Index dans les anciennes versions X serveurs à XFree86 4.3 provoquera la désactivation du fait des bogues figurant dans l'extension RENDER des anciennes versions de serveurs X. Le recouvrement d'index de couleurs sur les stations de travail n'est pas pris en charge lorsque l'extension Composite est activée. Par défaut : désactivée. Option "TransparentIndex" "entier" Lorsque des recouvrements d'index de couleurs sont activés, cette option permet à l'utilisateur de choisir quel pixel utiliser pour la transparence dans les affichages dotés de pixels transparents. Celle valeur est comprise entre 0 et 255 (Remarque : certaines applications, telles que Alias Maya, ne fonctionnent correctement que si cette valeur est égale à zéro). Par défaut : 0. Option "OverlayDefaultVisual" "booléen" Lorsque les recouvrements sont utilisés, cette option détermine comme affichage par défaut un recouvrement plaçant la fenêtre racine dans le recouvrement. Elle est déconseillées pour les recouvrements RGB. Par défaut : désactivée. Option "RandRRotation" "booléen" Permet la prise en charge de la rotation pour l'extension XRandR. Cela permet l'utilisation de l'extension de serveur X XRandR pour configurer l'orientation de l'écran via la rotation. Cette fonction est prise en charge sur le GeForce2 et le matériel supérieur utilisant la profondeur 24. Un serveur XOrg 6.8.1 ou plus récent est requis. Cette fonction ne fonctionne pas avec les recouvrements matériels, des recouvrements émulés seront utilisés en remplacement mais diminueront sensiblement les performances. Pour plus de détails, voir l'ANNEXE W. Par défaut : désactivée. Option "SWCursor" "booléen" Active ou désactive le rendu logiciel du pointeur X. Par défaut : désactivée. Option "HWCursor" "booléen" Active ou désactive le rendu matériel du pointeur X. Par défaut : activée. Option "CursorShadow" "booléen" Active ou désactive l'utilisation d'une ombre avec l'accélération matérielle du pointeur ; il s'agit d'une réplique translucide noire de votre pointeur décalée par rapport au pointeur réel. Cette option n'est disponible que sur le GeForce2 et les produits supérieurs (c.-à-d., tous sauf TNT/TNT2, GeForce 256, GeForce DDR et Quadro). Par défaut, l'ombre du pointeur est désactivée. Option "CursorShadowAlpha" "entier" La valeur alpha à appliquer à l'ombre du pointeur ; n'agit que si CursorShadow est activé. Cette valeur doit être comprise dans la plage [0, 255] -- 0 correspond à une ombre complètement transparente et 255 à une ombre complètement opaque. Valeur par défaut : 64. Option "CursorShadowXOffset" "entier" Le décalage, en pixels, vers la droite de l'ombre par rapport à l'image du pointeur réel ; n'agit que si CursorShadow est activé. Cette valeur doit être comprise dans la plage [0, 32]. Valeur par défaut : 4. Option "CursorShadowYOffset" "entier" Le décalage, en pixels, vers le bas de l'ombre par rapport à l'image du pointeur réel ; n'agit que si CursorShadow est activé. Cette valeur doit être comprise dans la plage [0, 32]. Valeur par défaut : 2. Option "ConnectedMonitor" "chaîne" Permet d'ignorer ce que le module du noyau NVIDIA détecte comme connecté à votre carte vidéo. Ceci peut s'avérer utile lorsque, par exemple, vous utilisez un commutateur KVM (clavier, vidéo, souris) et que vous êtes commuté à distance au démarrage de X. Dans ce cas, le module du noyau NVIDIA ne peut pas détecter les périphériques d'affichage connectés et le pilote X NVIDIA suppose que vous disposez d'un seul CRT. Les valeurs admises pour cette option sont "CRT" (écran cathodique), "DFP" (écran plat numérique) ou "TV" (téléviseur); Si vous utilisez TwinView, cette option peut être une liste de dispositifs d'affichage, séparés par une virgule ; par ex.: "CRT, CRT" ou "CRT, DFP". REMARQUE : tout périphérique branché dans un connecteur VGA à 15 broches est considéré par le pilote comme un CRT. "DFP" ne doit être utilisé que pour les écrans plats connectés via un port DVI. Par défaut : la chaîne est NULL. Option "UseEdidFreqs" "booléen" Cette option oblige le serveur X à utiliser les paramètres HorizSync et VertRefresh du périphérique d'affichage EDID (en sa présence). L'information de la plage EDID aura la priorité sur les plages HorizSync et VertRefresh spécifiées dans la section Monitor. Si un périphérique d'affichage ne fournit par un EDIT ou que l'EDIT ne précise aucune plage HorizSync ou VertRefresh, le serveur X utilisera par défaut les plages HorizSync et VertRefresh spécifiées dans la section Monitor. Option "IgnoreEDID" "booléen" Pour ignorer les valeurs EDID (Extended Display Identification Data) du moniteur. Les modes requis sont comparés aux valeurs EDID (en leur présence) obtenues de votre moniteur pendant la validation du mode. Certains moniteurs 'mentent' sur leurs capacités. Ignorer ces valeurs fournies par le moniteur peut être utile pour permettre la validation de certains modes, mais peut être dangereux si vous ne savez pas exactement ce que vous faites. Par défaut : utilisation des valeurs EDID. Option "NoDDC" "booléen" Synonyme de "IgnoreEDID" Option "FlatPanelProperties" "chaîne" Demande les propriétés particulières des écrans plats éventuellement connectés sous forme de liste contenant des paires de valeurs séparées par une virgule. Les deux seules propriétés actuellement disponibles sont 'Scaling' et 'Dithering'. Les valeurs admises pour 'Scaling' sont : 'default' (le pilote utilisera le cadrage courant), 'native' (le pilote utilisera le cadrage de l'écran plat, en sa présence), 'scaled' (le pilote utilisera le cadreur NVIDIA dans la mesure du possible ), 'centered' (le pilote centrera l'image dans la mesure du possible) et 'aspect-scaled' (le pilote utilisera le cadreur NVIDIA, mais conserve l'aspect correct). Les valeurs admises pour 'Dithering' sont : 'default' (le pilote décidera quand effectuer le tramage), 'enabled' (le pilote effectuera le tramage chaque fois que possible), et 'disabled' (le pilote n'effectuera jamais le tramage ). Si une propriété quelconque n'est pas spécifiée, la valeur sera 'default'. Une chaîne de propriétés peut ressembler à : "Scaling = centered, Dithering = enabled" Option "UseInt10Module" "booléen" Active l'utilisation du module Int10 XFree86 pour initialiser en douceur toutes les cartes secondaires au lieu de les poster par l'intermédiaire du module du noyau NVIDIA. Par défaut : désactivée (le téléchargement est effectué via le module du noyau NVIDIA). Option "TwinView" "booléen" Active ou désactive TwinView. Reportez-vous à l'ANNEXE I. Par défaut, TwinView est désactivé. Option "TwinViewOrientation" "chaîne" Contrôle la relation entre les deux périphériques d'affichage en cas d'utilisation de TwinView. Les valeurs possibles sont : "RightOf" "LeftOf" "Above" "Below" "Clone". Reportez-vous à l'ANNEXE I. Par défaut, la chaîne est NULL. Option "SecondMonitorHorizSync" "plage(s) de valeurs" Cette option est similaire à l'entrée du paramètre HorizSync dans la section Monitor, mais se réfère au second moniteur si vous utilisez TwinView. Reportez-vous à l'ANNEXE I. Par défaut, aucune plage. Option "SecondMonitorVertRefresh" "plage(s) de valeurs" Cette option est similaire à l'entrée du paramètre VertRefresh dans la section Monitor, mais se réfère au second moniteur si vous utilisez TwinView. Reportez-vous à l'ANNEXE I. Par défaut, aucune plage. Option "MetaModes" "chaîne" Cette option décrit la combinaison de modes à utiliser sur chaque moniteur si vous utilisez TwinView. Reportez-vous à l'ANNEXE I. Par défaut, la chaîne est NULL. Option "NoTwinViewXineramaInfo" "booléen" Si vous utilisez TwinView, le pilote X NVIDIA fournit normalement une extension Xinerama que les clients X tels que les gestionnaires de fenêtres) peuvent utiliser pour connaître la configuration TwinView actuelle. Cette option permet de désactiver ce comportement, étant donné qu'il peut perturber certains gestionnaires de fenêtre. Par défaut, l'information Xinerama de TwinView est fournie. Option "TVStandard" "chaîne" Reportez-vous à (app-j) ANNEXE J : CONFIGURATION TV-OUT. Option "TVOutFormat" "chaîne" Reportez-vous à (app-j) ANNEXE J : CONFIGURATION TV-OUT. Option "TVOverScan" "Valeur décimale comprise entre 0.0 et 1.0" Les valeurs admises sont comprises entre 0.0 et 1.0. Reportez-vous à (app-j) ANNEXE J : CONFIGURATION TV-OUT. Option "Stereo" "entier" Permet des affichages stéréo à quadruple tampons sur Quadro. Nombre entier indiquant le type de lunettes stéréo utilisées : 1 - Lunettes DDC. Le signal de synchronisation est envoyé aux lunettes via le DDC vers le moniteur. Il y a généralement un câble traversant entre le moniteur et la carte vidéo. 2 - Lunettes "Blueline". Il y a généralement un câble traversant entre le moniteur et la carte vidéo. Les lunettes savent quel oeil afficher en fonction de la longueur de la ligne bleue visible en bas de l'écran En utilisant ce mode, la dimension Y de la fenêtre racine sera de un pixel plus courte que demandé. Ce mode ne fonctionne pas avec des fenêtres racines virtuelles de taille supérieure à la fenêtre racine visible (desktop panning). 3 - Prise en charge de la stéréo embarquée ("onboard"). Ne se trouve généralement que sur les cartes professionnelles. Les lunettes sont connectées via un connecteur DIN à l'arrière de la carte vidéo. 4 - TwinView clone mode stéréo (aka "passive" stéréo). Sur les cartes vidéo qui prennent en charge TwinView, l'oeil gauche est affiché sur le premier écran et l'oeil droit sur le second. Cette option s'utilise généralement avec des projecteurs spéciaux pour obtenir 2 images polarisées visibles à l'aide de lunettes polarisées. Pour utiliser ce mode stéréo, vous devez également configurer TwinView en mode clone en utilisant les même valeurs de résolution, panning offset et panning domains sur chaque écran. Le mode stéréo n'est disponible que sur les cartes Quadro. Les options Stéréo 1, 2 et 3 (aka, "active" stereo) peuvent être utilisées avec TwinView, si tous les modes de chaque métamode ont des valeurs de synchronisation identiques. Consultez l'annexe L (app-l), MODES DE PROGRAMMATION, pour savoir si les modes de vos métamodes sont identiques. Il est inutile d'appliquer ces conditions à l'option Stéréo 4 ("passive" stereo). Actuellement, la stéréo peut être "bizarre" sur la Quadro originale (NV10) et le retournement gauche-droite peut être confus. Nous essayons de corriger ce problème pour une version ultérieure. Par défaut : le mode stéréo est désactivé. Les options stéréo 1, 2 et 3 (aka "active" stereo) ne sont pas prises en charge sur les écrans plats numériques. Option "AllowDFPStereo" "booléen" Par défaut, le pilote NVIDIA X procède à une vérification qui désactive la stéréo active (options stéréo 1, 2 et 3) si l'écran X utilise un DFP. L'option "AllowDFPStereo" omet cette vérification. Option "NoBandWidthTest" "booléen" Pendant la validation de mode, le pilote X vérifie si un mode donné respecte les contraintes de la bande passante mémoire du matériel. Cette option désactive ce test. Par défaut : le test de la bande passante mémoire est effectué. Option "IgnoreDisplayDevices" "chaîne" Cette option dit au module du noyau NVIDIA d'ignorer complètement les classes de périphériques d'affichage indiquées pendant le contrôle des périphériques connectés. Vous pouvez spécifier une liste de "CRT","DFP" et "TV", séparés par une virgule. Par exemple : "IgnoreDisplayDevices" "DFP, TV" empêchera le pilote NVIDIA d'essayer de détecter si des écrans plats ou des téléviseurs sont connectés. Généralement, cette option est inutile ; toutefois, certains BIOS de vidéo contiennent des informations incorrectes sur les périphériques d'affichage pouvant être connectés ou concernant le port i2c à utiliser pour la détection. Ces erreurs peuvent ralentir considérablement le démarrage de X. Si X est très lent au démarrage, vous pouvez indiquer au pilote NVIDIA d'ignorer les périphériques d'affichage qui ne sont pas connectés. REMARQUE : tout périphérique branché dans un connecteur VGA à 15 broches est considéré par le pilote comme un CRT. "DFP" ne doit être utilisé que pour les écrans plats connectés via un port DVI. Option "MultisampleCompatibility" "booléen" Active ou désactive l'utilisation des tampons multisample avant et arrière. Bien que cela exige plus de mémoire, cette opération est nécessaire pour corriger la sortie dans le cas d'un rendu sur les tampons multisample avant et arrière ou d'un FSAA emboutissable. Cette option est nécessaire pour corriger le fonctionnement de SoftImage XSI. Par défaut : un tampon multisample unique est partagé entre les tampons avant et arrière. Option "NoPowerConnectorCheck" "booléen" Le pilote X de NVIDIA abandonne l'initialisation du serveur X s'il détecte un GPU nécessitant un connecteur d'alimentation externe sans ce type de connecteur branché. Cette option permet de désactiver ce test. Par défaut : le test du connecteur d'alimentation est effectué. Option "XvmcUsesTextures" "booléen" Oblige XvMC à utiliser le moteur 3D pour les requêtes XvMCPutSurface plutôt que le recouvrement vidéo. Par défaut : le recouvrement vidéo est utilisé si disponible. Option "AllowGLXWithComposite" "booléen" Active GLX même lorsque l'extension X Composite est chargée. ATTENTION : ACTIVATION À VOS RISQUES ET PÉRILS. Les applications OpenGL ne s'afficheront pas correctement dans de nombreuses circonstances lorsque ce paramètre est activé. Par défaut : GLX est désactivé quand l'extension Composite est chargée. Option "ExactModeTimingsDVI" "booléen" Impose l'initialisation du serveur X selon les temporisations exactes spécifiées dans ModeLine. Par défaut : pour les périphériques DVI, le serveur X s'initialise avec le mode le plus proche dans la liste EDID. __________________________________________________________________________ (app-e) ANNEXE E : CONFIGURATION DES VARIABLES D'ENVIRONNEMENT OPENGL __________________________________________________________________________ ANTI-CRÉNELAGE DE LA SCÈNE COMPLÈTE (FSAA) L'anti-crénelage (ou antialiasing) est une technique qui permet d'atténuer les bords "en escalier" des objets graphiques d'une scène. L'anti-crénelage de la scène complète est pris en charge sur les GeForce et les processeurs plus récents. En définissant la variable d'environnement, vous pouvez activer l'anti-crénelage de la scène complète dans n'importe quelle application OpenGL sur ces GPU. Il existe plusieurs méthodes d'anti-crénelage que vous pouvez choisir en configurant correctement la variable d'environnement __GL_FSAA_MODE. Notez que les performances peuvent diminuer avec l'augmentation de nombre d'échantillons prélevés pendant le rendu FSAA. Les tableaux suivants indiquent les valeurs possibles de __GL_FSAA_MODE et leur effet sur les différents processeurs graphiques NVIDIA. __GL_FSAA_MODE GeForce, GeForce2, Quadro et Quadro2 Pro ----------------------------------------------------------------------- 0 FSAA désactivé 1 FSAA désactivé 2 FSAA désactivé 3 Super-échantillonnage 1.5 x 1.5 4 Super-échantillonnage 2 x 2 5 FSAA désactivé 6 FSAA désactivé 7 FSAA désactivé __GL_FSAA_MODE GeForce4 MX, GeForce4 4xx Go, Quadro4 380,550,580 XGL et Quadro4 NVS ----------------------------------------------------------------------- 0 FSAA désactivé 1 Multi-échantillonnage bilinéaire 2x 2 Multi-échantillonnage Quincunx 2x 3 FSAA désactivé 4 Super-échantillonnage 2 x 2 5 FSAA désactivé 6 FSAA désactivé 7 FSAA désactivé __GL_FSAA_MODE GeForce3, Quadro DCC, GeForce4 Ti, GeForce4 4200 Go, et Quadro4 700,750,780,900,980 XGL ----------------------------------------------------------------------- 0 FSAA désactivé 1 Multi-échantillonnage bilinéaire 2x 2 Multi-échantillonnage Quincunx 2x 3 FSAA désactivé 4 Multi-échantillonnage bilinéaire 4x 5 Multi-échantillonnage gaussien 4x 6 Multi-échantillonnage bilinéaire 2x par super-échantillonnage 4x 7 FSAA désactivé __GL_FSAA_MODE GeForce FX, Quadro FX ----------------------------------------------------------------------- 0 FSAA désactivé 1 Multi-échantillonnage bilinéaire 2x 2 Multi-échantillonnage Quincunx 2x 3 FSAA désactivé 4 Multi-échantillonnage bilinéaire 4x 5 Multi-échantillonnage gaussien 4x 6 Multi-échantillonnage bilinéaire 2x par super-échantillonnage 4x 7 Multi-échantillonnage bilinéaire 4x par super-échantillonnage 4x 8 Multi-échantillonnage bilinéaire 4x par super-échantillonnage 2x (disponible sur les GPU GeForce FX et ultérieurs ; pas disponible sur les GPU Quadro) FILTRAGE ANISOTROPE DE TEXTURE Le filtrage anisotrope automatique de texture peut être activé en définissant la variable d'environnement __GL_LOG_MAX_ANISO. Les valeurs possibles sont : 0 Filtrage anisotrope désactivé 1 Filtrage anisotrope 2x 2 Filtrage anisotrope 4x 3 Filtrage anisotrope 8x 4 Filtrage anisotrope 16x Les filtrages 4x et supérieurs sont uniquement disponibles sur les GPU GeForce3 ou plus récents ; le 16x est uniquement disponible sur les GPU GeForce 6800 ou plus récents. SYNCHRONISATION VBLANK Le réglage de la variable d'environnement __GL_SYNC_TO_VBLANK sur une valeur différente de zéro obligera glXSwapBuffers à se synchroniser sur la vitesse de rafraîchissement vertical de votre moniteur (effectue une permutation uniquement pendant la période de rafraîchissement vertical). Lorsque __GL_SYNC_TO_VBLANK est utilisé avec TwinView, OpenGL est synchronisé avec un seul périphérique d'affichage ; cela peut générer des distorsions sur le périphérique d'affichage qui n'est pas synchronisé avec OpenGL. Vous pouvez utiliser la variable d'environnement __GL_SYNC_DISPLAY_DEVICE pour indiquer le périphérique d'affichage à synchroniser avec OpenGL. Vous devez affecter le nom d'un périphérique d'affichage à cette variable d'environnement ; par exemple "CRT-1". Sur la ligne "Connected display device(s):" de votre fichier journal X, consultez la liste des périphériques d'affichage installés et leur nom. DÉSACTIVATION DES FONCTIONNALITÉS SPÉCIFIQUES DE L'UNITÉ CENTRALE Le réglage de la variable d'environnement __GL_FORCE_GENERIC_CPU sur une valeur différente de zéro empêche l'utilisation de fonctionnalités spécifiques de l'UC, telles que MX, SSE ou 3DNOW!. L'utilisation de cette option peut entraîner une baisse des performances. Elle peut s'avérer pratique si elle est utilisée avec certains logiciels, tels que le logiciel de débogage de mémoire Valgrind. __________________________________________________________________________ (app-f) ANNEXE F : CONFIGURATION DE L'AGP __________________________________________________________________________ Vous avez le choix entre plusieurs configurations de l'AGP avec le module du noyau NVIDIA : vous pouvez décider d'utiliser le module AGP de NVIDIA (NVAGP)ou le module AGP fourni avec le noyau Linux (AGPGART). Ce dernier est contrôlé via l'option "NvAGP" de votre fichier de configuration X : Option "NvAgp" "0" ... prise en charge d'AGP désactivée Option "NvAgp" "1" ... utilisation de NVAGP, si possible Option "NvAgp" "2" ... utilisation d'AGPGART, si possible Option "NvAGP" "3" ... tentative d'utilisation d'AGPGART et, en cas d'échec, de NVAGP La valeur par défaut est 3 (jusqu'après la version 1.0-1251, la valeur par défaut était 1). Vous devez utiliser le module AGP qui fonctionne le mieux avec votre chipset AGP. Si vous avez des problèmes de stabilité, essayez de démarrer en désactivant l'AGP et observez si le problème est résolu. Ensuite, vous pouvez faire un essai avec l'un des autres modules AGP. Vous pouvez demander l'état AGP courant à un moment quelconque via l'interface du système de fichiers /proc (consultez l'ANNEXE O : INTERFACE PROC). Si vous voulez utiliser le module AGPGART de Linux, celui-ci doit être compilé avec votre noyau et peut être soit lié statiquement soit construit en tant que module. Le support AGP NVIDIA ne peut pas être utilisé si AGPGART est chargé dans le noyau. Il est conseillé de compiler AGPGART comme module et de s'assurer qu'il n'est pas chargé si vous utilisez l'AGP NVIDIA. Notez également que si vous changez les pilotes AGP, vous devez généralement redémarrer le système avant que les changements ne prennent effet. Les chipsets AGP suivants sont pris en charge par l'AGP NVIDIA ; pour tous les autres chipsets, il est conseillé d'utiliser le module AGPGART. o Intel 440LX o Intel 440BX o Intel 440GX o Intel 815 ("Solano") o Intel 820 ("Camino") o Intel 830 o Intel 840 ("Carmel") o Intel 845 ("Brookdale") o Intel 845G o Intel 850 ("Tehama") o Intel 855 ("Odem") o Intel 860 ("Colusa") o Intel 865G ("Springdale") o Intel 875P ("Canterwood") o Intel E7205 ("Granite Bay") o Intel E7505 ("Placer") o AMD 751 ("Irongate") o AMD 761 ("IGD4") o AMD 762 ("IGD4 MP") o AMD 8151 ("Lokar") o VIA 8371 o VIA 82C694X o VIA KT133 o VIA KT266 o VIA KT400 o VIA P4M266 o VIA P4M266A o VIA P4X400 o VIA K8T800 o RCC CNB20LE o RCC 6585HE o Micron SAMDDR ("Samurai") o Micron SCIDDR ("Scimitar") o NVIDIA nForce o NVIDIA nForce2 o NVIDIA nForce3 o ALi 1621 o ALi 1631 o ALi 1647 o ALi 1651 o ALi 1671 o SiS 630 o SiS 633 o SiS 635 o SiS 645 o SiS 646 o SiS 648 o SiS 648FX o SiS 650 o SiS 655FX o SiS 730 o SiS 733 o SiS 735 o SiS 745 o SiS 755 o ATI RS200M Si vous rencontrez des problèmes de stabilité avec l'AGP, prenez connaissance des informations suivantes : o Prise en charge de l'extension de format de page sur les processeurs Athlon Certains noyaux Linux ont un bogue d'attribut de cache causant des conflits avec le cache spéculatif avancé dans les nouveaux processeurs de la famille AMD d'Athlon (AMD Athlon XP, AMD Athlon 4, AMD Athlon MP et AMD Duron Modèles 6 et supérieurs). Ce bogue de noyau se manifeste généralement en cas d'utilisation intensive de l'accélération graphique 3D avec une carte graphique AGP. Les distributions Linux basées sur le noyau 2.4.19 ou suivant *doivent* intégrer le correctif. Pour les noyaux précédents, l'utilisateur doit s'assurer lui-même qu'une petite portion du cache spéculatif avancé est désactivée (normalement en appliquant un correctif sur le noyau) et qu'une option d'amorçage est spécifiée de manière à appliquer l'ensemble du correctif. Le pilote NVIDIA désactive automatiquement la petite portion de cache spéculatif avancé pour les processeurs AMD affectés sans besoin de corriger le noyau ; il peut même être utilisé sur les noyaux qui contiennent déjà le correctif. De plus, pour les noyaux plus anciens, l'utilisateur accomplit la portion de l'option d'amorçage du correctif en désactivant explicitement les pages 4 Mo. Il peut le faire depuis la ligne de commande d'amorçage (boot) en tapant : mem=nopentium Ou en ajoutant la ligne suivante à etc/lilo.conf : append = "mem=nopentium" o Configuration de l'option "drive strength AGP" dans le BIOS (cartes mères VIA) La plupart des cartes mères VIA permettent de configurer l'option "drive strength AGP" du BIOS système. Le réglage de cette option a de fortes répercussions sur la stabilité du système. La plage comprise entre 0xEA et 0xEE semble être idéale pour le matériel NVIDIA. Le réglage d'un quartet quelconque sur 0xF cause généralement de sérieux problèmes de stabilité. Si vous décidez de tester ce réglage, vous le faites à vos risques et devez savoir que si vous utilisez des valeurs incorrectes, le système pourrait ne plus redémarrer tant que vous ne le réinitialisez pas (avec une carte graphique PCI ou en rétablissant les valeurs par défaut du BIOS). o Version du BIOS système Assurez-vous de disposer de la dernière version du BIOS système fournie par le fabricant de la carte. o Débit AGP Si le débit AGP utilisé entraîne des verrouillages, vous pouvez diminuer la valeur du paramètre. Pour ce faire, extrayez le fichier .run : sh NVIDIA-Linux-x86-1.0-7174-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-7174-pkg1/usr/src/nv/ Modifiez ensuite os-registry.c en apportant les modifications suivantes : - static int NVreg_ReqAGPRate = 7; + static int NVreg_ReqAGPRate = 4; /* force le débit AGP sur 4x */ ou + static int NVreg_ReqAGPRate = 2; /* force le débit AGP sur 2x */ ou + static int NVreg_ReqAGPRate = 1; /* force le débit AGP sur 1x */ et activez le paramètre "ReqAGPRate" : - { NULL, "ReqAGPRate", &NVreg_ReqAGPRate, 0 }, + { NULL, "ReqAGPRate", &NVreg_ReqAGPRate, 1 }, Enfin, recompilez et chargez le nouveau module de noyau. Sur les cartes mères Athlon dotées du chipset VIA KX133 ou 694X (par ex. la carte mère ASUS K7V), les pilotes NVIDIA utilisent pas défaut le mode AGP 2x pour palier à l'insuffisance du pilote sur l'un des signaux. Vous pouvez forcer AGP 4x en réglant NVreg_EnableVia4x sur 1, toutefois le système risque de devenir instable. Sur les chipsets ALi1541 et ALi1647, les pilotes NVIDIA désactivent la fonction AGP afin de remédier aux problèmes de cadence et d'intégrité des signaux. Vous pouvez forcer l'activation de l'AGP sur ces chipsets en définissant NVreg_EnableALiAGP sur 1. Le système peut toutefois devenir instable. Les premières révisions du SBIOS pour la carte mère ASUS A7V8X-X KT400 configurent mal le chipset lorsqu'une carte graphique AGP 2.x est installée. Si X se bloque sur votre système ASUS KT400 équipé d'AGPGART ou de NvAGP pour Linux et que la carte graphique installée n'est pas un périphérique AGP 8x, assurez-vous d'avoir installé la dernière version du SBIOS. __________________________________________________________________________ (app-g) ANNEXE G : PROBLÈMES SPÉCIFIQUES DES SYSTÈMES ALI __________________________________________________________________________ Les astuces suivantes peuvent vous aider à corriger les problèmes de stabilité des systèmes ALI : o Désactivez TURBO AGP MODE dans le BIOS. o Si vous utilisez P5A, effectuez une mise à jour vers le BIOS 1002 bêta 2. o Si vous utilisez 1007, 1007A ou 1009, réglez le temps de récupération E/S sur 4 cycles. o AGP est désactivé par défaut sur certains chipsets ALi (ALi1541, ALi1647) pour corriger les sérieux problèmes de stabilité du système avec ces chipsets. Reportez-vous aux commentaires sur NVreg_EnableALiAGP dans os-registry.c pour forcer l'utilisation de l'AGP. __________________________________________________________________________ (app-h) ANNEXE H : PROBLÈMES SPÉCIFIQUES DES SYSTÈMES TNT __________________________________________________________________________ La plupart des problèmes liés aux cartes SGRAM/SDRAM TNT devraient être résolus. Il peut toutefois arriver que le pilote ne fonctionne pas parce que le BIOS installé sur votre carte vidéo n'est pas le bon. Si ce pilote échoue, procédez comme suit : o Observez votre moniteur au démarrage du système. Le premier écran (qui reste affiché très peu de temps), indique le type de mémoire vidéo de votre carte, qui peut être une SGRAM ou une SDRAM. o Modifiez le fichier "os-registry.c" depuis les sources du module du noyau. Recherchez la variable "NVreg_VideoMemoryTypeOverride" et entrez la valeur correspondant à votre type de mémoire (valeur numérique sur la ligne juste au dessus de la variable). o Cette variable n'étant généralement pas utilisée, remplacez "#if 0", qui se trouve environ 10 lignes au-dessus de la variable, par "#if 1". o Reconstruisez et réinstallez le nouveau pilote ("make"). __________________________________________________________________________ (app-i) ANNEXE I : CONFIGURATION DE TWINVIEW __________________________________________________________________________ TwinView n'est pris en charge que sur les GPU NVIDIA compatibles avec le double affichage, tels que les GeForce2 MX, GeForce2 Go, Quadro2 MXR, Quadro2 Go et tous les GPU GeForce4, Quadro4, GeForce FX ou Quadro FX. Renseignez-vous auprès de votre revendeur pour savoir si votre carte vidéo prend en charge TwinView. TwinView permet à deux écrans (écrans plats numériques, CRT et TV) d'afficher le contenu d'un seul écran X dans une configuration arbitraire quelconque. Cette méthode d'affichage multiple offre plusieurs avantages par rapport à d'autres techniques (telles que Xinerama) : o Utilisation d'un seul écran X. Le pilote NVIDIA dissimule toutes les informations du serveur X concernant l'affichage multiple ; le serveur X considère qu'un seul écran est utilisé. o Les deux écrans partagent la même mémoire image. Par conséquent, toutes les fonctionnalités présentes sur un seul écran (par ex. accélération OpenGL) sont disponibles sur TwinView. o Aucune autre information n'est nécessaire pour l'émulation d'un seul bureau. Si vous souhaitez utiliser chaque périphérique d'affichage comme écran X distinct, reportez-vous à (app-r) ANNEXE R : CONFIGURATION DE PLUSIEURS ÉCRANS X SUR UNE CARTE. OPTIONS TWINVIEW DE CONFIGURATION X Pour activer TwinView, vous devez ajouter les options suivantes dans la section "Device" de votre fichier de configuration X : Option "TwinView" Option "MetaModes" "" Vous devez également spécifier l'une des paires d'options suivantes : Option "SecondMonitorHorizSync" "" Option "SecondMonitorVertRefresh" "" ou : Option "HorizSync" "" Option "VertRefresh" "" Vous pouvez également spécifier les options suivantes (ces options sont facultatives) : Option "TwinViewOrientation" "" Option "ConnectedMonitor" "" Chacune de ces options est décrite plus en détails ci-dessous : o TwinView Cette option est nécessaire pour activer TwinView ; si elle n'a pas été ajoutée, toutes les options TwinView seront ignorées. o SecondMonitorHorizSync, SecondMonitorVertRefresh Ces deux options spécifient les contraintes du second moniteur. Les valeurs entrées respectent la même convention que celles de "HorizSync" et "VertRefresh" dans la section Monitor. Comme décrit dans la man page XF86Config, les plages peuvent être une liste de valeurs distinctes séparées par un virgule et/ou deux valeurs distinctes séparées par un tiret. HorizSync est exprimé en kHz et VertRefresh en Hz. Si vous pouvez compter sur les EDIT des périphériques d'affichage, utilisez l'option "UseEdidFreqs" au lieu des ces options (vous trouverez une description de l'option "UseEdidFreqs" dans l'ANNEXE D). o HorizSync, VertRefresh Déterminer quel écran d'affichage est considéré comme le "premier" et lequel est défini comme le "second" n'est pas toujours aisé. C'est pourquoi vous pouvez utiliser ces options au lieu des versions SecondMonitor. Grâce à ces options, vous pouvez définir une liste de plages de fréquences délimitées par des points-virgules, chacune d'entre elles étant associée de manière facultative à un nom de périphérique d'affichage. Exemple : Option "HorizSync" "CRT-0: 50-110; DFP-0: 40-70" Option "VertRefresh" "CRT-0: 60-120; DFP-0: 60" Pour de plus amples informations, reportez-vous à l'Annexe traitant des noms des périphériques d'affichage. o MetaModes Un MetaMode décrit le mode à utiliser sur chaque écran à un moment donné. Les MetaModes listent les combinaisons de modes et la séquence dans laquelle ils doivent être utilisés. Lorsque le pilote NVIDIA dit à X quels sont les modes disponibles, il lui communique en fait le bounding box minimum du MetaMode, alors que le mode "per display device" est maintenu à l'intérieur du pilote. Dans la syntaxe des MetaModes, les modes contenus à l'intérieur d'un MetaMode sont séparés par une virgule et les MetaModes multiples sont séparés par des points-virgules. Par exemple : ", ; , " où est le nom du mode à utiliser sur l'écran 0 simultanément à utilisé sur l'écran 1. Une commutation de mode causera ensuite l'utilisation de sur l'écran 0 et de sur l'écran 1. Voici une entrée réelle de MetaMode extraite du fichier d'exemple de configuration X : Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768" Si vous voulez qu'un écran ne soit pas actif pour un MetaMode donné, vous pouvez utiliser "NULL" comme nom du mode ou simplement omettre complètement le nom du mode : "1600x1200, NULL; NULL, 1024x768" ou "1600x1200; , 1024x768" Facultativement, les noms de modes peuvent être suivis par une description de l'offset permettant de contrôler la position des écrans dans l'espace d'affichage virtuel ; par ex. : "1600x1200 +0+0, 1024x768 +1600+0; ..." Les descriptions de l'offset respectent les conventions utilisées dans l'option de ligne de commande "-geometry" de X ; les offsets positifs et négatifs sont valides, mais les valeurs d'offsets négatives ne sont pas admises si la taille de l'écran virtuel est définie dans le fichier de configuration X. Si aucun offset n'est spécifié pour un MetaMode, les offsets seront calculés en fonction de la valeur entrée pour l'option TwinViewOrientation (voir ci-dessous). Notez que si des offsets sont indiqués pour l'un quelconque des modes dans un seul MetaMode, ces offsets seront appliqués à tous les modes à l'intérieur de ce MetaMode ; dans ce cas, le système suppose que les offsets sont +0+0 s'ils n'ont pas été spécifiés. Si la taille de l'écran virtuel n'est pas entrés de manière explicite, elle sera calculée comme étant le bounding box de tous les bounding boxes des MetaModes. Les MetaModes dont le bounding box est plus grand que la taille de l'écran virtuel entrée de manière explicite seront rejetés. Il est également possible de modifier une chaîne de MetaMode en spécifiant un "Panning Domain" ; par ex. : "1024x768 @1600x1200, 800x600 @1600x1200" Un "Panning Domain" correspond à la zone dans laquelle peut se déplacer la fenêtre d'affichage d'un écran pour suivre la souris. Avec TwinView, le panoramique est effectué sur deux niveaux : le premier est un panoramique de la fenêtre d"affichage d'un seul écran à l'intérieur de son panning domain, tant que la fenêtre est contenue dans le bounding box du MetaMode. Dès que la souris sort du bounding box du MetaMode, un panoramique est effectué sur l'intégralité de ce MetaMode (c.-à.d. sur tous les périphériques d'affichage) pour suivre la souris dans l'écran virtuel. Notez que les panning domains de chaque périphérique d'affichage sont accrochés par défaut dans la position de leurs fenêtres d'affichage, de sorte ces fenêtres d'affichage restent par défaut "verrouillées" ensemble et n'effectuent que le second type de mouvement. L'utilisation des panning domains est surtout utile pour éliminer les zones mortes de l'écran virtuel, qui sont inaccessibles lorsque les écrans ont différentes résolutions. Par exemple : "1600x1200, 1024x768" donne une région inaccessible au-dessous de l'écran de 1024x768. En spécifiant, pour le second écran, un panning domain de : "1600x1200, 1024x768 @1024x1200" il est possible d'accéder aux zones mortes et de faire un panoramique vers le haut et vers le bas de la fenêtre d'affichage 1024x768 dans le panning domain de 1024x1200 . Il est possible d'associer des offsets à des panning domains pour positionner les panning domains dans l'espace d'affichage virtuel (notez que l'offset décrit le panning domain et n'agit que sur la fenêtre d'affichage en l'obligeant à être contenue à l'intérieur du panning domain). L'exemple suivant décrit deux modes, ayant chacun un panning domain de 1900 pixels de largeur, avec le second écran placé au-dessous du premier : "1600x1200 @1900x1200 +0+0, 1024x768 @1900x768 +0+1200" Comme il est souvent difficile de déterminer quel mode sera utilisé au sein d'un MetaMode sur chaque périphérique d'affichage, il est possible d'ajouter à l'avance les descriptions des modes pour un MetaMode donné en spécifiant le nom du périphérique d'affichage. Exemple : "CRT-0: 1600x1200, DFP-0: 1024x768" Si rien n'est spécifié pour les MetaModes, le pilote X utilisera les modes indiqués dans la sous-section "Display" correspondante pour essayer de placer des modes adéquats sur chaque écran. o TwinViewOrientation Cette option détermine la position du second écran par rapport au premier écran X virtuel, si aucun offset n'a été spécifié dans les MetaModes. Les valeurs admises sont : "RightOf" (par défaut) "LeftOf" "Above" "Below" "Clone" Si vous avez entré "Clone", les deux écrans auront un offset de 0,0. Comme il est souvent difficile de déterminer quel périphérique d'affichage est considéré comme le "premier" et lequel est défini comme le "second", TwinViewOrientation peut se révéler source de confusion. Vous pouvez clarifier le paramètre TwinViewOrientation en spécifiant explicitement les noms des périphériques d'affichage afin d'indiquer qu'un tel se positionne par rapport à un tel. Exemple : "CRT-0 LeftOf DFP-0" o ConnectedMonitor Cette option permet d'ignorer ce que le module du noyau NVIDIA détecte comme étant connecté à votre carte vidéo. Elle peut être utile, par exemple, si l'un de vos écrans ne supporte pas la détection DDC (Display Data Channel). Les valeurs admises sont présentées sous forme de liste de noms de périphériques d'affichage séparés par des virgules. Exemple : "CRT-0, CRT-1" "CRT" "CRT-1, DFP-0" AVERTISSEMENT : cette option remplace les noms des périphériques d'affichage détectés par le module noyau NVIDIA et n'est presque jamais nécessaire. Vous n'en aurez réellement besoin que dans le cas d'un périphérique d'affichage non détecté, soit parce qu'il ne fournit pas d'informations DDC soit parce qu'il se trouve de l'autre côté d'un commutateur KVM (clavier-vidéo-souris). Dans la plupart des cas, il est recommandé de ne pas définir cette option. À l'instar des autres entrées de configuration X, les espaces ne sont pas pris en compte et la casse des caractères n'est pas respectée. FAQ SUR TWINVIEW : Q: Mon second moniteur ne fonctionne pas. Quel est le problème ? R: Les moniteurs non compatibles DDC (Display Data Channel) ne peuvent pas être détectés par votre carte NVIDIA (la plupart des anciens moniteurs ne sont pas compatibles). Dans ce cas, vous devez dire explicitement au pilote NVIDIA X que vous êtes connecté, en utilisant l'option "ConnectedMonitor" ; par ex. : Option "ConnectedMonitor" "CRT, CRT" Q: Les gestionnaires de fenêtres sauront-ils placer les fenêtres correctement (par ex. en évitant de les placer à cheval entre deux écrans ou dans des zones inaccessibles du bureau virtuel) ? R: Oui. Le pilote X de NVIDIA fournit une extension Xinerama qui permet aux clients X (comme les gestionnaires de fenêtres) d'appeler XineramaQueryScreens() pour connaître la configuration TwinView courante. Notez que le protocole Xinerama ne peut pas informer les clients des changements de configuration. Aussi, si vous changez de MetaMode, votre gestionnaire de fenêtres ne le saura pas et continuera à se baser sur votre ancienne configuration. En utilisant l'extension Xinerama avec l'extension XF86VidMode, les gestionnaires de fenêtres devraient être capables de déterminer la configuration TwinView à tout moment. Malheureusement, certains gestionnaires de fenêtres ne savent pas interpréter les informations fournies par XineramaQueryScreens() ; pour corriger ce problème, vous pouvez désactiver la communication de la position des écrans TwinView à l'aide de l'option "NoTwinViewXineramaInfo" dans le fichier de configuration X (reportez-vous à l'annexe D pour plus de détails). N'oubliez pas que le pilote NVIDIA ne peut pas fournir l'extension Xinerama si l'extension Xinerama du serveur X est déjà utilisée. L'extension Xinerama du pilote NVIDIA ne pourra pas être installée si Xinerama a été explicitement spécifié dans le fichier de configuration X ou sur la ligne de commande du serveur X. Par conséquent, vérifiez que le fichier journal du serveur X ne contient pas la ligne (++) XineramR: enabled si vous voulez que le pilote NVIDIA fournisse l'extension Xinerama dans TwinView. Une autre solution consiste à utiliser les panning domains pour éliminer les zones inaccessibles de l'écran virtuel (reportez-vous à la description des MetaModes ci-dessus). Une troisième solution est d'utiliser deux écrans X distincts, plutôt que TwinView. Reportez-vous à (app-r) ANNEXE R : CONFIGURATION DE PLUSIEURS ÉCRANS X SUR UNE CARTE; Q: Pourquoi est-il impossible d'obtenir une résolution de 1600x1200 sur le second écran quand j'utilise un GeForce2 MX ? R: Sur le GeForce2 MX, le second écran est un écran plat numérique et le signal Pixel Clock (horloge pixel) du second écran a une fréquence de seulement 150 MHz, ce qui limite effectivement la résolution du second écran à environ 1280x1024 (le XFree86 Video Timings HOWTO explique comment les fréquences du signal Pixel Clock limitent les modes programmables). Cette contrainte n'est pas présente sur les GeForce4 et GeForce FX - la fréquence maximum du pixel clock est la même pour les deux écrans. Q: Le recouvrement vidéo fonctionne-t-il sur les écrans ? R: Le recouvrement vidéo matériel fonctionne uniquement sur le premier écran. Actuellement, la solution consiste à utiliser des blitters (transferts de blocs de bits transparents) vidéo au lieu de TwinView. Q: Comment les dimensions de l'écran virtuel sont-elles déterminées dans TwinView ? R: Après la validation de tous les modes demandés et le calcul des offsets pour chaque fenêtre d'affichage des MetaModes, le pilote NVIDIA calcule le bounding box des panning domains pour chaque MetaMode. Il détermine ainsi la largeur et la hauteur maximum du bounding box. Notez que la largeur virtuelle et la hauteur virtuelle peuvent être déterminées par différents MetaModes. Par exemple, si vous avez entré la chaînes suivante : "1600x1200,NULL; 1024x768+0+0, 1024x768+0+768" la taille de l'écran virtuel obtenu sera de 1600 x 1536. Q: Puis-je jouer à un jeu plein écran sur les deux écrans ? R: Oui. Tandis que les détails de la configuration varient d'un jeu à un autre, l'idée de base est qu'un MetaMode présente X avec un mode dont la résolution est le bounding box des fenêtres d'affichage pour ce MetaMode. Par exemple : Option "MetaModes" "1024x768,1024x768; 800x600,800x600" Option "TwinViewOrientation" "RightOf" produit deux modes : un avec un résolution de 2048x768 et un avec une résolution de 1600x600. Des jeux tels que Quake 3 Arena utilisent l'extension VidMode pour rechercher les résolutions des modes disponibles. Pour configurer Quake 3 Arena afin d'utiliser le MetaMode ci-dessus, ajoutez les paramètres suivants dans votre fichier q3config.cfg : seta r_customaspect "1" seta r_customheight "600" seta r_customwidth "1600" seta r_fullscreen "1" seta r_mode "-1" Notez que la configuration ci-dessus ne détermine pas de mode ayant une résolution de 800x600 (souvenez-vous que le MetaMode "800x600, 800x600" a un résolution de 1600x600") ; par conséquent, si vous configurez Quake 3 Arena pour utiliser une résolution de 800x600, il s'affichera dans le coin inférieur gauche de l'écran et le reste de l'écran sera grisé. Pour avoir également à disposition des modes head simples, vous devez entrer une chaîne de Metamode du type suivant : "800x600,800x600; 1024x768,NULL; 800x600,NULL; 640x480,NULL" L'objectif de ce document n'est pas de fournir une description précise de la configuration à utiliser pour chaque jeu. Toutefois les exemples cités et les nombreuses informations disponibles sur le Web devraient vous mettre sur la bonne voie. __________________________________________________________________________ (app-j) ANNEXE J : CONFIGURATION TV-OUT __________________________________________________________________________ Les cartes vidéo basées sur les GPU NVIDIA avec un connecteur de sortie TV (S-Video) peut être utilisées pour la connexion d'un téléviseur, exactement comme s'il s'agissait d'un écran cathodique ou d'un écran plat numérique. Le téléviseur peut être utilisé seul ou (à l'aide de cartes vidéo appropriées) avec un autre écran dans une configuration TwinView. Si le téléviseur est le seul écran connecté à votre carte vidéo, il sera utilisé comme écran principal au démarrage de votre système (le bureau s'affichera sur le téléviseur exactement comme s'il s'agissait d'un écran cathodique). Pour utiliser votre téléviseur avec X, vous devez faire très attention aux paramètres suivants dans votre fichier de configuration X : o VertRefresh et HorizSync dans la section Monitor ; les valeurs affectées doivent être valables pour votre téléviseur. Valeurs généralement correctes : HorizSync 30-50 VertRefresh 60 o Modes dans la section Screen ; les modes admis pour votre encodeur TV seront indiqués en détail dans le fichier journal X (générés à l'aide de la commande `startx -- -logverbose 5`) lorsque X est exécuté sur un téléviseur. Certains modes sont limités à des normes TV spécifiques, mais ceci est indiqué dans le fichier journal X. En général, au moins 800x600 et 640x480 sont pris en charge. o Il faut ajouter l'option "TVStandard" dans votre section Screen ; les valeurs admises sont : "PAL-B" : Belgique, Danemark, Finlande, Allemagne, Guinée, Hong Kong, Inde, Indonésie, Italie, Malaysia, Pays Bas, Norvège, Portugal, Singapour, Espagne, Suède et Suisse "PAL-D" : Chine et Corée du Nord "PAL-G" : Danemark, Finlande, Allemagne, Italie, Malaisie, Pays Bas, Norvège, Portugal, Espagne, Suède et Suisse "PAL-H" : Belgique "PAL-I" : Hong Kong et Royaume-Uni "PAL-K1" : Guinée "PAL-M" : Brésil "PAL-N" : France, Paraguay et Uruguay "PAL-NC" : Argentine "NTSC-J" : Japon "NTSC-M" : Canada, Chili, Colombie, Costa Rica, Équateur, Haïti, Honduras, Mexique, Panama, Porto Rico, Corée du Sud, Taiwan, États-Unis et Venezuela. "HD480i" : 480 lignes entrelacées "HD480p" : 480 lignes progressives "HD720p" : 720 lignes progressives "HD1080i": 1080 lignes entrelacées "HD1080p": 1080 lignes progressives "HD576i" : 576 lignes entrelacées "HD576p" : 576 lignes progressives La ligne de votre fichier de configuration X devrait ressembler à : Option "TVStandard" "NTSC-M" Si aucun TVStandard n'est spécifié ou que la valeur indiquée est incorrecte, "NTSC-M" sera utilisé par défaut. Remarque : si votre pays ne figure pas dans la liste ci-dessus, choisissez le pays le plus proche de chez vous. o L'option "ConnectedMonitor" peut être utilisée pour dire à X d'utiliser le téléviseur comme écran. Cette option n'est utile que si votre carte vidéo ne détecte pas le téléviseur ou si vous utilisez un écran cathodique CRT (ou un écran plat numérique) comme écran de démarrage, mais que vous voulez rediriger X sur le téléviseur. La ligne dans votre fichier XF86Config doit être : Option "ConnectedMonitor" "TV" o L'option "TVOutFormat" peut être utilisée pour forcer SVIDEO ou la sortie COMPOSITE. Sans cette option, le pilote détecte automatiquement le format de sortie. Malheureusement, cette détection n'est pas toujours exacte. Le format de sortie peut être forcé à l'aide des options : Option "TVOutFormat" "SVIDEO" ou Option "TVOutFormat" "COMPOSITE" o L'option "TVOverScan" peut être utilisée pour activer Overscan s'il est pris en charge. Les valeurs admises sont des valeurs décimales de 1.0 (overscan maximum pour que les images soient les plus grandes possibles) à 0.0 (overscan désactivé, pour que les images soient les plus petites possibles). Par défaut, l'overscan est désactivé(0.0). À l'heure actuelle, l'overscan n'est disponible que sur le GeForce4 et les processeurs graphiques plus récents avec encodeurs TV NVIDIA ou Conexant. Le pilote NVIDIA X ne restaure pas toujours correctement la console avec les versions de XFree86 antérieures à la version 4.3 si un téléviseur joue le rôle de console. Cela est dû aux incompatibilités binaires entre les modules XFree86 int10. Avec un téléviseur, nous vous conseillons de passer à la version XFree86 4.3 ou ultérieure. _ __________________________________________________________________________ (app-k) ANNEXE K : CONFIGURATION D'UN ORDINATEUR PORTABLE __________________________________________________________________________ INSTALLATION ET CONFIGURATION L'installation et la configuration de l'ensemble de pilotes accélérés NVIDIA pour Linux sur un ordinateur portable est similaire à celle d'un environnement d'ordinateur de bureau à part quelques différences mineures citées ci-dessous. A partir de la version 1.0-2802, les informations nécessaires à l'initialisation de l'écran plat interne sont générées par défaut à partir des données stockées dans le BIOS vidéo. Vous pouvez désactiver cette fonction en définissant l'option du noyau "SoftEDIDs" sur 0. Si "SoftEDIDs" est désactivée, les données enregistrées dans le programme seront choisies dans un tableau en fonction de la valeur entrée pour l'option de noyau "Mobile". L'option de noyau "Mobile" peut être réglée sur l'une des valeurs suivantes : 0xFFFFFFFF : laisse au module du noyau le soin de détecter automatiquement la valeur correcte. 1 : ordinateurs portables Dell 2 : ordinateurs portables Toshiba, à l'exception du Compal 3 : autres ordinateurs portables 4 : ordinateurs portables Compal Toshiba 5 : ordinateurs portables Gateway Là encore, l'option de noyau "Mobile" n'est nécessaire que si SoftEDIDs est désactivé ; si SoftEDIDs est utilisé, il est plus sûr de laisser au module du noyau le soin de détecter automatiquement la valeur correcte (comportement par défaut). Si vous devez modifier l'une de ces options, vous pouvez : o modifier os-registry.c dans le répertoire usr/src/nv/ du fichier .run ; o entrer la valeur sur la ligne de commande modprobe (par ex. : `modprobe nvidia NVreg_SoftEDIDs=0 NVreg_Mobile=3`) ; o ajouter une ligne "options" dans le fichier de configuration du module ; en général, /etc/modules.conf (ex. : "options nvidia NVreg_Mobile=5"). FONCTIONNALITÉS ADDITIONNELLES TWINVIEW Tous les chipsets NVIDIA pour ordinateurs portables prennent en charge TwinView. La configuration de TwinView est la même sur un ordinateur portable et un ordinateur de bureau (consultez l'ANNEXE I ci-dessus). Notez cependant que dans une configuration TwinView utilisant l'écran plat interne de l'ordinateur portable et un écran cathodique externe, l'écran cathodique sera l'écran principal (spécifiez son HorizSync et VertRefresh dans la section Monitor de votre fichier de configuration X) et l'écran plat sera le secondaire (spécifiez les paramètres HorizSync et VertRefresh dans les options SecondMonitorHorizSync et SecondMonitorVertRefresh). Vous pouvez également utiliser l'option UseEdidFreqs pour l'acquisition de HorizSync et VertRefresh de l'EDID de chaque écran sans recourir au fichier de configuration X (mais vous devez être sûr des EDID de vos écrans - reportez-vous à la description de l'option UseEdidFreqs dans l'ANNEXE D). BASCULEMENT ENTRE LES ÉCRANS PAR TOUCHE CLAVIER En plus de TwinView, les chipsets NVIDIA pour ordinateurs portables ont la capacité de réagir à un événement LCD/CRT généré sur le clavier, en basculant entre chacun des écrans connectés et chaque combinaison possible des écrans connectés (notez que seulement 2 écrans peuvent être utilisés en même temps). TwinView, tel que configuré dans votre fichier de configuration X et la fonctionnalité touche clavier sont mutuellement exclusifs - si vous activez TwinView dans votre fichier de configuration X, le pilote X NVIDIA ne tiendra pas compte des événements LCD/CRT générés sur le clavier. Un autre aspect important de la fonctionnalité de basculement par touche clavier est la possibilité de connecter et déconnecter dynamiquement les écrans à/de votre ordinateur portable sans besoin de redémarrer X. Cette fonctionnalité pose toutefois le problème de savoir comment valider et déterminer les modes à programmer sur chacun des périphériques d'affichage. D'abord, l'option UseEdidFreqs est extrêmement précieuse parce qu'elle permet de retrouver les vitesses de rafraîchissement horizontal et de rafraîchissement vertical de chaque écran à partir de l'EDID des écrans -- sinon, la sémantique du contenu de la section Monitor changerait constamment avec chaque événement généré par touche clavier. Au démarrage de X ou quand un changement est détecté dans la liste des écrans connectés, une nouvelle liste de séquences de touches est construite -- elle indique quels écrans seront utilisés avec chaque événement clavier. Après un événement clavier, l'état de la touche suivante dans la séquence est choisi. Chaque mode demandé dans le fichier de configuration X est validé en fonction des contraintes de chaque écran et les modes qui en résultent deviennent disponible pour cet écran. Si plusieurs écrans doivent être actifs en même temps, les modes de chaque écran sont accouplés ; si les écrans n'ont pas la même résolution, le système recherche la meilleure correspondance et un panoramique sera effectué sur l'écran ayant la plus basse résolution à l'intérieur de la résolution de l'autre écran. Après une commutation VT quittant X, la console VGA sera toujours restaurée sur l'écran utilisé pour le démarrage de X. De même, en cas de commutation VT retournant dans X, la configuration utilisée sera la même qu'en cas de commutation VT quittant X, indépendamment des commandes clavier LCD/CRT activées quand X n'était pas accessible. MODES NON STANDARD SUR LES ÉCRANS LCD Certains utilisateurs n'arrivent pas à programmer un mode 1400x1050 (la résolution de certains écrans LCD d'ordinateurs portables). La base de données des modes par défaut de la version 4.0.3 de XFree86 offre plusieurs modes 1400x1050 supplémentaires, mais si vous utilisez une version antérieure de XFree86, vous pouvez utiliser un modeline du type : # -- 1400x1050 -- # 1400x1050 @ 60Hz, 65.8 kHz hsync Modeline "1400x1050" 129 1400 1464 1656 1960 1050 1051 1054 1100 +HSync +VSync PROBLÈMES CONNUS CONCERNANT LES ORDINATEURS PORTABLES o Le basculement LCD/CRT par touche clavier ne fonctionne pas sur les ordinateurs portables Toshiba, exception faite du Satellite 3000. o TwinView ne fonctionne pas sur l'ordinateur portable Toshiba Satellite 2800. o Le recouvrement vidéo ne fonctionne que sur l'écran principal (où vous avez démarré X. Par exemple, si vous démarrez X sur l'écran LCD interne, lancez une application vidéo utilisant le recouvrement vidéo (utilisant l'adaptateur "Video Overlay" via l'extension XV), puis basculez à l'aide d'une touche clavier pour ajouter un second écran, la vidéo n'apparaîtra pas sur le second écran. Pour corriger ce problème, vous pouvez configurer l'application vidéo de manière à utiliser l'adaptateur "Video Blitter" via l'extension XV (toujours disponible) ou basculer à l'aide d'une touche clavier sur l'écran devant utiliser le recouvrement vidéo *avant* de démarrer X. __________________________________________________________________________ (app-l) ANNEXE L : MODES DE PROGRAMMATION __________________________________________________________________________ L'ensemble de pilotes accélérés NVIDIA pour Linux prend en charge tous les modes VGA et VESA standard, ainsi que la plupart des lignes de modes personnalisées par l'utilisateur ; les modes double-scan sont pris en charge par tout le matériel. Les modes entrelacés sont pris en charge par tous les GeForce FX/Quadro FX et les GPU récents, et par certains GPU plus anciens. Le fichier journal X comprend un message du type "Interlaced video modes are supported on this GPU" (les modes vidéo entrelacés sont pris en charge par ce GPU) si les modes entrelacés sont reconnus. En général, les modes que vous pouvez utiliser dépendront plus de votre écran (moniteur/écran plat/téléviseur) que de votre carte vidéo basée sur GPU NVIDIA ou de l'ensemble de pilotes accélérés NVIDIA pour Linux. Pour utiliser un ou plusieurs modes standard dans X, il suffit d'ajouter une ligne "Modes" telle que : Modes "1600x1200" "1024x768" "640x480" dans la sous-section Display de votre fichier de configuration X (consultez la man page XF86Config(5x) ou xorg.conf(5x) pour plus de détails). La documentation suivante est fondamentale si vous voulez éditer des lignes de mode, utiliser xvidtune(1) ou simplement vous informer. Notez que vous n'y trouverez pas d'explications détaillées sur l'édition de lignes de modes personnalisés pour X. Nous laissons ce soin à d'autres documents, tels que XFree86 Video Timings HOWTO (disponible sur www.tldp.org). PROFONDEURS, BITS PAR PIXEL ET PAS Bien que le nombre de bits par pixel ne concerne pas directement les modes de programmation, il doit être pris en compte si l'on considère la résolution maximum programmable ; pour éviter tout confusion, il nous semble utile de faire le point sur les termes "profondeur" et "bits par pixel". La profondeur est le nombre de bits de données stockées par pixel. Les profondeurs supportées sont 8, 15, 16, et 24. Toutefois, la plupart des matériels vidéo stockent les données des pixels aux formats 8, 16, ou 32 bits ; il s'agit de la quantité de mémoire allouée pour chaque pixel. Lorsque vous spécifiez votre profondeur, X sélectionne le format de bits par pixel (bpp) auquel stocker les données. Le tableau ci-dessous indique le bpp utilisé pour chaque profondeur possible. profondeur bpp ===== ===== 8 8 15 16 16 16 24 32 Enfin, le "pas" est le nombre d'octets dans la mémoire linéaire compris entre une donnée de pixel et la donnée du pixel immédiatement au-dessous. Vous pouvez penser qu'il s'agit de la résolution horizontale multipliée par le nombre d'octets par bytes (bits par pixel divisés par 8). En pratique, le pas peut être supérieur à ce produit en raison des contraintes d'alignement. RÉSOLUTIONS MAXIMALES L'ensemble de pilotes accélérés NVIDIA pour Linux et les cartes vidéo basées sur GPU NVIDIA supportent des résolutions allant jusqu'à 2048x1536, bien que la résolution maximum prise en charge par votre système soit également limitée par la quantité de mémoire vidéo (pour plus de détails, reportez-vous au point FORMULES UTILES) et la résolution maximum de votre écran (moniteur/écran plat/téléviseur). Notez également que si un recouvrement vidéo ne limite pas la résolution maximum ou la vitesse de rafraîchissement, la bande passante de la mémoire vidéo utilisée par un mode programmé a un effet sur la qualité du recouvrement. FORMULES UTILES La résolution maximum dépend de la quantité de mémoire vidéo et du nombre de bits par pixel que vous utilisez : HR * VR * (bpp/8) = Mémoire vidéo utilisée En d'autres termes, la quantité de mémoire vidéo utilisée est égale à la résolution horizontale (HR) multipliée par la résolution verticale (VR), multipliée par le nombre d'octets par pixel (bits par pixel divisés par huit). Techniquement, la mémoire vidéo utilisée correspond en fait au pas qui fixe la résolution verticale et ce pas peut être légèrement supérieur à (HR * (bpp/8)), de manière à remplir les conditions requises par le matériel, à savoir que le pas doit être un multiple d'une certaine valeur. Notez qu'il s'agit uniquement de l'utilisation que la mémoire d'image fait de la mémoire ; la mémoire vidéo est également utilisée pour d'autres choses, par exemple comme cache OpenGL ou pixmap. Une autre formule importante établit la relation entre la résolution, l'horloge pixel (aka dot clock) et la vitesse de rafraîchissement vertical : RR = PCLK / (HFL * VFL) En d'autres termes, la vitesse de rafraîchissement (RR) est égale à l'horloge pixel (PCLK) divisée par le nombre total de pixels : La longueur d'image horizontale (HFL) multipliée par la longueur d'image verticale (VFL) (remarquez qu'ils s'agit de longueurs d'images et non seulement de résolutions visibles). Comme décrit dans XFree86 Video Timings HOWTO, cette formule peut être réécrite sous la forme : PCLK = RR * HFL * VFL En considérant une horloge pixel maximum, vous pouvez régler RR, HFL et VFL à votre gré, tant que le produit de ces trois facteurs reste cohérent. L'horloge pixel est indiquée en clair dans le fichier journal quand vous démarrez X avec l'option `startx -- -logverbose 5`. Le fichier journal X doit contenir plusieurs lignes telles que : (--) 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 qui indiquent l'horloge pixel maximum pour chaque nombre de bits par pixel. VALIDATION DES MODES Pendant la phase PreInit du serveur X, le pilote X NVIDIA valide tous les modes requis de la manière suivante : o Il détecte l'intersection des plages HorizSync et VertRefresh entrées par l'utilisateur dans le fichier de configuration X avec les plages indiquées par le moniteur dans EDID (Extended Display Identification Data) ; ce comportement peut être désactivé en utilisant l'option "IgnoreEDID" ; dans ce cas, le pilote X acceptera aveuglement les plages de valeurs entrées par l'utilisateur pour HorizSync et VertRefresh. o Il appelle la fonction d'aide xf86ValidateModes(), qui recherche les modes ayant les noms spécifiés par l'utilisateur dans le fichier de configuration X, en éliminant les modes dont la vitesse de rafraîchissement horizontale ou verticale n'est pas valide, les horloges pixel dépassent la taille maximum admise par la carte vidéo ou les résolutions sont supérieures à la taille de l'écran virtuel (si une taille d'écran virtuel a été spécifiée dans le fichier de configuration X). Pour les autres contraintes appliquées, reportez-vous à xc/programs/Xserver/hw/xfree86/common/xf86Mode.c:xf86ValidateModes(). o Tous les modes renvoyés par xf86ValidateModes() sont ensuite examinés pour être sûr que leurs résolutions ne sont pas supérieures à celle du mode maximum à l'aide de l'option "IgnoreEDID". Si l'écran est un téléviseur, chaque mode est vérifié pour s'assurer que sa résolution est prise en charge par l'encodeur TV (en général, l'encodeur supporte uniquement les résolutions de 800x600 et 640x480). o Tous les modes sont également testés pour confirmer qu'ils respectent les contraintes liées à la bande passante mémoire. Ce test peut être désactivé à l'aide de l'option NoBandWidthTest du fichier de configuration X. o Tous les autres modes sont ensuite contrôlés pour s'assurer qu'ils respectent les contraintes décrites dans AUTRES CONTRAINTES DE MODES. Les trois dernières étapes sont également effectuées lors de la programmation de chaque mode, afin de détecter les modes potentiellement non valides soumis par XF86VidModeExtension (eg xvidtune(1)). Pour TwinView, la validation ci-dessus est effectuée pour les modes requis pour chaque périphérique d'affichage. AUTRES CONTRAINTES DE MODES La liste ci-dessous indique les autres contraintes à respecter pour les paramètres de modes. Dans certains cas, ces contraintes se réfèrent uniquement à certains chipsets particuliers. o La résolution horizontale (HR) doit être un multiple de 8 et inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. o La largeur de l'espace vide horizontal (longueur maximum de trame horizontale et sync end horizontal moins résolution horizontale minimum et sync start horizontal (max(HFL,HSE) - min(HR,HSS)) doit être un multiple de 8 et inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. o Le sync start horizontal (HSS) doit être un multiple de 8 et inférieur ou égal à la valeur indiquée dans le tableau ci-dessous. o Le sync width horizontal (sync end horizontal moins horizontal sync start (HSE - HSS)) doit être un multiple de 8 et inférieur ou égal à la valeur indiquée dans le tableau ci-dessous. o La longueur de trame horizontale (HFL) doit être un multiple de 8, supérieur ou égale à 40 et inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. o La résolution verticale (VR) doit être inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. o La largeur de l'espace vide vertical (longueur maximum de trame verticale et sync end vertical moins résolution verticale minimum et sync start vertical (max(VFL,VSE) - min(VR,VSS)) doit être inférieure ou égale valeur indiquée dans le tableau ci-dessous. o Le sync start vertical (VSS) doit être inférieur ou égal à la valeur indiquée dans le tableau ci-dessous. o Le sync width vertical (sync end vertical moins sync start vertical (VSE - VSS)) doit être inférieur ou égal à la valeur indiquée dans le tableau ci-dessous. o La longueur de trame verticale (VFL) doit être supérieure ou égale à 2 et inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. Valeurs DAC maximum ------------------ | GeForce/TNT Geforce2 & 3 Geforce4 ou plus récent ______|_____________________________________________________ | HR | 4096 4096 8192 HBW | 1016 1016 2040 HSS | 4088 4088 8224 HSW | 256 256 512 HFL | 4128 4128 8224 VR | 2048 4096 8192 VBW | 128 128 256 VSS | 2047 4095 8192 VSW | 16 16 16 VFL | 2049 4097 8192 Cet exemple de ligne de mode illustre comment utiliser les abréviations citées ci-dessus : # Ligne de mode personnalisée pour l'écran plat SGI 1600SW # nom PCLK HR HSS HSE HFL VR VSS VSE VFL Modeline "sgi1600x1024" 106.9 1600 1632 1656 1672 1024 1027 1030 1067 GARANTIE DE MODES IDENTIQUES Certaines fonctionnalités telles que le mode de stéréo actif avec TwinView exigent une définition exacte de la synchronisation de mode utilisée. Cela peut s'effectuer de plusieurs manières : o Pour s'assurer que les deux périphériques d'affichage utilisent les mêmes modes, assurez-vous que les valeurs HorizSync et VertRefresh des deux périphériques d'affichage sont identiques en validant les modes. Cette validation consiste à vérifier que les valeurs HorizSync et SecondMonitorHorizSync concordent, et que les valeurs VertRefresh et SecondMonitorVertRefresh concordent également. o Une méthode plus directe consiste à spécifier la ligne de mode que vous désirez utiliser (en sélectionnant un des générateurs de lignes de mode disponibles) et à affecter un nom unique. Par exemple, si vous désirez utiliser 1024x768 à 120 Hz sur chaque moniteur de TwinView avec l'option stéréo active, ajoutez des informations semblables à celles-ci : # 1024x768 @ 120.00 Hz (GTF) hsync: 98.76 kHz; pclk: 139.05 MHz Modeline "1024x768_120" 139.05 1024 1104 1216 1408 768 769 772 823 -HSync +Vsync Dans la section moniteur et la section écran de votre fichier de configuration X, spécifiez un métamode semblable à celui-ci : Option "MetaModes" "1024x768_120, 1024x768_120" VOIR ÉGALEMENT : Un générateur de modelines XFree86 conforme à la norme est disponible sur le site suivant : http://gtf.sourceforge.net/ Pour obtenir d'autres générateurs de modelines, vous pouvez rechercher "modeline" sur freshmeat.net. __________________________________________________________________________ (app-m) ANNEXE M : FLIPPING ET UBB __________________________________________________________________________ Les pilotes accélérés NVIDIA pour Linux prennent en charge UBB (Unified Back Buffer) et OpenGL Flipping. Dans certaines situations, ces fonctionnalités peuvent améliorer les performances. o Unified Back Buffer (UBB) : UBB n'est disponible que sur les GPU de la famille Quadro (exception faite du Quadro4 NVS) et est activé par défaut quand la mémoire vidéo disponible est suffisante. Il peut être désactivé à l'aide de l'option UBB du fichier de configuration X décrite dans l'annexe D. Lorsque UBB est activé, toutes les fenêtres partagent le même tampon arrière, stencil et de profondeur. Si les fenêtres sont nombreuses, l'utilisation de ces trois types ne dépasse jamais la taille utilisée pour la fenêtre en plein écran. Toutefois, même en présence d'une seule fenêtre de petite taille, les paramètres back, stencil et depth seront ceux d'une fenêtre plein écran. Conséquence : l'utilisation de la RAM vidéo peut se révéler moins efficace que sans UBB. o Flipping : lorsque le retournement OpenGl est activé, OpenGl permute les tampons en changeant le tampon balayé par DAC au lieu de copier le contenu du tampon arrière sur le tampon avant. Ce mécanisme entraîne généralement des performances supérieures et permet de réaliser des permutations transparentes lors de la régénération verticale (lorsque la variable __GL_SYNC_TO_VBLANK est définie). Les conditions de retournement d'OpenGL sont un peu compliquées, mais voici la règle générale : sur du matériel GeForce ou plus récent, OpenGL peut appliquer le retournement lorsqu'une application OpenGL est exécutée en plein écran et sans être masquée et que la variable __GL_SYNC_TO_VBLANK est activée. En sus, OpenGL reconnaît le retournement sur le matériel Quadro, même en présence d'une fenêtre OpenGL partiellement masquée ou non affichée en mode plein écran, ou lorsque la variable __GL_SYNC_TO_VBLANK n'est pas activée. __________________________________________________________________________ (app-n) ANNEXE N : PROBLÈMES CONNUS __________________________________________________________________________ Les problèmes suivants existent encore dans cette version et leur résolution est actuellement à l'étude. o OpenGL + Xinerama À l'heure actuelle, OpenGL ne peut utiliser que le premier écran dans un environnement Xinerama. o OpenGL et dlopen() Il existe certains problèmes avec les versions précédentes du chargeur dynamique glibc (par ex., la version fournie avec Red Hat Linux 7.2) et des applications telles que Quake3 et Radiant, qui utilisent dlopen(). Pour de plus amples informations, reportez-vous à la section FAQ. o DPMS et TwinView Les modes DPMS "suspend" et "standby" ne fonctionnent pas correctement sur un second CRT quand on utilise TwinView. L'écran est vide au lieu du moniteur défini pour l'état DPMS requis. o DPMS et écrans plats Les modes DPMS "suspend" et "standby" ne fonctionnent pas correctement sur un écran plat. L'écran est vide au lieu de l'écran plat défini pour l'état DPMS requis o Plusieurs cartes et moniteurs Dans certains cas, la carte secondaire n'est pas installée correctement par le module du noyau NVIDIA. Vous pouvez éliminer ce problème en activant l'utilisation du module Int10 XFree86 pour initialiser en douceur toutes les cartes secondaires. Pour plus de détails, reportez à l'ANNEXE D: OPTIONS DE CONFIGURATION X. o Ordinateur portable Si vous utilisez un ordinateur portable, reportez-vous aux "Problèmes connus concernant les ordinateurs portables" dans l'ANNEXE D. o FSAA Lorsque l'option FSAA est activée (la variable d'environnement __GL_FSAA_MODE est définie sur une valeur qui active FSAA et un multi-échantillonnage est sélectionné), le rendu peut être altéré en cas de redimensionnement de la fenêtre. o Interaction avec pthreads Les applications à un thread qui dlopen() la bibliothèque libGL de NVIDIA puis dlopen() toute autre bibliothèque reliée avec pthreads, se bloquent dans la bibliothèque libGL de NVIDIA. Cela ne se produit pas dans les nouvelles bibliothèques OpenGL ELF TLS OpenGL de NVIDIA. Reportez-vous à (app-c) ANNEXE C : COMPOSANTS INSTALLÉS pour une description des bibliothèques OpenGl ELF TLS). Pour éliminer ce problème, vous pouvez : 1) charger la bibliothèque qui est reliée avec pthreads avant de charger libGL.so ; 2) relier l'application à pthreads. o Finalisateur DSO libGL et pthreads Quand une application OpenGL multithread se ferme, il est possible qu'un finalisateur (aussi connu sous le nom de destructeur, ou " _fini ") soit appelé pendant que d'autres threads exécutent le code OpenGL. Ce finalisateur a pour rôle de libérer les ressources allouées par libGL, ce qui peut poser des problèmes aux threads qui utilisent encore ces ressources. Mettre la variable d'environnement " __GL_NO_DSO_FINALIZER " sur "1" contournera ce problème en obligeant le finalisateur de la libGL à laisser les ressources en place. Ces ressources seront de toute façon réclamées par le système d'exploitation à la fin du processus. Sachez que le finalisateur est aussi exécuté dans le cadre de lclose(3), de sorte que si vous avez une application qui ouvre (dlopens(3)) et ferme (dlcloses(3)) libGL de façon répétée, " __GL_NO_DSO_FINALIZER " entraînera la fuite de ressources de libGL jusqu'à la fin du processus. Utiliser cette option peut améliorer la stabilité dans certaines applications multithread, applications Java3D comprises. o XVideo et l'extension X Composite XVideo ne fonctionne pas correctement lorsque Composite est activé. Voir (app-u) ANNEXE U: L'EXTENSION X COMPOSITE. o La plate-forme EM64T d'Intel et SWIOTLB Linux ne fournit pas à l'heure actuelle de mécanisme permettant d'allouer de la mémoire avec des adresses qui rentrent dans les quatre premiers Gigs de mémoire sur la plate-forme EM64T d'Intel. Les adresses de cette plage sont nécessaires pour que le matériel PCI 32 bits assure les fonctions DMA. À la place, le noyau de Linux fournit un tlb E/S logiciel afin de contourner le problème. Cette approche engendre malheureusement certains problèmes. Les premières implémentations de swiotlb mettent de côté une quantité de mémoire minime pour son pool de mémoire (4 méga-octets). De plus, quand ce pool est épuisé, le noyau panique obligatoirement. Les épisodes de panique du noyau et les problèmes de stabilité qui y sont liés peuvent être évités en augmentant la taille du pool. Cela peut être effectué via la ligne de commande du noyau avec l'option " swiotlb= ". NVIDIA suggère de porter la taille de ce pool à 32 méga-octets lors de l'utilisation de son pilote. Cela se fait en passant la valeur " swiotlb=16384 " au noyau. Depuis le noyau 2.6.9 de kernel.org, la taille par défaut de swiotlb a été portée à 64 méga-octets et la gestion des dépassements a été améliorée. Ces deux éléments améliorent considérablement la stabilité et sont vivement recommandés. Veuillez également lire le problème connu suivant, également relatif au sujet des problèmes de stabilité sur cette plate-forme. o La plate-forme X86-64 (AMD64/EM64T) et les noyaux 2.6 De nombreux noyaux 2.4 et 2.6 x86_64 présentent un problème de comptabilité dans leur implémentation de l'interface de noyau change_page_attr. Les premiers noyaux 2.6 incluent un contrôle qui déclenche un BUG() quand cette situation se présente (déclencher un BUG() entraîne l'élimination de l'application en cours par le noyau, c.'-à-d. de votre application opengl ou, potentiellement, du serveur X). Ce problème de comptabilité a été résolu dans le noyau 2.6.11. Nous avons ajouté des contrôles permettant de reconnaître que le module de noyau de NVIDIA est compilé pour la plate-forme x86-64 sur un noyau entre la version 2.6.0 et la 2.6.11. Dans ce cas, nous désactiverons l'usage de l'interface de noyau change_page_attr. Cela évitera le problème de comptabilité mais laissera le système en danger d'aliasing du cache. L'aliasing du cache peut mener à la corruption des données et à des blocages aléatoires du système, mais ne se reproduit pas de façon cohérente. Vous remarquerez que ce problème de comptabilité change_page_attr et BUG() peuvent être déclenchés par d'autres sous-systèmes du noyau qui reposent sur cette interface. Si vous utilisez un noyau x86_64 2.6, nous vous recommandons de passer à un noyau 2.6.11 ou plus récent. PROBLÈMES MATÉRIELS Cette section décrit les problèmes qui ne seront pas corrigés. Généralement, ces problèmes ne sont pas imputables à NVIDIA. Voici la liste de ces problèmes : o Carte mère Gigabyte GA-6BX Cette carte mère utilise un régulateur LinFinity sur le rail 3.3-V de seulement 5 A - moins que la spécification AGP, qui exige 6 A. Pendant l'exécution de l'outil de diagnostic ou d'applications, la température du régulateur augmente en causant une baisse de tension dans le chip NVIDIA jusqu'à 2.2 V. Dans ce cas, le régulateur ne peut pas fournir sur le rail 3.3-V le courant dont le chip NVIDIA a besoin. Ce problème ne se produit pas quand la carte graphique a un régulateur avec commutateur ou quand l'alimentation externe est connectée au rail 3.3-V. o Chipsets VIA KX133 et 694X avec AGP 2x Sur les cartes mères Athlon avec le chipset VIA KX133 ou 694X, comme la carte mère ASUS K7V, les pilotes NVIDIA utilisent par défaut le mode AGP 2x pour palier à l'insuffisance du drive strength sur l'un des signaux. o Chipsets Irongate avec AGP 1x Les cartes mères Athlon avec le chipset Irongate utilisent les transferts AGP 1x pour palier au problème de l'intégrité du signal du chipset. o Chipsets ALi1541 et ALi1647 Sur les chipsets ALi1541 et ALi1647, les pilotes NVIDIA désactivent AGP pour palier aux problèmes de temporisation et d'intégrité des signaux. Vous trouverez des informations sur les chipsets Ali, dans l'ANNEXE G : PROBLÈMES SPÉCIFIQUES DES SYSTÈMES ALI. o E/S APIC (SMP) Si vous rencontrez des problèmes d'instabilité avec une machine SMP Linux et que des messages d'avertissement I/O APIC sont générés par le noyau, vous pouvez considérablement améliorer la stabilité en réglant le paramètre "noapic" du noyau. o Local APIC (UP) Sur certains systèmes, l'option de configuration du noyau "Local APIC Support on Uniprocessors" peut causer des problèmes d'instabilité du système. Si des verrouillages se produisent avec une machine UP Linux et que cette option est activée, essayez de désactiver le support APIC local. __________________________________________________________________________ (app-o) ANNEXE O : INTERFACE PROC __________________________________________________________________________ L'interface /proc du système de fichiers vous permet d'obtenir des informations du run-time sur le pilote, les cartes graphiques NVIDIA installées et l'état AGP. Ces informations sont contenues dans plusieurs fichiers situés dans /proc/driver/nvidia : o /proc/driver/nvidia/version Contient la version du pilote installé et la version du compilateur GNU C utilisé pour construire le module du noyau Linux. o /proc/driver/nvidia/cards/0...3 Fournit des informations sur chacune des cartes graphiques NVIDIA installées (nom de modèle, IRQ, version du BIOS, type de bus). Notez que la version du BIOS n'est pas disponible pendant l'utilisation de X. o /proc/driver/nvidia/agp/card Informations sur les capacités AGP de la carte AGP installée. o /proc/driver/nvidia/agp/host-bridge Informations sur le host bridge (modèles et capacités AGP). o /proc/driver/nvidia/agp/status État courant d'AGP. Si le support AGP a été activé sur votre système (pilote AGP utilisé), ce fichier contient la vitesse d'AGP et des informations sur l'état de l'AGP Fast Writes et du Side Band Addressing sont affichées. Le pilote AGP peut être un pilote NVIDIA (pilote AGP NVIDIA incorporé) ou AGPGART (pilote agpgart.o du noyau Linux). Si vous voyez "inactive" à côté d'AGPGART, c'est que le chipset AGP a été programmé par AGPGART, mais qu'il n'est pas en cours d'utilisation. SBA et Fast Writes indiquent si l'une des fonctionnalités est en cours d'utilisation. Plusieurs facteurs entrent en jeu pour déterminer si ces fonctionnalités seront activées. D'abord, la carte AGP et le host bridge doivent tous les deux supporter ces fonctionnalités. Même si les deux les supportent, le pilote peut décider de le pas les utiliser pour préserver la stabilité du système. Il s'agit d'une particularité du Fast Writes AGP. __________________________________________________________________________ (app-p) ANNEXE P : PRISE EN CHARGE DE XVMC __________________________________________________________________________ Cette version prend en charge l'API XvMC (X-Video Motion Compensation) version 1.0 sur les GeForce4, les GeForce FX et les produits plus récents. Elle contient une bibliothèque statique "libXvMCNVIDIA.a" et une bibliothèque dynamique "libXvMCNVIDIA_dynamic.so" permettant l'appel de la fonction dlopen. Les produits GeForce4 MX, GeForce FX et plus récents prennent en charge l'IDCT de XvMC et les "niveaux d'accélération de la compensation de mouvement". Les produits GeForce4 Ti reconnaissent uniquement le niveau de compensation de mouvement. Les sous-images AI44 et IA44 sont prises en charge, ainsi que les surfaces 4:2:0 jusqu'à 2032x2032. libXvMCNVIDIA observe la variable d'environnement XVMC_DEBUG et envoie un débogage à stderr s'il est défini sur une valeur appropriée. '0' désactive le débogage. '1' active le débogage en cas de panne. '2' ou une valeur supérieure active la sortie de messages d'avertissement. __________________________________________________________________________ (app-q) ANNEXE Q : PRISE EN CHARGE DE GLX __________________________________________________________________________ Cette version prend en charge GLX 1.3 avec les extensions suivantes : GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_ARB_get_proc_address Vous trouverez une description de ces extensions, dans le registre d'extensions OpenGL à l'adresse : http://oss.sgi.com/projects/ogl-sample/registry/index.html Certaines de ces extensions font partie de la fonctionnalité GLX 1.3, mais sont également exportées comme extensions pour des raisons de compatibilité avec des versions antérieures. __________________________________________________________________________ (app-r) ANNEXE R : CONFIGURATION DE PLUSIEURS ÉCRANS X SUR UNE CARTE __________________________________________________________________________ Les puces graphiques qui prennent en charge TwinView (consultez (app-i) ANNEXE I : CONFIGURATION DE TWINVIEW) peuvent également être configurées pour le traitement de chaque périphérique d'affichage en tant qu'écran X distinct. Bien que cette technique présente plusieurs inconvénients par rapport à TwinView (ex.: il n'est pas possible de déplacer les fenêtres d'un écran X à l'autre, OpenGL accéléré ne peut pas étendre les deux écrans X), elle offre un certains nombre d'avantages : o Si chaque périphérique d'affichage est un écran X distinct, les propriétés pouvant varier d'un écran X à un autre peuvent également varier d'un périphérique d'affichage à un autre (ex. : profondeur, taille de la fenêtre racine, etc. o Le matériel qui ne peut s'utiliser que sur un seul écran à la fois (ex. : recouvrements vidéos, recouvrements RGB avec matériel accéléré) et qui ne peut donc pas servir dans TwinView, risque d'être exposé sur le premier écran X quand celui-ci est considéré séparément. o L'association 1 à 1 entre périphériques d'affichage et écrans X est davantage dans la tradition de X. Pour configurer deux écrans X distincts partageant une même carte graphique, vous devez procéder comme suit : Créez d'abord deux sections Device séparées ; dans chaque section, entrez le BusID de la carte graphique à partager, spécifiez "nvidia" comme pilote et affectez un écran distinct : Section "Device" Identifier "nvidia0" Driver "nvidia" # Entrez le BusID avec l'emplacement de votre carte graphique BusID "PCI:2:0:0" Screen 0 EndSection Section "Device" Identifier "nvidia1" Driver "nvidia" # Entrez le BusID avec l'emplacement de votre carte graphique BusId "PCI:2:0:0" Screen 1 EndSection Créez ensuite deux sections Screen, une pour chaque section Device : Section "Screen" Identifier "Screen0" Device "nvidia0" Monitor "Monitor0" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1600x1200" "1024x768" "800x600" "640x480" EndSubsection EndSection Section "Screen" Identifier "Screen1" Device "nvidia1" Monitor "Monitor1" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1600x1200" "1024x768" "800x600" "640x480" EndSubsection EndSection (Remarque : vous devez également créer un second section Monitor.) Enfin, modifiez la section ServerLayout pour utiliser et positionner les deux sections Screen : Section "ServerLayout" ... Screen 0 "Screen0" Screen 1 "Screen1" leftOf "Screen0" ... EndSection Vous trouverez de plus amples informations dans les pages man XF86Config(5x) ou xorg.conf(5x). __________________________________________________________________________ (app-s) ANNEXE S : PRISE EN CHARGE DE LA GESTION DE L'ÉNERGIE __________________________________________________________________________ Cette version prend en charge la gestion de la consommation d'énergie APM. En d'autres termes, le pilote NVIDIA peut gérer les modes d'interruption (suspend) et de reprise (resume) mais pas le mode de veille (standby). Le BIOS de votre ordinateur portable devra prendre en charge l'APM, au lieu de l'ACPI. De nombreux, mais pas tous les ordinateurs basés sur les GPU GeForce2 ou GeForce4 incluent la prise en charge de l'APM. Vous pouvez vérifier la présence de cette prise en charge de l'APM via l'interface procfs (contrôlez l'existence de /proc/apm) ou via la sortie d'initialisation du noyau : % dmesg | grep -i apm Un message similaire au suivant indiquera la prise en charge de l'APM : apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16) Un message similaire au suivant indiquera l'absence de prise en charge de l'APM : No APM support in Kernel Bien que la prise en charge de l'ACPI progresse dans les noyaux développés et qu'il existe certains correctifs rétroportés pour les noyaux 2.4, le pilote de cartes graphiques NVIDIA ne fournit pas encore de prise en charge pour l'ACPI. Cette prise en charge devrait être inclue sous peu. Vous remarquerez que le mode de veille n'est pas pris en charge, mais que le noyau essaiera de passer en mode de veille si cela lui est ordonné. En cas de changement du niveau de puissance, de nombreux services du système sont avertis du changement de sorte à pouvoir le gérer de façon appropriée. Par exemple, les connexions réseau sont désactivées avant l'interruption puis réactivées à la reprise. Lorsque le noyau essaie de passer en mode de veille, le BIOS fait échouer la tentative. Le noyau imprime alors le message d'erreur " standby: Parameter out of range ", mais n'avertit pas les services du système de l'échec. Résultats, le système ne passe pas en mode d'interruption, mais tous les services du système sont désactivés et semblent bloqués. La meilleure façon de se reprendre de cette situation consiste à passer en mode d'interruption puis en mode de reprise. La prise en charge de la gestion de la consommation est toujours en cours de développement et il s'agit actuellement d'une fonction bêta. Le résultat est que certaines fonctionnalités sont encore absentes ou peu fiables. Les problèmes connus sont les suivants : Certains chipsets perdent leur configuration AGP en mode d'interruption et risquent d'endommager le bus lors de la reprise d'activité. Le pilote AGP est indispensable à l'enregistrement et à la restauration de l'état de registre approprié sur de tels systèmes. Le composant NvAGP de NVIDIA est averti de tout événement de gestion de l'énergie et garantit le maintien de la configuration tout au long des cycles suspend/resume. Le pilote Linux 2.4 AGPGART ne prend pas en charge la gestion de l'énergie contrairement à Linux 2.6 AGPGART (pour certains chipsets uniquement toutefois). Si vous utilisez l'un de ces deux pilotes AGP et que vous constatez que votre système ne parvient pas à reprendre ses fonctions normalement, votre problème sera résolu si vous choisissez le pilote NvAGP de NVIDIA. La désactivation du module AGP (consultez l'annexe F : CONFIGURATION D'AGP pour savoir comment désactiver le module AGP) permet également de résoudre ce problème. Pour l'ACPI, seul S3 " Suspend to Ram " est couramment pris en charge. Cela signifie que S4 " Suspend to Disk ", aussi connu comme " Software Suspend " ou " swsusp ", ne fonctionne pas actuellement de façon fiable. _________________________________________________________________________ (app-t) ANNEXE T : NOMS DES PÉRIPHÉRIQUES D'AFFICHAGE __________________________________________________________________________ On appelle "périphérique d'affichage" tout composant matériel en mesure d'afficher une image. Les périphériques d'affichage sont classés en trois grandes catégories : écrans CRT analogiques, écrans plats numériques (DFP) et téléviseurs. Vous observerez que les écrans plats analogiques sont considérés comme des CRT analogiques par le pilote. Un "nom de périphérique d'affichage" est une chaîne de description qui permet d'identifier de manière unique un périphérique d'affichage. Il suit le format "-". Exemple : "CRT-0", "CRT-1", "DFP-0" ou "TV-0". Sachez que le numéro indique le mode de raccordement du connecteur du périphérique d'affichage sur la carte graphique et ne correspond en aucune manière au nombre de périphériques d'un type donné. Autrement dit, par exemple, vous pouvez disposer d'un "CRT-1" sans posséder de "CRT-0". Pour identifier les périphériques d'affichage connectés, consultez votre fichier journal X afin d'y repérer une ligne de ce type : (II) NVIDIA(0): Connected display device(s) : CRT-0, DFP-0 Vous pouvez utiliser les noms des périphériques d'affichage pour définir les options MetaMode, HorizSync et VertRefresh dans le fichier de configuration X afin d'indiquer les éléments auxquels s'applique le paramètre de périphérique d'affichage. Exemple : Option "MetaModes" "CRT-0: 1600x1200, DFP-0: 1024x768" Option "HorizSync" "CRT-0: 50-110 ; DFP-0: 40-70" Option "VertRefresh" "CRT-0: 60-120 ; DFP-0: 60" Vous n'êtes pas obligé de spécifier le nom du périphérique d'affichage dans ces options. Si vous le faites, le pilote tente alors de déduire les périphériques d'affichage auxquels s'applique un paramètre donné. Dans le cas des MetaModes, par exemple, le premier mode répertorié s'applique au "premier" périphérique d'affichage et le second mode recensé au "second" périphérique d'affichage. Malheureusement, il est souvent difficile de déterminer le composant considéré comme le "premier" ou le "second" périphérique d'affichage. C'est pourquoi il est préférable de spécifier le nom du périphérique d'affichage. Lorsque vous indiquez le nom d'un périphérique d'affichage, vous pouvez également omettre les chiffres mentionnés dans ce nom, bien que cela s'avère utile uniquement si vous disposez d'un seul périphérique d'affichage de ce type. Si, par exemple, vous n'avez qu'un écran CRT et un écran DFP connectés, vous pouvez les spécifier comme suit dans la chaîne MetaModes : Option "MetaModes" "CRT: 1600x1200, DFP: 1024x768" __________________________________________________________________________ (app-u) ANNEXE U : L'EXTENSION X COMPOSITE __________________________________________________________________________ La version X.org X11R6.8.0 contient une prise en charge expérimentale relative à une nouvelle extension du protocole X appelée Composite. Cette extension permet de dessiner les fenêtres dans les pixmaps au lieu de le faire directement à l'écran. Conjointement avec les extensions DAMAGE et RENDER, ceci permet à un programme que l'on appelle un gestionnaire composite de mélanger les fenêtres pour dessiner l'écran. Il est possible d'améliorer les performances en activant " Option "RenderAccel" " dans xorg.conf. Voir (app-d) ANNEXE D : OPTIONS DE CONFIGURATION X pour de plus amples détails. Une prise en charge complète de l'extension Composite requerrait la prise en charge de pilotes supplémentaires. À l'heure actuelle, les clients à rendu direct comme GLX n'ont aucun moyen de savoir ce qu'ils sont supposés rendre dans un pixmap et dessinent du coup directement à l'écran. Nous étudions actuellement les solutions à implémenter pour que ces clients interopèrent sans problème avec l'extension Composite. En attendant, GLX est désactivé par défaut lorsque l'extension Composite est détectée. Une option a été fournie pour le réactiver. Voir " Option "AllowGLXWithComposite" " dans (app-d) ANNEXE D : OPTIONS DE CONFIGURATION X. Ce problème a été examiné sur la liste de mailing de l'xorg : http://freedesktop.org/pipermail/xorg/2004-May/000607.html L'extension Composite est également à l'origine de problèmes avec d'autres composants du pilote : o Xv ne peut pas dessiner dans les pixmaps qui ont été redirigés hors écran et dessinera à la place directement sur l'écran. Pour certains programmes, vous pouvez contourner ce problème en utilisant un pilote vidéo de remplacement. Par exemple, " mplayer -vo x11 " fonctionnera correctement, tout comme " xine -V xshm ". Si vous voulez utiliser Xv, vous pouvez simplement désactiver le gestionnaire de composition et le réactiver lorsque vous avez terminé. o Les recouvrements sur station de travail sont incompatibles avec l'extension Composite. Vous trouverez davantage d'informations sur l'extension Composite sur http://freedesktop.org/Software/CompositeExt __________________________________________________________________________ (app-v) ANNEXE V : NVIDIA-SETTINGS __________________________________________________________________________ Utilitaire de configuration graphique, nvidia-settings est inclus avec le pilote graphique Linux de NVIDIA. Après voir installé le pilote et lancé X, vous pouvez exécuter cet utilitaire de configuration en exécutant : nvidia-settings dans une fenêtre de terminal. Des informations détaillées sur les options de configuration disponibles sont présentées dans la fenêtre d'aide de l'utilitaire. Pour plus d'informations, veuillez consulter le guide de l'utilisateur disponible sur : ftp://download.nvidia.com/XFree86/Linux-x86/nvidia-settings-user-guide.txt Le code source de nvidia-settings est distribué sous le GPL et est disponible sur : ftp://download.nvidia.com/XFree86/nvidia-settings/ __________________________________________________________________________ (app-w) ANNEXE W : L'EXTENSION X XRANDR __________________________________________________________________________ La version X.org X11R6.8.1 contient la prise en charge du composant de rotation de l'extension XRandR. Ceci permet de faire tourner les écrans par incréments de 90 degrés. Le pilote prend en charge la rotation avec l'extension lorsque " Option "RandRRotation" " est activé dans le fichier de configuration X. Les visuels de recouvrement CI ou RGB de station de travail fonctionnent avec des performances moindres lorsque RandRRotation est activé. Le recouvrement vidéo n'est pas disponible lorsque RandRRotation est activé. Vous pouvez obtenir les rotations disponibles en utilisant l'interface de ligne de commande " xrandr " avec l'extension RandR en exécutant ce qui suit : xrandr -q Vous pouvez fixer l'orientation de la rotation de l'écran en exécutant au choix : xrandr -o left (gauche) xrandr -o right (droite) xrandr -o inverted (inversé) xrandr -o normal (normal) La rotation peut également être définie par le biais de l'utilitaire de configuration nvidia-settings dans le panneau " Rotation Settings ".