Pilotes accélérés NVIDIA pour Linux - LISEZMOI et Guide d'installation NVIDIA Corporation Dernière mise à jour : 17/06/2005 Plus récente version du pilote : 1.0-7667 __________________________________________________________________________ Préface __________________________________________________________________________ Le jeu de pilotes accélérés NVIDIA pour Linux apporte à Linux x86 les fonctionnalités 2D et la prise en charge OpenGL haute performance avec les processeurs graphiques (GPU) NVIDIA. Ces pilotes fournissent une accélération matérielle optimisée pour les applications OpenGL et X et prennent en charge la majorité des processeurs graphiques NVIDIA récents (vous trouverez la liste complète des puces prises en charge dans l'annexe A). Les écrans TwinView, TV-Out et plats sont également pris en charge. Le présent fichier LISEZMOI décrit les procédures d'installation, de configuration et d'utilisation du jeu de pilotes accélérés NVIDIA pour Linux. Un forum aux questions et des diagnostics de problèmes courants sont également fournis. Ces pages sont consultables sur le site Web de NVIDIA (http://www.nvidia.com) et sont installées dans le répertoire /usr/share/doc/NVIDIA_GLX-1.0/. __________________________________________________________________________ Introduction __________________________________________________________________________ Ce document contient les instructions d'installation et d'utilisation du jeu de pilotes accélérés NVIDIA pour Linux. Le chapitre 1, le chapitre 2 et le chapitre 3 guident l'utilisateur dans le processus de téléchargement, d'installation et de configuration du pilote. Le chapitre 4 présente le forum aux questions relatif au processus d'installation et le chapitre 5 les solutions aux problèmes courants. Si des informations supplémentaires sont nécessaires, le chapitre 6 contient des informations de contact pour les ressources de pilotes NVIDIA pour Linux et le chapitre 7 une brève liste de ressources externes. Ce document part du principe que l'utilisateur comprend les rudiments des techniques et de la terminologie de Linux. Le chapitre 8 contient toutefois des détails sur certaines parties du processus d'installation que les nouveaux utilisateurs trouveront certainement utiles. Les annexes contiennent d'autres informations supplémentaires, notamment le matériel pris en charge, la configuration système requise, les listes d'options des divers utilitaires associés au pilote, les détails de configuration pour des configurations spécifiques et des rubriques et fonctions avancées. TABLE DES MATIÈRES Préface Introduction I. Instructions d'installation 1. Sélection et téléchargement des paquetages NVIDIA appropriés pour votre système 2. Installation du pilote NVIDIA 3. Configuration X pour le pilote NVIDIA II. Divers 4. Forum aux questions 5. Problèmes courants 6. Contacter NVIDIA 7. Ressources supplémentaires 8. Conseils pour les nouveaux utilisateurs de Linux 9. Remerciements III. Annexes A. Puces graphiques NVIDIA prises en charge B. Configuration logicielle minimale requise C. Composants installés D. Options de configuration X E. Configuration des variables d'environnement OpenGL F. Configuration d'AGP G. Configuration de Twinview H. Configuration de TV-Out I. Configuration d'un ordinateur portable J. Modes de programmation K. Flipping et UBB L. Problèmes connus M. Interface Proc N. Prise en charge de XVMC O. Prise en charge de GLX P. Configuration de plusieurs écrans X sur une carte Q. Prise en charge de la gestion de la consommation R. Noms des périphériques d'affichage S. L'extension X Composite T. L'utilitaire nvidia-settings U. L'extension XRandR V. Prise en charge de GLX dans Xinerama __________________________________________________________________________ Chapitre 1. Sélection et téléchargement des paquetages NVIDIA appropriés pour votre système __________________________________________________________________________ Vous pouvez télécharger les pilotes NVIDIA du site Web de NVIDIA (http://www.nvidia.com). Le pilote NVIDIA repose sur un modèle à architecture unifiée, dans lequel un unique jeu de pilotes est utilisé pour toutes les puces graphiques NVIDIA prises en charge (pour la liste des processeurs pris en charge, voir l'annexe A). L'utilisateur n'a plus à s'occuper de la tâche délicate de sélection du pilote adéquat et le jeu de pilotes se télécharge sous la forme d'un unique fichier nommé : “ NVIDIA-Linux-x86-1.0-7667-pkg1.run ” Le suffixe ("-pkg#") du paquetage permet de différencier les paquetages contenant le même pilote avec des interfaces de noyaux précompilées différentes. Le fichier ayant le numéro de paquetage le plus élevé est adapté à la plupart des installations. La prise en charge des GPU " existants " a été supprimée du pilote unifié. Ces GPU existants feront l'objet de versions spécifiques du pilote de GPU. Reportez- vous à l'annexe A pour la liste des GPU existants. Le fichier téléchargé est un programme d'installation auto-extractible que vous pouvez placer où vous voulez sur votre système. _________________________________________________________________________ Chapitre 2. Installation du pilote NVIDIA __________________________________________________________________________ Ce chapitre contient les instructions d'installation du pilote NVIDIA. Notez qu'après l'installation, mais avant d'utiliser le pilote, vous devez effectuer les opérations des étapes décrites dans le chapitre 3. Des détails supplémentaires sont fournis à l'intention des nouveaux utilisateurs de Linux dans le chapitre 8. OPÉRATIONS PRÉLIMINAIRES Avant de commencer l'installation du pilote, vous devez quitter le serveur X et arrêter (kill) toutes les applications OpenGL (sachez qu'il est possible que certaines applications OpenGL persistent même après l'arrêt du serveur X). Vous devez définir le niveau d'exécution par défaut de manière à amorcer le système sur une console VGA et pas directement dans X. Cette opération facilitera la restauration en cas de problème au cours de l'installation. Pour plus de détails, voir le chapitre 8. DÉMARRAGE DU PROGRAMME D'INSTALLATION Après avoir téléchargé le fichier « NVIDIA-Linux-x86-1.0-7667-pkg#.run”, passez au répertoire qui contient le fichier téléchargé et exécutez l'exécutable en tant qu'utilisateur " root " : # cd votrerépertoire # sh NVIDIA-Linux-x86-1.0-7667-pkg#.run Le fichier " .run " est auto-extractible. Exécuté, il extrait le contenu de l'archive et exécute l'utilitaire " nvidia-installer " qui est une interface interactive qui vous guidera dans l'installation. L'installation installe également l'utilitaire " nvidia-installer " qui peut être utilisé à un stade ultérieur pour désinstaller les pilotes, télécharger automatiquement les mises à jour des pilotes, etc. L'utilisation de cet utilitaire est détaillée plus loin dans ce chapitre. Vous pouvez aussi fournir des options de ligne de commande au fichier " .run ". certaines des options les plus courantes sont listées ci-dessous. Options courantes de " .run " --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-7667 ", 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. INSTALLATION DE L'INTERFACE DU NOYAU Le module de noyau NVIDIA dispose d'une couche d'interface de noyau qui doit être compilée spécifiquement pour chaque noyau, NVIDIA distribue le code source à cette couche d'interface noyau, ainsi que des versions précompilées pour un grand nombre des noyaux disponibles dans les distributions les plus répandues de Linux. 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). Le programme d'installation déterminera s'il dispose d'une interface de noyau précompilée pour votre système. S'il n'en a pas, il tentera d'en télécharger une du site ftp de NVIDIA et de la relier au module de noyau binaire. S'il ne parvient pas à en télécharger une, que ce soit pour des problèmes de connectivité réseau ou parce qu'il n'y en a pas, le programme d'installation contrôle votre système pour rechercher les sources de noyau requises puis compile l'interface pour vous. Si le programme d'installation compile l'interface noyau, vous devez installer le paquetage kernel-sources adapté à votre noyau. Si " nvidia-installer " doit compiler une interface de noyau pour votre noyau, vous aurez besoin des fichiers de prise en charge installés sur votre système. Sur la plupart des systèmes, cela signifie que vous devrez localiser et installer le package kernel-sources ou kernel-headers approprié ; sur certaines distributions récentes toutefois, aucun package supplémentaire n'est requis (par ex. Fedora Core 3, Red Hat Enterprise Linux 4). Vous remarquerez que pour relier l'interface de noyau (dans le cas où l'interface a été téléchargée ou compilée à l'installation), vous devez disposer d'un éditeur de liens sur votre système. L'éditeur de liens (habituellement " /usr/bin/ld ") fait partie du paquetage binutils. Si aucune interface de noyau précompilée n'est détectée, vous devez installer un éditeur de liens avant d'installer le pilote NVIDIA. CARACTÉRISTIQUES DU PROGRAMME D'INSTALLATION Sans options, le fichier " .run " exécute le programme d'installation après l'avoir dépaqueté. Le programme d'installation peut être exécuté dans le cadre d'une étape séparée du processus ou être exécuté à un moment ultérieur pour obtenir des mises à jour, etc. Voici quelques-unes des options de ligne de commande importantes de " nvidia-installer " : Options de " nvidia-installer " --uninstall Pendant l'installation, le programme d'installation effectue des sauvegardes des fichiers en conflit et enregistre l'installation des nouveaux fichiers. L'option uninstall défait une installation en ramenant le système dans l'état dans lequel il était avant l'installation. --latest L'utilitaire se connecte au site FTP de NVIDIA, signale la dernière version du pilote et l'url du fichier du dernier pilote. --update L'utilitaire se connecte au site FTP de NVIDIA, télécharge la dernière version du pilote et l'installe. --ui=none Le programme d'installation fait appel à une interface utilisateur de type ncurses s'il détecte la bibliothèque ncurses appropriée. À défaut, il revient à une interface de type ligne de commande. Cette option désactive l'utilisation de la bibliothèque de ncurses. Vous remarquerez que, comme suggéré par les options, 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). __________________________________________________________________________ Chapitre 3. Configuration X pour le pilote NVIDIA __________________________________________________________________________ Le fichier de configuration X fournit un moyen de configurer le serveur X. Cette section décrit les paramètres nécessaires pour activer le pilote NVIDIA. La liste complète des paramètres figure à l'annexe D. En avril 2004, la Fondation X.org a rendu disponible un serveur X reposant sur le serveur X XFree86. De nombreuses distributions de 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 : Le nom du fichier de configuration de X.org est " /etc/X11/xorg.conf " tandis que celui du fichier de configuration Xfree86 est " /etc/X11/XF86Config ", même si les fichiers utilisent la même syntaxe. Dans ce document, ces fichiers de configuration sont mentionnés de manière générique sous l'appellation " fichier de configuration X ". Le fichier journal X.org est " /var/log/Xorg.#.log " tandis que le fichier journal Xfree86 est "/var/log/XFree86.#.log " (où " # " est le numéro du serveur - en général 0). Le format de ces fichiers journaux est pratiquement identique. Dans ce document, ces fichiers sont mentionnés de manière générique sous l'appellation " fichier journal X ". Pour que les changements éventuels soient lus dans le serveur X, vous devez éditer le fichier utilisé par le serveur. Même s'il n'est pas déraisonné d'éditer les deux fichiers, il est relativement simple de déterminer le fichier correct en recherchant la ligne (==) Using config file: dans le fichier journal X. Cette ligne indique le nom du fichier de configuration X utilisé. Si vous ne possédez pas de fichier de configuration X opérationnel, vous pouvez en obtenir un de plusieurs manières. Un modèle de fichier de configuration est fourni avec la distribution XFree86 et avec le paquetage du pilote NVIDIA (ce fichier est installé dans " /usr/share/doc/NVIDIA_GLX-1.0/ "). De nombreuses distributions fournissent des outils permettant de générer un fichier de configuration (par exemple " xf86config "). Pour de plus amples informations sur la syntaxe de ce fichier, reportez-vous à la page man XF86Config (" 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 d'éditer ce fichier comme suit : Supprimez la ligne : Driver "nv" (ou Driver "vesa") (ou Driver "fbdev") Et remplacez-la par la suivante : Driver "nvidia" Supprimez les lignes suivantes : Load "dri" Load "GLCore" Dans la section "Module" du fichier, ajoutez la ligne suivante (si elle n'y figure pas déjà) : Load "glx" 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 l'édition 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, toute application OpenGL devrait utiliser automatiquement les nouvelles bibliothèques NVIDIA. Si vous rencontrez un problème, reportez-vous aux diagnostics de problèmes du chapitre 5. __________________________________________________________________________ Chapitre 4. Forum aux questions __________________________________________________________________________ Cette section contient les réponses aux questions fréquemment posées associées au pilote x86 NVIDIA pour Linux et à son installation. Des diagnostics de problèmes courants figurent au chapitre 5 tandis que des conseils s'adressant aux nouveaux utilisateurs sont donnés au chapitre 8. Par ailleurs, des informations détaillées relatives à des configurations spécifiques sont données dans les annexes. PROGRAMME D'INSTALLATION NVIDIA Q: Comment puis-je extraire le contenu du fichier " .run " sans installer le pilote ? R: Exécutez le programme d'installation comme suit : # sh NVIDIA-Linux-x86-1.0-7667-pkg1.run --extract-only Vous créerez ainsi le répertoire NVIDIA-Linux-x86-1.0-7667-pkg1, qui contiendra le contenu décompressé du fichier " .run ". 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-6629-pkg1.run --extract-only # cd NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/ Q. Comment et quand les fichiers de périphériques NVIDIA sont-ils créés ? A. En fonction de la configuration du système cible, les fichiers de périphériques NVIDIA étaient créés de trois manières différentes : - à l'installation en utilisant mknod - au chargement du module via devfs (système de fichiers de périphériques Linux) ; - au chargement du module via hotplug/udev. Avec les versions courantes du pilote NVIDIA, les fichiers de périphériques sont créés ou modifiés par le pilote X au démarrage du serveur X. Par défaut, le pilote NVIDIA essaiera de créer des fichiers de périphériques avec les attributs suivants : UID: 0 - 'root' GID: 0 - 'root' Mode: 0666 - 'rw-rw-rw-' Les fichiers de périphériques existants sont modifiés si leurs attributs ne correspondent pas à ces valeurs par défaut. Si vous voulez que le pilote NVIDIA crée les fichiers de périphériques avec d'autres attributs, vous pouvez spécifier ceux-là avec les paramètres " NVreg_DeviceFileUID " (utilisateur), " NVreg_DeviceFileGID " (groupe) et " NVreg_DeviceFileMode " du module de noyau Linux NVIDIA. Par exemple, le pilote NVIDIA peut se voir ordonner de créer des fichiers de périphériques avec UID=0 (root), GID=44 (vidéo) et Mode=0660 en passant les paramètres de module suivants au module de noyau Linux NVIDIA: NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 NVreg_DeviceFileMode=0660 Le paramètre de module de noyau " NVreg_ModifyDeviceFiles " désactivera la gestion de fichiers de périphériques dynamique, s'il est mis sur 0. 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 de noyau NVIDIA doit être compilée spécifiquement 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 de 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-7667-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 de 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 de 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-7667-pkg1.run --extract-only # cd NVIDIA-Linux-x86-1.0-7667-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 ", " SNARF_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 jeux différents d'interfaces de noyau précompilées. 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 uniquement par les interfaces de noyau précompilées qu'ils contiennent. En outre, les fichiers " .run " ayant un numéro pkg supérieur contiennent tout ce qu'il y a dans les fichiers " .run " dotés d'un numéro .pkg inférieur. Q: J'ai déjà installé NVIDIA-Linux-x86-1.0-7667-pkg1.run, mais je constate que NVIDIA-Linux-x86-1.0-7667-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-7667-pkg2.run ? R: Cela est inutile. Le pilote contenu dans tous les fichiers " .run " 1.0-7667 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 PILOTE NVIDIA Q: Par où dois-je commencer pour le diagnostic des problèmes d'affichage ? A. L'un des outils les plus efficaces pour le diagnostic de problèmes est le fichier journal X de " /var/log ". Les lignes qui commencent par " (II) " sont des informations, par " (WW) " des avertissements et 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 ". Recherchez : (II) LoadModule: "nvidia" Les lignes provenant du pilote devraient commencer par : (II) NVIDIA(0) Q. Comment puis-je augmenter la quantité de données imprimées dans le fichier journal X ? A. 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: 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, qui sont installés par défaut dans le cadre de l'installation du pilote. Si vous préférez que les fichiers d'en-tête OpenGL distribués par NVIDIA ne soient pas installés, vous pouvez passer l'option --no-opengl-headers au fichier " NVIDIA-Linux-x86-1.0-7667-pkg1.run " pendant l'installation. Q: Puis-je être informé par e-mail de la sortie de nouvelles versions du jeu 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=driver_update 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 le Web permettra probablement de trouver plusieurs correctifs. 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: 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 versions plus anciennes des pilotes ? R. Visitez ftp://download.nvidia.com/XFree86_40/ 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 : 2.3.98). Le nouveau guide de l’utilisateur, chapitre 8, contient davantage de conseils et astuces sur la définition des variables d’environnement. 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. Q: Pourquoi X se plante-t—il lorsqu’il démarre sur Fedora Core 4 ? R: Il existe des problèmes d’interaction avec SELinux (qui est activé par défaut sur Fedora Core 4) et le pilote de cartes graphiques NVIDIA. NVIDIA étudie actuellement ces problèmes mais il reste recommandé d’ajouter l’option d’initialisation du noyau « selinux=0 » à la ligne d’initialisation du noyau dans le fichier grub.conf. Vous devez réinstaller le pilote NVIDIA après l'ajout de cette option. Q : Je ne parviens pas à obtenir, en utilisant les utilitaires de configuration de GNOME, une résolution supérieure à 800x600. Quel est le problème ? R : L’installation de GNOME fournie dans certaines distributions telles que Red Hat Enterprise Linux 4 contient plusieurs interfaces permettant de spécifier la résolution : 'System Settings' -> 'Display' qui mettre à jour le fichier de configuration X, et 'Applications' -> 'Preferences' -> 'Screen Resolution' qui mettra à jour la résolution de l’écran par utilisateur en utilisant l’extension XRandR. La résolution de votre bureau sera limitée au plus petit de ces deux réglages. Pensez donc à les vérifier tous les deux. Q: Le fichier journal du serveur X contient le message suivant : (WW) NVIDIA(0): You appear to be using the XFree86-DGA extension. Please (WW) NVIDIA(0): be aware that support for this extension will be (WW) NVIDIA(0): removed from the NVIDIA driver in a future driver (WW) NVIDIA(0): release. See the NVIDIA README for details. Quels sont les projets de NVIDIA quant à la prise en charge de l'extension XFree86-DGA ? R: La prise en charge de l'extension XFree86-DGA va être supprimée du pilote NVIDIA dans une future version. Cela signifie que tandis que l'extension continuera à être publicisée et que XDGASelectInput() continuera à fonctionner correctement de sorte que les clients DGA puissent acquérir le mouvement relatif du pointeur, les points d'entrée DGA tels que XDGASetMode() et XDGAOpenFramebuffer() échoueront. Si vous préférez que la prise en charge DGA ne soit pas supprimée du pilote NVIDIA X, n'hésitez pas à communique vos préoccupations au forum Linux sur nvnews.net. Q : Le journal de mon noyau contient des messages dotés du préfixe " Xid " ; qu'est-ce que cela veut dire ? R : Les messages " Xid " indiquent qu'une erreur de GPU générale est survenue, souvent à cause d'un mauvaise programmation du GPU par le pilote ou de la corruption des commandes envoyées au GPU. Ces messages fournissent des informations de diagnostic qui peuvent être utilisées par NVIDIA pour faciliter le débogage des problèmes signalés. Q: Sur quel matériel NVIDIA l’extension OpenGL EXT_framebuffer_object est-elle prise en charge ? R: L’extension EXT_framebuffer_object est prise en charge sur les GPU GeForce FX et plus récents. __________________________________________________________________________ Chapitre 5. Problèmes courants __________________________________________________________________________ Cette section fournit des solutions aux problèmes courants associés au pilote x86 NVIDIA pour Linux. 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! 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-7667-pkg1.run --advanced-options " pour plus de détails). Les versions anciennes de module-init-tools contiennent des binaires « modprobe » qui rapportent une erreur lorsqu’il leur est demandé de charger un module qui est déjà chargé dans le noyau. Veuillez mettre à jour votre version de module-init-tools si vous recevez un message d’erreur de ce type. Le serveur X lit « /proc/sys/kernel/modprobe » pour déterminer le chemin de l’utilitaire « modprobe » et revient à « /sbin/modprobe » si le fichier n’existe pas. Veuillez contrôler la validité du chemin et fait référence à un binaire « modprobe » compatible avec le noyau Linux exécuté sur votre système. L’option « LoadKernelModule » du pilote X peut être utilisée pour changer le comportement par défaut et désactiver le chargement automatique du module du noyau. 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 (EE) NVIDIA(0): the 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 : Paramètre Comportement ------------------------------- ------------------------------- 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 (voir chapitre 3). Si votre fichier de configuration X est correct, regardez si e 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 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: Quake3 se bloque lorsque je change de mode vidéo. Que se passe-t-il ? R: Vous avez probablement rencontré un 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: 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: 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: 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: 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. 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'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 : # cd /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: 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: 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: 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: 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: 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: 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 de l'annexe D). 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. __________________________________________________________________________ Chapitre 6. Contacter NVIDIA __________________________________________________________________________ Un forum de discussion sur les pilotes NVIDIA pour Linux est disponible sur Internet. Pour y accéder, rendez-vous à l'adresse http://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 les chapitres 4 et 5 de ce document 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). __________________________________________________________________________ Chapitre 7. Ressources supplémentaires __________________________________________________________________________ Ressources ABI OpenGL Linux http://oss.sgi.com/projects/ogl-sample/ABI/ Le projet XFree86 http://www.xfree86.org/ XFree86 Video Timings HOWTO http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html La X.org Foundation http://www.x.org/ OpenGL http://www.opengl.org/ __________________________________________________________________________ Chapitre 8. Conseils pour les nouveaux utilisateurs de Linux __________________________________________________________________________ Ce guide d'installation part du principe que l'utilisateur maîtrise les rudiments des techniques et de la terminologie de Linux. Cette section contient des conseils et astuces que les nouveaux utilisateurs trouveront sans doute utiles. Ces conseils ont pour objectif de faciliter la compréhension des utilisateurs et de les aider à installer et à configurer le pilote NVIDIA pour Linux, mais ne constituent en aucun cas un didacticiel d’administration du système d'exploitation Linux. Contrairement à de nombreux systèmes d'exploitation d'ordinateur de bureau, il est relativement facile de causer des dommages irréversibles à un système Linux. Nous recommandons vivement à tous ceux qui n'ont pas l'habitude d'utiliser Linux de se munir d'un didacticiel par le biais de leur distributeur avant d'effectuer toute opération. L'INVITE DE COMMANDE Alors que les versions plus récentes de Linux mettent de nouvelles interfaces de bureau à la disposition des utilisateurs, sous Linux de nombreuses opérations s'effectuent à l'invite de commande. Si vous avez l'habitude du système d'exploitation Windows, l'invite de commande de Linux s'apparente à celle de Windows bien que sa syntaxe et son utilisation varient quelque peu. Toutes les commandes de cette section sont données à l'invite de commande. Certains systèmes sont configurés pour s'initialiser en mode console, cas dans lequel une invite s'affiche à la connexion. D'autre systèmes sont configurés pour lancer X windows, cas dans lequel l'utilisateur doit ouvrir une fenêtre de terminal ou de console pour obtenir une invite de commande. Cela peut en général être fait en recherchant un programme de terminal ou de console dans les menus de bureau. Personnalisable, l'invite de base consiste normalement en une courte chaîne d'informations, un des caractères " # ", " $ " ou " % " et un curseur (si possible clignotant) qui indique l'emplacement où s'affichera la saisie de l'utilisateur. NAVIGATION DANS LA STRUCTURE DES RÉPERTOIRES La structure de répertoires de Linux est de type hiérarchique. Où que vous vous trouviez à l'intérieur, la commande " ls " listera le contenu de ce répertoire. La commande " file" imprimera le type des fichiers contenus dans un répertoire. Par exemple : % file nomfichier Imprimera le type du fichier "nomfichier". Changer de répertoire se fait au moyen de la commande "cd". % cd nomrép fera de "nomrép" le répertoire courant. Où que vous vous trouviez dans la structure de répertoires, la commande " pwd " imprimera le nom du répertoire courant. Il existe deux répertoires spéciaux " . " et " .. ", qui font référence au répertoire courant et au répertoire immédiatement successif dans la hiérarchie. Pour toute commande requerrant un nom de fichier ou un nom de répertoire comme argument, vous pouvez spécifier les chemins absolus ou relatifs de ces éléments. Un chemin absolu commence par le caractère "/" qui fait référence au répertoire supérieur ou racine de la structure de répertoires. Un chemin relatif commence par un répertoire dans le répertoire de travail courant. Le chemin relatif peut commencer par "." ou " .. ". Les éléments d'un chemin sont séparés par le caractère " /". À titre d'exemple, si le répertoire courant est " /home/jesse" et que l'utilisateur veut passer au répertoire " /usr/local ", il peut utiliser l'une des commandes suivantes pour le faire : % cd /usr/local Ou % cd ../../usr/local PERMISSIONS ET PROPRIÉTÉS DES FICHIERS Des permissions et un propriétaire sont associés à tous les fichiers et répertoires. Cela est utile pour empêcher des utilisateurs non-administratifs de corrompre involontairement (ou non) le système. Les permissions et le propriétaire d'un fichier ou d'un répertoire peuvent être déterminés en ajoutant l'option -l à la commande "ls". Par exemple : % ls -l drwxr-xr-x 2 jesse users 4096 Feb 8 09:32 bin drwxrwxrwx 10 jesse users 4096 Feb 10 12:04 pub -rw-r--r-- 1 jesse users 45 Feb 4 03:55 testfile -rwx------ 1 jesse users 93 Feb 5 06:20 myprogram -rw-rw-rw- 1 jesse users 112 Feb 5 06:20 README % La première colonne de caractères dans le premier champ de la sortie indique le type du fichier : " d " correspond à un répertoire et " -" à un fichier normal. Les neuf colonnes suivantes précisent les permissions (voir plus bas) de l'élément. Le second champ indique le nombre de fichiers associés à cet élément, le troisième champ indique le propriétaire, le quatrième indique le groupe auquel le fichier est associé, le cinquième la taille de l'élément en octets, le sixième, le septième et le huitième indiquent l'heure de la dernière modification du fichier et le nom de l'élément. Comme annoncé, les dernières neuf colonnes du premier champ indiquent les permissions de l'élément. Ces colonnes sont regroupées en trois groupes : le premier indique les permissions associées au propriétaire de l'élément ("jesse " dans ce cas), le second les permissions du groupe associé à l'élément et le troisième les permissions associées au reste du monde. Les lettres " r", "w" et "x" indiquent, respectivement, les permissions de lecture, d'écriture et d'exécution, pour chacune de ces associations. Par exemple, l'utilisateur "jesse" a des permissions de lecture et d'écriture pour " testfile ", les utilisateurs du groupe " users " ont uniquement des permissions de lecture, idem pour le reste du monde. Pour le fichier " myprogram" en revanche, l'utilisateur "jesse" a des permissions de lecture, d'écriture et d'exécution (ce qui suggère que "myprogram2 est un programme qui peut être exécuté), tandis que le groupe " users" et le reste du monde n'ont aucune permission (ce qui laisse penser que le propriétaire ne veut que personne d'autre exécute ce programme). Les permissions, le propriétaire et le groupe associés à un élément peuvent être changés avec, respectivement, les commandes " chmod ", " chown " et " chgrp ". Si un utilisateur ayant les permissions appropriées veut changer la propriété utilisateur/groupe du fichier " README " de jesse/users à joe/admin, il doit procéder comme suit : # chown joe README # chgrp admin README La syntaxe à employer pour chmod est légèrement plus compliquée et présente plusieurs variations. La façon la plus concise de définir les permissions pour un élément donné consiste à utiliser une triplette de nombres : un pour l'utilisateur, un pour le groupe et un pour le monde. La valeur de chaque nombre dans la triplette correspond à une combinaison de permissions de lecture, écriture et exécution. L'exécution seule est représentée par un 1, l'écriture seule par un 2 et la lecture seule par un 4. Les combinaisons de ces permissions sont représentées comme des sommes de permissions individuelles. Le duo lecture et exécution correspond à 5, tandis que la triplette lecture, écriture et exécution, correspond à 7. Aucune permission n’est représentée par 0. Par conséquent, pour donner au propriétaire des permissions de lecture, d'écriture et d'exécution, au groupe des permissions de lecture et d'exécution et au monde aucune permission, l'utilisateur doit saisir : % chmod 750 myprogram LE SHELL Le shell ou interpréteur de commandes fournit une interface entre l'utilisateur et le système d'exploitation. Il a pour tâche d'interpréter la saisie de l'utilisateur à l'invite de commande et d'appeler le système à faire quelque chose en réponse. Plusieurs shells différents sont disponibles, présentant chacun une syntaxe et des fonctions propres. Les deux shells les plus courants pour les distributions de Linux sont le Borne shell (" sh ") et le C-shell (" csh ") Les utilisateurs ont leurs préférences et opteront pour l'un ou l'autre. Selon le shell choisi certaines opérations seront plus simples (ou plus intuitives). Vous pouvez déterminer le shell courant en imprimant la valeur " SHELL" depuis l'invite de commande avec % echo $SHELL Vous pouvez lancer un nouveau shell en entrant simplement le nom à l'invite de commande : % csh Ou % sh Enfin, vous pouvez exécuter un programme depuis un shell spécifique en faisant précéder le nom de l'exécutable du nom du shell dans lequel il sera exécuté : % sh myprogram Le shell par défaut de l'utilisateur à la connexion est déterminé par la personne qui configure son compte. S'il y a de nombreuses différences de syntaxe entre les shells, la plus fréquente est sans aucun doute la façon dont sont définies les variables d’environnement. DÉFINITION DES VARIABLES D'ENVIRONNEMENT Chaque session est associée à des variables d'environnement, qui consistent en des paires nom/valeur et contrôlent la façon dont le shell et les programmes exécutés depuis le shell se comportent. Un exemple de variable d'environnement est la variable " PATH ", qui indique au shell quels répertoires explorer pour tenter de localiser un fichier exécutable que l'utilisateur a entré à la ligne de commande. Si vous êtes certain qu'une commande existe alors que le shell signale ne pas arriver à la trouver lorsque vous essayez de l'exécuter, il y a certainement un problème au niveau de la variable " PATH ". Les variables d'environnement dépendent dans des mesures différentes du shell utilisé. Pour le Borne shell ('sh'), cela se fait comme suit : % export MYVARIABLE="avalue" Pour le C-shell, comme suit : % setenv MYVARIABLE "avalue" Dans les deux cas les guillemets sont uniquement nécessaires si la valeur contient des espaces. La commande " echo" peut être utilisée pour examiner la valeur d'une variable d'environnement : % echo $MYVARIABLE Les commandes permettant de définir les variables d'environnement peuvent également inclure des références à d'autres variables d'environnement (précédées du caractère "$") et, même, à elles-mêmes. Pour ajouter le chemin " /usr/local/bin" au début du chemin de recherche et le répertoire courant " . " à la fin du chemin de recherche, l'utilisateur doit entrer % export PATH=/usr/local/bin:$PATH:. dans le Borne shell, et % setenv PATH /usr/local/bin:${PATH}:. dans le C-shell. Vous remarquerez que les accolades sont requises pour protéger le nom de la variable dans le C-shell. ÉDITION DES FICHIERS DE TEXTE Plusieurs éditeurs de texte sont disponibles pour le système d'exploitation Linux. Certains de ces éditeurs requièrent le système X Windows, tandis que d'autres sont conçus pour fonctionner dans une console ou un terminal. Il convient en général de savoir utiliser un éditeur basé sur un terminal, car il arrive que les fichiers nécessaires pour que X s'exécute soient ceux qui doivent être édités. Trois éditeurs courants sont "vi", " pico" et "emacs". Ils peuvent tous être démarrés de la ligne de commande, en option en fournissant le nom d'un fichier à éditer. " vi" est sans doute à la fois le plus courant et le moins intuitif des trois. " pico" est relativement simple pour un novice mais n'est pas souvent installé sur les systèmes. " emacs" est hautement extensible et raisonnablement répandu mais peut se révéler quelque peu compliqué dans un environnement non-X. Les versions les plus récentes sont toutes accompagnées d'une aide en ligne et une aide hors ligne figure dans le manuel et les pages d'infos correspondants (veuillez consulter la section sur le manuel de Linux et les pages d'infos). De nombreux programmes utilisent la variable d'environnement " EDITOR " pour déterminer quel éditeur de texte démarrer lorsque des opérations d'édition sont requises. UTILISATEUR ROOT À l'installation, pratiquement toutes les distributions configurent l'utilisateur administratif par défaut " root". Il y a de nombreuses opérations sur le système que seul l'utilisateur "root » (ou un utilisateur aux privilèges similaires) peut effectuer, comme par exemple installer le pilote NVIDIA pour Linux. Il y a trois façons de devenir « root ». Vous pouvez vous connecter en tant que root comme vous le feriez sous n’importe quel autre nom d’utilisateur, utiliser la commande d’utilisateur de substitution (« su »') à l’invite de commande ou, certains systèmes étant livrés avec « sudo », utiliser la capacité de ce dernier d’exécuter des programmes en tant que root tout en conservant un journal de leurs actions. Cette dernière méthode est utile dans le cas où un utilisateur causerait par inadvertance des dommages au système et ne parviendrait pas à se souvenir de ce qu’il a fait (ou préfèrerait ne pas le dire). Il convient en général de ne rester root que le temps nécessaire pour accomplir la tâche requerrant des privilèges root (une fonction utile de l’utilitaire « sudo »). INITIALISATION À UN NIVEAU D’EXÉCUTION DIFFÉRENT Dans Linux, les niveaux d’exécution déterminent les services qui démarrent et s’arrêtent automatiquement lorsque le système s’initialise ou s’arrête. Les niveaux d’exécution vont en général de 0 à 6, le niveau 5 démarre en général X Windows dans le cadre des services (le niveau d’exécution 0 correspond à l’arrêt du système, le niveau 6 à son redémarrage). Il convient d’installer le pilote NVIDIA pour Linux tant que X ne fonctionne pas et d’empêcher le lancement de X au démarrage dans le cas où il y aurait des problèmes avec l’installation (sinon, vous risqueriez de vous retrouver avec un système endommagé qui essaiera automatiquement de lancer X mais s’arrêtera brusquement au démarrage vous empêchant d’effectuer les opérations nécessaires pour réparer X). Selon la configuration de votre réseau, les niveaux d’exécution 1, 2 ou 3 devraient être suffisants pour installer le pilote. Le niveau 3 inclut en général des services de mise en réseau, de sorte que si les utilitaires utilisés par le système pendant l’installation dépendent d’un système de fichiers distant, les niveaux 1 et 2 sont insuffisants. Si votre système s’initialise en général en mode console à invite de commande, vous ne devriez rien avoir à changer. S’il s’initialise normalement en mode X Windows avec une connexion graphique et un bureau, vous devez sortir de X Windows et changer votre niveau d’exécution par défaut. Sur la plupart des distributions, le niveau d’exécution par défaut est stocké dans le fichier « /etc/inittab » même s’il convient de consulter le guide qui accompagne votre distribution. La ligne qui indique le niveau d’exécution par défaut ressemble à id:n:initdefault: "n" indiquant le numéro du niveau d’exécution. « /etc/inittab » doit être édité en tant que root. Veuillez lire les sections sur l’édition des fichiers et l’utilisateur root si ces concepts ne vous sont pas familiers. Il est par ailleurs aussi recommandé de créer une copie du fichier avant de l’éditer, en particulier si vous n’avez pas l’habitude des éditeurs de texte Linux pour si jamais vous endommagiez sans le vouloir le fichier : # cp /etc/inittab /etc/inittab.original La ligne doit être éditée de sorte qu’un niveau d’exécution approprié soit défini par défaut (1, 2 ou 3 sur la plupart des systèmes) : id:3:initdefault: Une fois les changements enregistrés, quittez X. Une fois l’installation du pilote terminée, vous pourrez revenir au niveau d’exécution par défaut d’origine soit en éditant de nouveau « /etc/inittab » soit en redonnant son nom d’origine à la copie de sauvegarde. Les différentes distributions fournissent différentes façons de quitter X Windows. Sur de nombreux systèmes, l’utilitaire « init » change le niveau d’exécution courant. Cette solution peut être utilisée pour passer à un niveau d’exécution dans lequel X ne fonctionne pas. # init 3 D’autres méthodes permettent de sortir de X, veuillez consulter votre distribution. MANUEL LINUX ET PAGES D’INFOS La plupart des distributions installent par défaut le manuel du système ou ses pages d’infos. Ces pages sont en général à jour et contiennent une liste complète de l’utilisation des programmes et utilitaires du système. De même, de nombreuses implémentations des programmes incluent traditionnellement l’option –help, qui imprime normalement la liste des options courantes du programme en question. Pour afficher la page de manuel d’une commande, entrez % man nomcommande à l’invite de commande, « nomcommande » étant la commande qui vous intéresse. De façon similaire, entrer % info nomcommande affichera la page d’infos de la commande. Certaines distributions peuvent indiquer que certaines pages sont plus à jour que d’autres. L’interface utilisée pour le système d’infos est interactive et navigable. Si vous ne parvenez pas à localiser la page de manuel de la commande qui vous intéresse, il est possible que vous deviez ajouter des éléments à votre variable d’environnement « MANPATH ». Veuillez consulter la section consacrée aux variables d’environnement. Chapitre 9. Remerciements __________________________________________________________________________ « nvidia-installer » s’inspire de l’outil « loki_update » : http://www.lokigames.com/development/loki_update.php3/ La prise en charge de ftp et d’http dans « nvidia-installer » est basée sur "snarf 7.0 » : http://www.xach.com/snarf/ Le fichier d’archive auto-extractible (fichier aka '.run') est généré en utilisant « makeself.sh » : http://www.megastep.org/makeself/ __________________________________________________________________________ Annexe A. Processeurs graphiques NVIDIA pris en charge __________________________________________________________________________ Nom du processeur NVIDIA IP PCI du périphérique ------------------------------- ------------------------------- GeForce 6800 Ultra 0x0040 GeForce 6800 0x0041 GeForce 6800 GT 0x0045 GeForce 6800 GT 0x0046 Quadro FX 4000 0x004E GeForce 7800 GTX 0x0091 GeForce 6800 0x00C1 GeForce 6800 LE 0x00C2 GeForce 6800 Ultra 0x0040 GeForce 6800 0x0041 GeForce 6800 GT 0x0045 GeForce 6800 GT 0x0046 Quadro FX 4000 0x004E GeForce 6800 0x00C1 GeForce 6800 LE 0x00C2 GeForce Go 6800 0x00C8 GeForce Go 6800 Ultra 0x00C9 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 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 0x00FD Quadro FX 330 0x00FD Quadro FX 1300 0x00FE GeForce PCX 4300 0x00FF 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 6600 LE 0x0142 GeForce Go 6600 0x0144 GeForce 6610 XL 0x0145 GeForce Go 6600 TE/6200 TE 0x0146 GeForce Go 6600 0x0148 GeForce Go 6600 GT 0x0149 Quadro FX 540 0x014E GeForce 6200 0x014F GeForce 6200 TurboCache(TM) 0x0161 GeForce Go 6200 0x0164 GeForce Go 6400 0x0166 GeForce Go 6200 0x0167 GeForce Go 6400 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 intégré GeForce2 0x01A0 GPU intégré GeForce4 MX 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/600 PCI 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 La liste ci-dessous contient des GPU qui ne sont plus pris en charge dans le pilote unifié. Pour ces GPU, des versions spéciales du pilote NVIDIA devront être employées. Nom du processeur NVIDIA ID PCI du périphérique ------------------------------- ------------------------------- 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 Aladdin TNT2 0x00A0 GeForce 256 0x0100 GeForce DDR 0x0101 Quadro 0x0103 GeForce2 GTS/GeForce2 Pro 0x0150 GeForce2 Ti 0x0151 GeForce2 Ultra 0x0152 Quadro2 Pro 0x0153 __________________________________________________________________________ Annexe B. Configuration logicielle minimale requise __________________________________________________________________________ Élément logiciel Min. requis Contrôler avec... ------------------ ------------------ ------------------ Noyau Linux 2.4.0 `cat /proc/version` XFree86/Xorg 4.0.1/6.7 `XFree86 -version/Xorg -version` Kernel modutils 2.1.121 `insmod -v` Si vous devez construire le module du noyau NVIDIA : Élément logiciel Min. requis Contrôler avec... ------------------ ------------------ ------------------ binutils 2.9.5 `size - -version` GNU make 3.77 `make -- version` gcc 2.91.66 `gcc -- version` glibc 2.0 `ls /lib/libc.so.* > 6` Si vous faites la construction à partir de rpms : Élément logiciel requis Contrôler avec... ------------------------------- ------------------------------- 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 http://www.xfree86.org). Ces paquetages de logiciels sont également disponibles auprès de votre distributeur Linux. ________________________________________________________________________ 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) : 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. 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. 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. 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. 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 à l’annexe N. 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 cœur 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. Fichiers d'en-tête OpenGL et GLX (/usr/include/GL/gl.h, /usr/include/GL/glext.h, /usr/include/GL/glx.h et /usr/include/GL/glext.h). Ces fichiers peuvent également être installés dans /usr/share/doc/NVIDIA_GLX-1.0/include/GL/. en passant l'option "--opengl-headers" dans le fichier .run pendant l'installation. 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. 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 le chapitre 2. 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 ldconfig peut créer des liens symboliques incorrects lorsque le "soname" 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". __________________________________________________________________________ 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 : Valeur Comportement ----------------------------- ----------------------------- 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 U. Par défaut : désactivée. Option "AllowDDCCI" "booléen" Permet la prise en charge de DDC/CI dans l’extension NV-CONTROL X. DDC/CI est un mécanisme permettant la communication entre votre ordinateur et votre périphérique d’affichage. Il peut être utilisé pour définir les valeurs normalement contrôlées par le biais du On Screen Display de votre périphérique d’affichage. Veuillez vous reporter aux attributs DDC/CI NV-CONTROL dans « NVCtrl.h » et aux fonctions de « NVCtrlLib.h » dans le code source « nvidia-settings ». Par défaut : DDC/CI est désactivé. 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 G. 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 G. 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 G. 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 G. 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 G. 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 à l’annexe H pour les détails de configuration de la sortie TV. Option "TVOutFormat" "chaîne" Reportez-vous à l’annexe H pour les détails de configuration de la sortie TV. 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 à l’annexe H pour les détails de configuration de la sortie TV. 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 : Valeur Équipement ----------------------------- ----------------------------- 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 : Option "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" Force l’initialisation du serveur X avec les synchronisations exactes spécifiées dans le ModeLine. Valeur par défaut : pour les périphériques DVI, le serveur X s’initialise avec le mode le plus proche dans la liste EDID. Option "Coolbits" "entier" Permet la prise en charge dans l’extension X NV-CONTROL de la manipulation des paramètres de l’horloge du GPU. Quand cette option est sur « 1 », l’utilitaire nvidia-settings contient une page étiquetée « Clock Frequencies » qui permet de manipuler les paramètres de l’horloge. AVERTISSEMENT : cette opération peut causer l’endommagement du système et l’annulation des garanties. Cet utilitaire peut en effet faire tourner votre système en dehors des spécifications de conception du fabricant, par exemple, et sans limitation aucune, le faire tourner à : des tensions système supérieures, des températures au-dessus de la normale, des fréquences excessives et avec des changements du BIOS susceptibles d’endommager BIOS. Le système d’exploitation de votre ordinateur risque de se bloquer ce qui pourra se traduire par des pertes de données ou des images endommagées. Selon le fabricant de votre ordinateur, les garanties couvrant l’ordinateur, le matériel et les logiciels risquent d’être annulées, et vous pourrez ne plus bénéficier du support du fabricant. NVIDIA ne fournit pas de support à la clientèle pour l’option Coolbits. C’est pour ces raisons qu’absolument aucune garantie d’aucune sorte, ni expresse ni tacite, n’est accordée. Avant d’activer cette option et de l’utiliser, vous devez évaluer si l’utilitaire est approprié à l’usage que vous voulez en faire et prendre toutes les responsabilités relatives à ces opérations. Option "LoadKernelModule" "booléen" Par défaut, le module du pilote X NVIDIA pour Linux X tentera de charger le module de noyau NVIDIA Linux. Définissez cette option sur "off" pour désactiver le chargement automatique du module de noyau NVIDIA par le pilote X de NVIDIA. __________________________________________________________________________ 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, GeForce 6xxx, GeForce 7xxx, 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. __________________________________________________________________________ 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 M). 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. Chipsets AGP pris en charge ------------------------------------------------- Intel 440LX Intel 440BX Intel 440GX Intel 815 ("Solano") Intel 820 ("Camino") Intel 830 Intel 840 ("Carmel") Intel 845 ("Brookdale") Intel 845G Intel 850 ("Tehama") Intel 855 ("Odem") Intel 860 ("Colusa") Intel 865G ("Springdale") Intel 875P ("Canterwood") Intel E7205 ("Granite Bay") Intel E7505 ("Placer") AMD 751 ("Irongate") AMD 761 ("IGD4") AMD 762 ("IGD4 MP") AMD 8151 ("Lokar") VIA 8371 VIA 82C694X VIA KT133 VIA KT266 VIA KT400 VIA P4M266 VIA P4M266A VIA P4X400 VIA K8T800 RCC CNB20LE RCC 6585HE Micron SAMDDR ("Samurai") Micron SCIDDR ("Scimitar") NVIDIA nForce NVIDIA nForce2 NVIDIA nForce3 ALi 1621 ALi 1631 ALi 1647 ALi 1651 ALi 1671 SiS 630 SiS 633 SiS 635 SiS 645 SiS 646 SiS 648 SiS 648FX SiS 650 SiS 655FX SiS 730 SiS 733 SiS 735 SiS 745 SiS 755 ATI RS200M Si vous rencontrez des problèmes de stabilité AGP, gardez à l’esprit les points suivants : Informations supplémentaires sur AGP 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" 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-7667-pkg1.run --extract-only # cd NVIDIA-Linux-x86-1.0-7667-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. 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). 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. 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. __________________________________________________________________________ Annexe G. 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) : 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é. 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. 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 un écran X distinct, reportez-vous à l’annexe P. 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 : TwinView Cette option est nécessaire pour activer TwinView ; si elle n'a pas été ajoutée, toutes les options TwinView seront ignorées. 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). 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 R. 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. 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" 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 (++) Xinerama: 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 à l’annexe P. 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. __________________________________________________________________________ Annexe H. Configuration de la sortie TV __________________________________________________________________________ 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 : 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 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. Il faut ajouter l'option "TVStandard" dans votre section Screen ; les valeurs admises sont : TVStandard Description ----------------------------- ----------------------------- "PAL-B" Belgique, Danemark, Finlande, Allemagne, Guinée, Hong Kong, Inde, Indonésie, Italie, Malaisie, 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. 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" 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" 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. ___________________________________________________________________________ Annexe I. 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. À 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 : Valeur Signification ------------------------------- ------------------------------- 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 : modifier os-registry.c dans le répertoire usr/src/nv/ du fichier .run ; entrer la valeur sur la ligne de commande modprobe (par ex. : `modprobe nvidia NVreg_SoftEDIDs=0 NVreg_Mobile=3`) ; 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 Cette section examine les fonctionnalités additionnelles associées à la configuration d’un ordinateur portable. 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 G 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, le modeline suivant pourra vous être utile : # -- 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 Voici certains problèmes connus associés aux ordinateurs portables : Le basculement LCD/CRT par touche clavier ne fonctionne pas sur les ordinateurs portables Toshiba, exception faite du Satellite 3000. TwinView ne fonctionne pas sur l'ordinateur portable Toshiba Satellite 2800. 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. __________________________________________________________________________ Annexe J. 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 http://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 : 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. 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(). 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). 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. 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. 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. 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. 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. 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. La longueur de trame horizontale (HFL) doit être un multiple de 8, supérieure ou égale à 40 et inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. La résolution verticale (VR) doit être inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. 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. Le sync start vertical (VSS) doit être inférieur ou égal à la valeur indiquée dans le tableau ci-dessous. 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. 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. 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 # name PCLK HR HSS HSE HFL VR VSS VSE VFL 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 : 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. 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" INFORMATIONS ADDITIONNELLES Un générateur de modelines XFree86 conforme à la norme GTF est disponible sur http://gtf.sourceforge.net/. Pour obtenir d'autres générateurs de modelines, vous pouvez rechercher "modeline" sur freshmeat.net. __________________________________________________________________________ Annexe K. 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. 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. 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. __________________________________________________________________________ Annexe L. Problèmes connus __________________________________________________________________________ Les problèmes suivants existent encore dans cette version et leur résolution est actuellement à l'étude. 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, voir el chapitre 4. 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. 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 à l’annexe C 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. 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. 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 (voir l’entrée relative à l’aliasing du cache pour en savoir plus sur l’aliasing du cache). 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. Aliasing du cache L’aliasing du cache se produit quand plusieurs mappages vers une page physique de mémoire présentent des états de cache en conflit, tels que cached et uncached. À cause de ces états en conflit, les données de la page physique risquent d’être corrompues lors du vidage du cache du processeur. Si cette page est utilisée pour dma par un pilote tel que le pilote de carte graphique de NVIDIA, cela peut donner des problèmes de stabilité du matériel et des verrouillages. NVIDIA a rencontré des bogues avec certaines versions du noyau de Linux, qui entraînent l’aliasing du cache. Bien que certains systèmes tournent parfaitement en cas d’aliasing du cache, d’autres expérimenteront des problèmes de stabilité graves, dont des verrouillages aléatoires. Ces derniers utilisateurs auront tout intérêt à effectuer une mise à jour vers un noyau qui n’entraîne pas aliasing du cache. NVIDIA a ajouté une logique de pilote pour détecter l’aliasing du cache et imprimer un avertissement comportant un message similaire au suivant : NVRM: bad caching on address 0x1cdf000: actual 0x46 != expected 0x73. Si vous voyez ce message dans vos fichiers journaux et avez des problèmes de stabilité, vous devez mettre à jour votre noyau vers la dernière version. Si le message persiste après la mise à jour du noyau, veuillez envoyer un rapport de bogue à NVIDIA. BAR 64 bits (Base Address Registers) À commencer des GPU PCI Express natifs, les GPU NVIDIA disposeront d’une fonction BAR 64 bits (un Base Address Register stocke l’emplacement d’une région E/S PCI, tels que des registres ou une mémoire graphique). Cela signifie que les régions E7S PCI du GPU pourront être placées au-dessus de l’espace d’adresse 32 bits (les 4 premiers 4 giga-octets de mémoire). C’est le BIOS du système qui décide au moment de l’initialisation où placer le BAR. Si le BIOS prend en charge les BAR 64 bits, les régions E/S PCI du BIOS pourront être placées au-dessus de l’espace d’adresse 32 bits. Si le BIOS ne prend pas en charge cette fonction, vos régions E/S PCI seront placées au sein de l’espace d’adresse 32 bits comme elles l’ont toujours été. Les noyaux Linux courants (tels que le 2.6.11.x) ne comprennent pas ni ne prennent en charge les BAR 64 bits. Si le BIOS place des régions E/S PCI NVIDIA au-dessus de espace d’adresse 32 bits, le noyau rejettera le BAR et le pilote NVIDIA ne fonctionnera pas. Il n’y a actuellement pas de solution. Ordinateurs portables Si vous utilisez un ordinateur portable, reportez-vous aux "Problèmes connus concernant les ordinateurs portables" dans l'annexe I. 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. 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. XVideo et l'extension X Composite XVideo ne fonctionne pas correctement lorsque Composite est activé. Voir l’annexe S. 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 : Problèmes qui ne seront pas corrigés 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. 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. 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. 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 F. 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. 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. __________________________________________________________________________ Annexe M. 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 : /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. /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. /proc/driver/nvidia/agp/card Informations sur les capacités AGP de la carte AGP installée. /proc/driver/nvidia/agp/host-bridge Informations sur le host bridge (modèles et capacités AGP). /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. __________________________________________________________________________ Annexe N. 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. __________________________________________________________________________ Annexe O. 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. __________________________________________________________________________ Annexe P. Configuration de plusieurs écrans X sur une carte __________________________________________________________________________ Les puces graphiques qui prennent en charge TwinView (consultez l’annexe G) 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 : 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. 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. 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). __________________________________________________________________________ Annexe Q. 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. __________________________________________________________________________ Annexe R. 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" __________________________________________________________________________ Annexe S. L’extension composite X __________________________________________________________________________ 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 l’annexe D 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 l’annexe D. 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 : 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é. 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 __________________________________________________________________________ Annexe T. L’utilitaire 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/ __________________________________________________________________________ Annexe U. L’extension 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 ". Il faut savoir que la rotation n’est pas prise en charge actuellement lorsque TwinView est activé. __________________________________________________________________________ Annexe V. Prise en charge de GLX dans Xinerama __________________________________________________________________________ Ce pilote prend en charge GLX quand Xinerama est activé sur des GPU similaires. L’extension Xinerama rassemble plusieurs écrans X physiques (si possible sur plusieurs GPU) qu’elle relie en un écran X logique. Cela permet de faire glisser des fenêtres entre des GPU et de répartir une fenêtre sur plusieurs GPU. Le pilote NVIDIA prend en charge le rendu OpenGL accéléré par le matériel sur tous les GPU NVIDIA lorsque Xinerama est activé. Pour configurer Xinerama : configurez plusieurs écrans X (veuillez consulter les pages de manuel XF86Config(5x) ou xorg.conf(5x) pour plus de détails). L’extension Xinerama peut être activée en ajoutant la ligne Option "Xinerama" "True" à la section « ServerFlags » de votre fichier de configuration X. Configuration requise : Il est recommandé d’utiliser des GPU identiques. Certaines combinaisons de GPU non-identiques mais similaires sont prises en charge. Si un GPU est incompatible avec le reste d’un bureau Xinerama alors aucun rendu OpenGL ne s’affichera sur les écrans pilotés par ce GPU. Le rendu apparaîtra normalement sur les écrans connectés à des GPU pris en charge. Dans ce cas, le fichier journal X inclura un message de la forme suivante : (WW) NVIDIA(2): The GPU driving screen 2 is incompatabile with the rest of (WW) NVIDIA(2): the GPUs composing the desktop. OpenGL rendering will (WW) NVIDIA(2): be disabled on screen 2. Le pilote X NVIDIA X doit être utilisé pour tous les écrans X du serveur. Seule l’intersection des capacités entre tous les GPU sera affichée. Les options de configuration X qui affectent le fonctionnement GLX (par exemple : stéréo, recouvrements) doivent être définies de façon cohérente pour tous les écrans X du serveur X. Problèmes connus : La dimension de la fenêtre maximale pouvant être rendue est de 4 096 pixels. Les versions de XFree86 antérieures à la 4.5 et les versions de X.org antérieures à la 6.8.0 sont dépourvues des interfaces requises pour implémenter correctement les superpositions avec l’extension Xinerama. Sur les versions antérieures du serveur, mélanger les superpositions et Xinerama sera à l'origine d’un rendu corrompu. Si vous utilisez l’extension Xinerama avec des superpositions, il est recommandé d'effectuer une mise à niveau à XFree86 4.5, X.org 6.8.0 ou une version plus récente.