LEGGIMI e guida all'installazione di NVIDIA Accelerated Linux Driver Set Ultimo aggiornamento: $Date: 20/01/2004 $ Driver più recente: 1.0-5336 NVIDIA Accelerated Linux Driver Set permette di sfruttare le GPU NVIDIA con Linux e offre il supporto delle funzioni 2D accelerate e delle API OpenGL ad alte prestazioni. Questi driver consentono un'accelerazione hardware ottimizzata delle applicazioni OpenGL grazie a un server X di rendering diretto e supportano quasi tutti i chipset grafici NVIDIA (consultare l'APPENDICE A per un elenco completo dei chip supportati). Vengono supportati anche TwinView, TV-Out e display a schermo piatto. Questo file LEGGIMI descrive come installare, configurare e utilizzare NVIDIA Accelerated Linux Driver Set. Questo file LEGGIMI si trova sul sito Web di NVIDIA (www.nvidia.com) e viene installato in /usr/share/doc/NVIDIA_GLX-1.0/. __________________________________________________________________________ CONTENUTO: (sec-01) SCELTA DEI PACCHETTI NVIDIA ADATTI AL SISTEMA (sec-02) INSTALLAZIONE DEI PACCHETTI NVIDIA_KERNEL E NVIDIA_GLX (sec-03) MODIFICA DEL FILE XF86CONFIG (sec-04) DOMANDE FREQUENTI (sec-05) COME CONTATTARE NVIDIA (sec-06) ULTERIORI RISORSE (app-a) APPENDICE A: CHIP GRAFICI NVIDIA SUPPORTATI (app-b) APPENDICE B: REQUISITI SOFTWARE MINIMI (app-c) APPENDICE C: COMPONENTI INSTALLATI (app-d) APPENDICE D: OPZIONI XF86CONFIG (app-e) APPENDICE E: IMPOSTAZIONI VARIABILI AMBIENTE OPENGL (app-f) APPENDICE F: CONFIGURAZIONE AGP (app-g) APPENDICE G: PROBLEMI SPECIFICI ALI (app-h) APPENDICE H: PROBLEMI SPECIFICI TNT (app-i) APPENDICE I: CONFIGURAZIONE DI TWINVIEW (app-j) APPENDICE J: CONFIGURAZIONE DI TV-OUT (app-k) APPENDICE K: CONFIGURAZIONE DI UN PORTATILE (app-l) APPENDICE L: MODALITÀ DI PROGRAMMAZIONE (app-m) APPENDICE M: FLIPPING E UBB (app-n) APPENDICE N: PROBLEMI NOTI (app-o) APPENDICE O: INTERFACCIA PROC (app-p) APPENDICE P: SUPPORTO XVMC (app-q) APPENDICE Q: SUPPORTO GLX (app-r) APPENDICE R: CONFIGURAZIONE DI PIÙ SCHERMI X SU UNA SOLA SCHEDA (app-s) APPENDICE S: SUPPORTO DELLA GESTIONE DELL'ALIMENTAZIONE Si noti che, per rendere le istruzioni più concise, la maggior parte delle avvertenze e dei problemi più frequentemente riscontrati non sono citati dettagliatamente nelle istruzioni relative all'installazione, ma piuttosto nella sezione DOMANDE FREQUENTI. Si raccomanda, pertanto, di leggere completamente il presente file LEGGIMI, prima di eseguire i passi descritti. __________________________________________________________________________ (sec-01) SCELTA DEI PACCHETTI NVIDIA ADATTI AL SISTEMA __________________________________________________________________________ NVIDIA adotta un modello di architettura driver unificata; ciò significa che un driver set può essere utilizzato con qualsiasi dispositivo hardware NVIDIA supportato. Consultare l'appendice A per un elenco dell'hardware NVIDIA supportato dai driver attuali. La release dei driver 1.0-4349 ha introdotto un nuovo sistema di distribuzione e installazione, che semplifica nettamente la procedura di installazione. Il download si riduce a un unico file: NVIDIA-Linux-ia64-1.0-5336-pkg1.run. Questo contiene tutti gli elementi precedentemente suddivisi nei due pacchetti NVIDIA_kernel e NVIDIA_GLX. La release del driver 1.0-5336 introduce un suffisso del pacchetto ("-pkg#") nel file .run. Questo viene utilizzato per distinguere tra i pacchetti che contengono lo stesso driver, ma con differenti interfacce del kernel precompilate. In caso l'utente consideri poco chiara questa soluzione, si consiglia di effettuare il download del solo file .run con il numero di pkg più alto. __________________________________________________________________________ (sec-02) INSTALLAZIONE DEI PACCHETTI NVIDIA_KERNEL E NVIDIA_GLX __________________________________________________________________________ PRIMA DI INIZIARE L'INSTALLAZIONE DEL DRIVER Prima di iniziare l'installazione del driver, uscire dal server X. Per accedere alla console vga senza avviare X si può anche impostare il livello di funzionamento predefinito (consultare la documentazione inviata insieme alla distribuzione Linux, se non si è sicuri su come procedere; solitamente, è sufficiente modificare il file /etc/inittab). Ciò rende più semplice il ripristino, qualora durante l'installazione dovessero verificarsi problemi. Per poter utilizzare il driver, dopo averlo installato, occorre modificare il file XF86Config. Vedere la sezione seguente intitolata MODIFICA DEL FILE XF86CONFIG. INTRODUZIONE AL NUOVO PROGRAMMA DI INSTALLAZIONE DEI DRIVER DI NVIDIA Dopo aver effettuato il download di NVIDIA-Linux-ia64-1.0-5336-pkg1.run, iniziare l'installazione uscendo da X, quindi passare alla directory contenente il file scaricato ed eseguire: sh NVIDIA-Linux-ia64-1.0-5336-pkg1.run Il file .run è un archivio autoestraente. L'esecuzione del file .run avvia l'estrazione del contenuto dell'archivio ed esegue l'utility `nvidia-installer` in esso contenuta, che guida l'utente nell'intera procedura di installazione dei driver di NVIDIA. Il file .run accetta numerose opzioni della riga di comando. Ecco alcune delle opzioni più comuni: --info Stampa le informazioni incorporate nel file .run ed esce. --check Verifica l'integrità dell'archivio ed esce. --extract-only Estrae il contenuto di ./NVIDIA-Linux-ia64-1.0-5336-pkg1.run, ma non esegue 'nvidia-installer'. --help Stampa le informazioni sull'utilizzo delle opzioni più comuni della riga di comando ed esce. --advanced-options Stampa le informazioni sull'utilizzo delle opzioni più comuni ed avanzate della riga di comando ed esce. La procedura di installazione installa anche l'utility `nvidia-installer`, che può essere successivamente impiegata per disinstallare driver, effettuare il download automatico di driver aggiornati, ecc. INTERFACCE KERNEL Il modulo kernel di NVIDIA dispone di un livello di interfaccia del kernel che deve essere appositamente compilato per la configurazione e la versione del kernel eseguita dall'utente. NVIDIA distribuisce il codice sorgente per questo livello di interfaccia kernel, oltre a una versione precompilata di numerosi dei kernel appartenenti ad alcune delle distribuzioni più diffuse. Una volta eseguito il programma di installazione, questa applicazione determina se dispone dell'interfaccia kernel precompilata per il kernel eseguito. Se tale interfaccia non è disponibile, l'applicazione verifica se è eventualmente disponibile sul sito ftp di NVIDIA (sempre presumendo che l'utente disponga di una connessione Internet), e procede al download. Se l'applicazione individua un'interfaccia kernel precompilata che corrisponde al kernel effettivamente utilizzato, allora quell'interfaccia viene collegata[1] alla porzione binaria del modulo kernel di NVIDIA. Il risultato di questa operazione è un modulo interfaccia kernel appropriato per il kernel. Se non viene reperita alcuna interfaccia kernel precompilata, allora il programma di installazione procede alla compilazione dell'interfaccia kernel. Comunque, innanzitutto viene verificata la presenza nel sistema degli header corretti del kernel. Se il programma di installazione deve compilare l'interfaccia kernel, allora occorre installare il pacchetto dei sorgenti del kernel corrispondente al kernel in uso. [1] NOTA: l'installazione richiede la presenza di un linker installato. Il linker, solitamente '/usr/bin/ld', fa parte del pacchetto binutils. Verificare che questo pacchetto sia stato installato prima di procedere all'installazione dei driver NVIDIA. CARATTERISTICHE DEL PROGRAMMA DI INSTALLAZIONE NVIDIA o Disinstallazione: l'installazione del driver esegue un backup di ogni file in conflitto e registra i nuovi file installati nel sistema. È possibile eseguire: nvidia-installer --uninstall per disinstallare il driver corrente; questa opzione rimuove tutti i file installati nel sistema e procede a ripristinare qualsiasi file di cui sia stato eseguito il backup. L'installazione di nuovi driver disinstalla anche tutti i driver precedenti. o Autoaggiornamento: se si esegue: nvidia-installer --latest l'utility si collega al sito FTP di NVIDIA e invia un report relativo alla versione più recente del driver, contenente l'url per il file driver più aggiornato. Se si esegue: nvidia-installer --update l'utility si collega al sito FTP di NVIDIA, effettua il download del file driver più recente e lo installa. o Interfacce utente multiple: il programma di installazione si avvale di un'interfaccia utente basata su ncurses se è in grado di individuare la corretta libreria ncurses, in caso contrario, esegue una semplice interfaccia utente a riga di comando. Per disabilitare l'uso dell'interfaccia utente ncurses, usare l'opzione'--ui=none'. o Interfacce kernel aggiornate: il programma di installazione effettua il download di interfacce kernel precompilate dal sito FTP NVIDIA (per i kernel rilasciati dopo il driver NVIDIA). FAQ DEL PROGRAMMA DI INSTALLAZIONE NVIDIA D: Come posso estrarre il contenuto del file .run senza ricorrere alla effettiva installazione del driver? R: Eseguire: sh NVIDIA-Linux-ia64-1.0-5336-pkg1.run --extract-only Questa opzione crea la directory NVIDIA-Linux-ia64-1.0-5336-pkg1.run che contiene il contenuto non compresso del file .run. D: Come posso esaminare il codice sorgente del livello dell'interfaccia kernel? R: I file sorgente del livello dell'interfaccia kernel si trovano nella directory usr/src/nv/ del file .run estratto. Per accedere a questi file sorgente, eseguire: sh NVIDIA-Linux-ia64-1.0-5336-pkg1.run --extract-only cd NVIDIA-Linux-ia64-1.0-5336-pkg1.run/usr/src/nv/ D: Ho appena aggiornato il mio kernel e ora non riesco più a caricare il modulo kernel NVIDIA. Qual è il problema? R: Il livello dell'interfaccia kernel del modulo kernel di NVIDIA deve essere compilato specificamente per la configurazione e la versione del kernel eseguita dall'utente. Se si aggiorna il kernel, allora la soluzione più semplice consiste nella reinstallazione del driver. OPZIONI AVANZATE: È possibile installare il modulo del kernel di NVIDIA per un kernel non in esecuzione (per esempio: quando si sia appena creato e installato un nuovo kernel, ma non si sia ancora effettuato il reboot) con una riga di comando come questa: sh NVIDIA-Linux-ia64-1.0-5336-pkg1.run --kernel-name='KERNEL_NAME' nella quale 'KERNEL_NAME' è il contenuto che avrebbe il report `uname -r` se il kernel in questione fosse in esecuzione. D: Perché NVIDIA non offre più rpm? R: Non tutte le distribuzioni di Linux si avvalgono di rpm, e NVIDIA intende offrire un'unica soluzione in grado di funzionare per tutte le distribuzioni di Linux. Come indicato nella licenza software di NVIDIA, la società concede a terzi il diritto di effettuare il repackaging e la redistribuzione dei driver Linux di NVIDIA in qualsiasi formato di pacchetto al fine di includerli nelle distribuzioni di Linux. D: Il programma di installazione di NVIDIA non funziona sul mio computer. Come posso installare il driver contenuto nel file .run? R: Per installare il driver NVIDIA contenuto nel file .run senza utilizzare il programma di installazione NVIDIA, è possibile ricorrere al Makefile incluso: sh ./NVIDIA-Linux-ia64-1.0-5336-pkg1.run --extract-only cd NVIDIA-Linux-ia64-1.0-5336-pkg1.run make install Questo metodo di installazione non è consigliato, e viene fornito solo come ultima risorsa, nel caso in cui il programma di installazione di NVIDIA non funzioni correttamente sul proprio sistema. D: Il programma di installazione di NVIDIA può avvalersi di un server proxy? R: Sì, dal momento che il supporto FTP nel programma di installazione NVIDIA si basa su snarf, questo è in grado di funzionare con le variabili di ambiente FTP_PROXY, SNARF_PROXY e PROXY. D: Qual è il significato del suffisso "pkg#" del file .run? R: Il suffisso "pkg#" è utilizzato per distinguere i vari file .run che contengono lo stesso driver ma set differenti di interfacce del kernel precompilate. Se una distribuzione rilascia un nuovo kernel successivamente al rilascio di un driver NVIDIA, il driver NVIDIA più recente può essere ripresentato in un nuovo pacchetto che includa un'interfaccia del kernel precompilata per quel kernel più nuovo (in aggiunta a tutte le interfacce del kernel precompilate che sono state incluse nel pacchetto precedente del driver). I file .run con lo stesso numero di versione, ma numeri di okg differenti differiscono solo nelle interfacce del kernel precompilate incluse. In più, i file .run con numeri di pkg più alti offrono l'intero contenuto dei file .run con numeri di pkg più bassi. D: Ho già installato NVIDIA-Linux-ia64-1.0-5336-pkg1.run, ma vedo che NVIDIA-Linux-ia64-1.0-5336-pkg2.run è stato appena inserito nella pagina di download dei driver Linux di NVIDIA. Devo scaricare e installare il file NVIDIA-Linux-ia64-1.0-5336-pkg2.run? R: Questa operazione non è affatto necessaria. Il driver contenuto in tutti i file .run della serie 1.0-5336 è assolutamente identico. Non vi è nessuna necessità di procedere a una reinstallazione. D: Posso aggiungere le mie interfacce del kernel precompilate a un file .run? R: Sì, l'opzione del file .run "--add-this-kernel" provvederà ad aprire il file .run, creare un'interfaccia del kernel precompilata per il kernel attualmente in esecuzione e a ripristinare il pacchetto del file .run, aggiungendo "-custom" al nome del file. Questo può dimostrarsi utile, per esempio, se si amministrano più macchine Linux, tutte con lo stesso kernel. D: Dove posso reperire il codice sorgente per l'utility di installazione NVIDIA? R: L'utility di installazione NVIDIA è rilasciata in base alla GPL. Il più recente codice sorgente è disponibile all'indirizzo: ftp://download.nvidia.com/XFree86/nvidia-installer/ RINGRAZIAMENTI DEL PROGRAMMA DI INSTALLAZIONE NVIDIA Il programma di installazione NVIDIA si ispira allo strumento loki_update: (http://www.lokigames.com/development/loki_update.php3.) Il supporto per ftp e http del programma di installazione NVIDIA si basa su snarf 7.0: (http://www.xach.com/snarf/). L'archivio autoestraente (ovvero, il "file .run") viene generato utilizzando makeself.sh: (http://www.megastep.org/makeself/) __________________________________________________________________________ (sec-03) MODIFICA DEL FILE XF86CONFIG __________________________________________________________________________ Quando è uscito Xfree 4.0, utilizzava una sintassi di file XF86Config leggermente diversa da quello della serie 3.x, pertanto per consentire sia alla versione 3.x che 4.x di Xfree di coesistere nello stesso sistema, è stato deciso di utilizzare per XFree86 4.x il file di configurazione "/etc/X11/XF86Config-4", se disponibile e solo nel caso in cui questo non fosse disponibile di utilizzare "/etc/X11/XF86Config" (effettivamente, questa è una semplificazione dei criteri di ricerca; consultare la pagina XF86Config per una descrizione completa del percorso di ricerca). Determinare quale file di configurazione XFree86 viene utilizzato. In caso di dubbi, consultare la riga che inizia con " (==) Using config File:" nel file log XFree86 ("/var/log/XFree86.0.log"). Il presente LEGGIMI utilizza "XF68Config" per riferirsi al file di configurazione, qualunque fosse il nome. Se non è disponibile un file funzionante XF86Config, esistono diverse soluzioni: Xfree86 comprende un file config campione ed il pacchetto NVIDIA_GLX, comprende un file config campione (deve essere installato in /usr/share/doc/NVIDIA_GLX-1.0/). Si può utilizzare anche un programma come 'xf86config'; alcune distribuzioni forniscono uno strumento apposito per la preparazione di un file XF86Config. Per maggiori informazioni sulla sintassi del file XF86Config, consultare la pagina principale. Se è già disponibile un file XF86Config che utilizza un driver diverso (come il driver 'nv' O 'vesa'), basta trovare la sezione pertinente del dispositivo e sostituire la riga: Driver "nv" (o Driver "vesa") con Driver "nvidia" Nella sezione modulo, accertarsi di avere: Load "glx" Se esistenti, dovranno essere eliminate anche le seguenti righe: Load "dri" Load "GLcore" Ci sono numerose opzioni che possono essere aggiunte al file XF86Config per ottimizzare il driver NVIDIA XFree86. Consultare l'appendice D, per avere un elenco completo di queste opzioni. Una volta configurato il file XF86Config, è possibile riavviare X e iniziare a utilizzare le librerie OpenGL accelerate. Dopo aver riavviato X è possibile eseguire qualsiasi applicazione OpenGL e saranno automaticamente utilizzate le nuove librerie NVIDIA. In caso di problemi, consultare la sezione DOMANDE FREQUENTI, qui sotto. __________________________________________________________________________ (sec-04) DOMANDE FREQUENTI __________________________________________________________________________ D: Quale strumento posso usare per iniziare la diagnosi di eventuali problemi di visualizzazione? R: Uno degli strumenti più utili per la diagnosi di problemi è il file log in /var/log, di Xfree86 (il file è denominato: "/var/log/XFree86.<#>.log", in cui "<#>" è il numero server -- generalmente 0). Le righe che iniziano con "(II)" si riferiscono ad informazioni, "(WW)" si riferiscono ad avvisi e "(EE)" ad errori. Accertarsi di utilizzare il file config corretto (per esempio il file config editato); cercare la riga che inizia con: "(==) Using config file:" (file config utilizzato). Verificare anche che venga utilizzato il driver NVIDIA anziché il driver 'nv' o 'vesa'; cercando: "(II) LoadModule: "nvidia"", e righe del driver che iniziano con: "(II) NVIDIA(0)". D: Come è possibile aumentare la quantità di dati indicata nel file log di XFree86? R: Per opzione predefinita, il driver NVIDIA X produce relativamente pochi messaggi per stderr e per il file log XFree86. Se è necessario risolvere un problema, può essere utile abilitare un output più verboso utilizzando le opzioni riga di comando "-verbose" e "-logverbose", che possono essere utilizzate per impostare, rispettivamente, il livello di verbosità dei messaggi stderr e del file log. Il driver NVIDIA X emetterà più messaggi quando il livello di verbosità è uguale o superiore a 5 (l'impostazione predefinita di Xfree86 è livello 1 per stderr e 3 per il file log. Quindi, per abilitare messaggi verbosi dal driver NVIDIA X al file log e stderr, può essere avviato X, effettuando quanto segue: 'startx -- -verbose 5 -logverbose 5'. D: Il server X non si avvia e il file log XFree86 contiene l'errore: "(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!" R: Se il modulo kernel Nvdriver non funziona adeguatamente, non funzionerà nulla. Se nel file X log si riscontrano errori quali "(EE) NVIDIA(0): Failed to initialize the NVdriver kernel module!", probabilmente esiste un problema relativo al modulo kernel NVIDIA. Per prima cosa, se l'installazione è stata effettuata da rpm, verificare che l'rpm sia stato costruito specificatamente per il kernel utilizzato. Verificare anche che il modulo sia caricato ('/sbin/lsmod'); eventualmente tentare di caricarlo specificamente con 'insmode' o 'modprobe' (accertarsi di uscire dal server X prima di installare un nuovo modulo kernel). Se si riscontrano errori in relazione a simboli non risolti, con ogni probabilità il modulo kernel è stato costruito utilizzando un file destinato a una revisione kernel diversa da quella scelta. È specificatamente possibile verificare quali file header del kernel sono stati utilizzati quando si costruisce il modulo kernel NVIDIA con l'opzione --kernel-include-dir (vedere `sh NVIDIA-Linux-ia64-1.0-5336-pkg1.run --opzioni avanzate` per ulteriori dettagli). Si noti che la convenzione per la posizione dei file header del kernel è mutata sin dalla release 2.4.0 del kernel, proprio come la posizione del moduli kernel. Se il modulo kernel non viene caricato correttamente, modprobe/insmod potrebbe tentare di caricare un modulo kernel più vecchio (presumendo che sia stato effettuato l'aggiornamento). Passare alla cartella con il nuovo modulo kernel ed effettuare 'insmod ./nvidia.o' potrebbe essere di aiuto. Un'altra causa potrebbe essere l'assenza dei file dispositivo /dev/nvidia*. Infine, il modulo kernel di NVIDIA potrebbe anche visualizzare messaggi di errore che indicano la presenza di un problema -- per far comparire questi messaggi, scegliere /var/log/messages /var/log/messaggi, o la posizione di syslog per visualizzare messaggi relativi al kernel. Questi messaggi hanno la preposizione "NVRM". D: X si avvia, ma le applicazioni OpenGL terminano immediatamente. R: Se X si avvia, ma le applicazioni OpenGL si bloccano, presumibilmente esiste un problema relativo ad altre librerie o sono presenti symlink non aggiornati. Vedere l'Appendice C per maggiori dettagli. A volte basta ritornare a 'ldconfig'. Occorre anche verificare, che sia disponibile l'estensione corretta; 'xdpyinfo' dovrà comprendere le estensioni "GLX", "NV-GLX" e "NVIDIA-GLX". Se non vi sono queste tre estensioni, probabilmente esiste un problema relativo al modulo glx caricato, oppure il sistema non è in grado di caricare completamente Glcore. Verificare il file XF86Config ed accertarsi di caricare glx (vedi "Modifica del file XF86Config" qui sopra). Se il file XF86Config è quello giusto, controllare il file log Xfree86 per individuare errori riguardanti GLX. Controllare lo stato di tutti i symlink necessari (consultare l'Appendice C). D: L'installazione del modulo kernel di NVIDIA produce un messaggio di errore del tipo: "#Modules should never use kernel-headers system headers" oppure "#error but headers from an appropriate kernel-source". R: Occorre installare il sorgente del kernel Linux. Nella maggior parte delle situazioni questo problema può essere risolto installando il pacchetto sorgente kernel relativo alla propria distribuzione. D: Le applicazioni OpenGL producono il seguente messaggio di errore: "Error: Could not open /dev/nvidiactl because the permissions are too restrictive". Please see the FREQUENTLY ASKED QUESTIONS section of /usr/share/doc/NVIDIA_GLX-1.0/README for steps to correct. R: È probabile che un modulo di protezione del sistema PAM alteri i permessi dei file periferica NVIDIA. Nella maggior parte dei casi questo sistema di protezione funziona, ma è possibile che crei confusione. Per correggere questo problema, si raccomanda di disattivare questa funzione di protezione. Le diverse distribuzioni Linux dispongono di file diversi per controllare questo parametro: consultare il proprio distributore per informazioni sul corretto metodo di disabilitazione di questa funzione di sicurezza. Per esempio, se il sistema dispone del file /etc/security/console.perms occorre editare il file e rimuovere la riga che inizia con "" (ci è stato comunicato che potrebbe essere necessario rimuovere comunque i riferimenti aggiuntivi a nel console.perms, ma questa notizia non è ancora stata verificata da NVIDIA). Se invece il sistema dispone del file /etc/logindevperms occorre modificare il file e rimuovere la riga che elenca /dev/nvidiactl. La procedura citata impedisce la modifica dei file periferica NVIDIA da parte del sistema di protezione PAM. Successivamente, i permessi dei file periferica dovranno essere resettati allo stato originale. Questo è possibile grazie ai seguenti comandi: chmod 0666 /dev/nvidia* chown root /dev/nvidia* D: Se le app OpenGL subiscono un blocco e danno il seguente messaggio: "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: Il caricatore dinamico del sistema ha un problema in grado di bloccare ripetutamente le applicazioni collegate con pthreads e dlopen() libGL. Questo bug è presente nelle versioni più vecchie del caricatore dinamico. Le distribuzioni diffuse con questo caricatore comprendono, senza limitarsi ad esse, RedHat Linux 6.2 e Mandrake Linux 7.1. La versione 2.2 del caricatore dinamico e ogni versione successiva funzionano invece correttamente. Se l'applicazione che si blocca, è single thread, l'impostazione della variabile ambientale __GL_SINGLE_THREADED su qualsiasi valore permette di evitare il blocco. Immettere in bash shell: export __GL_SINGLE_THREADED=1 mentre in cash e derivati occorre utilizzare: setenv __GL_SINGLE_THREADED 1 Per le versioni precedenti di NVIDIA Accelerated Linux Driver Set si era sviluppata una soluzione alternativa del problema, ma questa causava problemi con altre applicazioni ed è stata quindi rimossa dopo la versione 1.0-1541. D: Quando carico Quake3, il programma si blocca durante il cambio di modalità video. Qual è il problema? R: Probabilmente si tratta del problema descritto qui sopra. Controllare il testo del messaggio di errore descritto nella risposta precedente. Impostare __GL_SINGLE_THREADED come descritto qui sopra, prima di far funzionare Quake 3, dovrebbe risolvere il problema. D: Il sistema funziona, ma sembra instabile. Qual è il problema? R: Il problema di stabilità può derivare dal modulo AGP sbagliato. Vedere l'Appendice F per maggiori dettagli. D: Il modulo kernel non viene caricato dinamicamente all'avvio di X; occorre sempre eseguire prima 'modprobe NVdriver'. Qual è il problema? R: Controllare che la riga "alias char-major-195 NVdriver" compaia nel file di configurazione del modulo, generalmente "/etc/conf.modules", "/etc/modules.conf" o "/etc/modutils/alias"; consultare la documentazione fornita insieme alla distribuzione, per avere dettagli. D: Non è possibile creare il modulo kernel Nvdriver, o è possibile crearlo, ma modprobe/ismod non carica il modulo nel nucleo. Qual è il problema? R: Generalmente, questo problema deriva dal fatto che la build si avvale dei file header del kernel sbagliati (per esempio per una versione del kernel diversa da quella in esecuzione). In precedenza, i file header kernel venivano archiviati nella directory "/usr/include/linux/", ma questa convenzione è stata abbandonata in favore di "/lib/modules/`uname -r`/build/include". Il programma di installazione NVIDIA è in grado di determinare la posizione nel sistema utilizzato; comunque se si riscontrano problemi, è possibile forzare la build a utilizzare specifici file header, utilizzando l'opzione --kernel-include-dir. Ovviamente, per far funzionare questa procedura, è necessario disporre del file header kernel appropriato per il sistema. Consultare la documentazione inviata insieme alla distribuzione; alcune distribuzioni non installano i file header kernel per opzione predefinita, o installano header che non coincidono perfettamente con il kernel utilizzato. D: Perché le applicazioni OpenGL sono così lente? R: Probabilmente l'applicazione sta utilizzando una libreria di sistema diversa da quella fornita da NVIDIA con OpenGL. Consultare l'APPENDICE C, per i dettagli. D: Il funzionamento di Quake2 crea problemi. R: Quake2 richiede qualche operazione di configurazione per funzionare correttamente. Nella cartella Quake2 l'installazione crea un symlink, chiamato libGL.so, che indica libMesaGL.so. Questo symlink va rimosso o rinominato. Poi, per far funzionare Quake2 in modalità OpenGL, immettere: 'quake2 +set vid_ref glx +set gl_driver libGL.so'. Sembra che Quake2 non supporti nessun tipo di modalità a schermo intero, ma l'X server può funzionare con qualsiasi risoluzione abilitata per Quake2, emulando la modalità a schermo intero. D: Il funzionamento di Heretic II crea problemi. R: Anche Heretic II, per opzione predefinita, installa un symlink chiamato libGL.so nella cartella applicazioni. Questo symlink può essere rimosso o rinominato, in quanto il sistema individua il file libGL.so predefinito (che i driver NVIDIA installano nella directory /usr/lib). Dall'interno del menù video di Heretic II è quindi possibile impostare la modalità di rendering in OpenGL. Inoltre lokigames ha reso disponibile una patch per Heretic II all'indirizzo: http://www.lokigames.com/products/heretic2/updates.php3 D: Dove posso ottenere gl.h or glx.h per compilare programmi OpenGL? R: Nella maggior parte dei sistemi questi header sono preinstallati. Comunque NVIDIA fornisce i propri file gl.h e glx.h che sono installati in /usr/share/doc/NVIDIA_GLX-1.0/usr/include/GL. Per utilizzare questi header, copiarli in /usr/include/GL, o istruire il programma di installazione affinché li installi in usr/include/GL inviando l'istruzione '--opengl-headers' al file NVIDIA-Linux-ia64-1.0-5336-pkg1.run durante l'installazione. D: È possibile ricevere via e-mail comunicati su NVIDIA Accelerated Linux Driver Set? R: Sì. Compilare il modulo disponibile al sito. http://www.nvidia.com/view.asp?FO=driver_update D: Il sistema rallenta selezionando vt e con rivafb abilitato. R: Utilizzando sia rivafb che il modulo kernel Nvdriver contemporaneamente, generalmente si riscontrano evidenti rallentamenti. In genere non è consigliabile usare due diversi driver software per uno stesso hardware. D: Compilando il modulo kernel Nvdriver compare il seguente errore: 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: Si sta tentando di compilare il modulo kernel Nvdriver con la stessa versione del compilatore utilizzato per compilare il kernel. Alcune strutture dati kernel di Linux, dipendono dalla versione di gcc utilizzata per la compilazione; per esempio, in include/linux/spinlock.h: ... * La maggior parte delle versioni contengono un bug pericoloso con inizializzatori vuoti. */ #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 Se il kernel è compilato con gcc 2.x, ma si usa gcc 3.x durante la compilazione dell'interfaccia (o viceversa), le dimensioni di rwlock_t variano ed è possibile che si verifichino errori durante l'esecuzione di funzioni quali ioremap. Per verificare quale versione di gcc è stata utilizzata per compilare il kernel è possibile esaminare l'uscita di: cat /proc/version Per verificare quale versione di gcc è attualmente utilizzata per $PATH, è possibile esaminare l'uscita di: gcc -v D: L'esecuzione di X non riesce e compare l'errore "Failed to allocate LUT context DMA" R: Questa è una delle possibili conseguenze della compilazione di Nvdriver con una versione diversa da quella utilizzata per compilare il kernel Linux (vedere sopra). D: Qual è la politica di NVIDIA nei confronti dei kernel Linux serie development? R: NVIDIA non supporta ufficialmente i kernel serie development. Tuttavia, tutto il codice sorgente del modulo kernel che si interfaccia con il kernel Linux è disponibile nella directory usr/src/nv/ del file .run. NVIDIA incoraggia i membri della comunità Linux a sviluppare patch per questi file sorgente per supportare kernel development series. Una ricerca di google con ogni probabilità finirà per individuare diverse patch supportate dalla comunità. D: Recentemente ho aggiornato varie librerie del mio sistema usando l'utility di aggiornamento del distributore di Linux e il driver grafico NVIDIA non funziona più. Qual è il problema? R: È possibile che siano state installate librerie in conflitto dall'utility di aggiornamento della distribuzione; consultare l'APPENDICE C: COMPONENTI INSTALLATI per ulteriori dettagli sulle modalità di diagnosi di questo problema. D: `rpm --rebuild` presenta un messaggio di errore "unknown option". R: Le versioni recenti di rpm non supportano più l'opzione "-rebuild"; se si dispone di una simile versione di rpm, si dovrebbe invece usare il comando "rpmbuild -rebuild". L'eseguibile "rpmbuild" è incluso nel pacchetto rpm-build. D: Sto utilizzando l'opzione grafica interna nForce o nForce2, e nel file XFree86.0.log sono comparsi avvertimenti come quello seguente: Not using mode "1600x1200" (exceeds valid memory bandwidth usage) R: La grafica integrata ha restrizioni dell'ampiezza di banda di memoria più stringenti che limitano la risoluzione e la velocità di aggiornamento delle modalità richieste. Per aggirare questo problema, è possibile ridurre la velocità massima di refresh riducendo il valore massimo dell'intervallo "VertRefresh" nella sezione Monitor del file XF86Config. Sebbene sia sconsigliato, è possibile disabilitare il test dell'ampiezza di banda della memoria con l'opzione del file XF86Config "NoBandWidthTest". D: Ho ricostruito il modulo del kernel NVIDIA, ma quando tento di inserirlo, ottengo un messaggio che mi dice che ci sono simboli non risolti. R: I simboli non risolti sono nella maggior parte dei casi provocati da un mismatch tra le sorgenti del kernel e il kernel in esecuzione. Questi devono essere identici perché il modulo del kernel NVIDIA sia creato correttamente. Accertarsi che le sorgenti del kernel siano installate e configurate in modo identico al kernel in esecuzione. D: Come posso verificare lo stato di installazione delle sorgenti del kernel? R: Se si sta eseguendo una distribuzione che si avvale di RPM (Red Hat, Mandrake, SuSE, ecc), allora è possibile usare gli RPM per verificare. A un prompt della shell, digitare: `rpm -qa | grep kernel` e verificare l'output. Dovrebbe essere presente un pacchetto che corrisponde al kernel (spesso denominato con definizioni quali kernel-2.4.18-3) e un pacchetto della sorgente del kernel con lo stesso codice di versione (spesso denominato con definizioni quali kernel-source-2.4.18-3). Se nessuna delle righe sembra corrispondere a un pacchetto sorgente, allora è probabile che sia necessario installarlo. Se le versioni elencate non corrispondono (per esempio, kernel-2.4.18-10 a fronte di kernel-source-2.4.18-3), allora occorre aggiornare il pacchetto sorgente del kernel in modo che corrisponda al kernel effettivamente installato. Se sono installati più kernel, occorre installare il pacchetto sorgente del kernel che corrisponde al kernel 'in esecuzione' (o accertarsi che il pacchetto sorgente installato corrisponda esattamente al kernel in esecuzione). Questo è possibile verificando l'output di "uname -r" e le versioni corrispondenti. D: Per quale motivo non sono in grado di caricare il modulo del kernel NVIDIA compilato per il kernel Red Hat Linux 7.3 2.4.18-3bigmem? R: I file header del kernel distribuiti da Red Hat per il kernel Red Hat Linux 7.3 2.4.18-3bigmem sono configurati in modo errato. Per questo kernel, si può caricare il modulo del kernel precompilato da NVIDIA, ma se si desidera compilare i file dell'interfaccia del kernel NVIDIA per questo kernel, allora è necessario eseguire questa procedura: cd /lib/modules/`uname -r`/build/ cp configs/kernel-2.4.18-i686-bigmem.config .config make mrproper oldconfig dep Nota: Red Hat Linux è distribuito con file header del kernel che sono configurati simultaneamente per TUTTI i kernel di una versione particolare della distribuzione. Un file header generato al momento dell'avvio imposta alcuni parametri che selezionano la configurazione corretta. La ricostruzione degli header del kernel con i comandi precedenti creerà file header idonei per la sola configurazione del kernel Red Hat Linux 7.3 2.4.18-3bigmem, eliminando i file header delle altre configurazioni. D: X impiega molto tempo per avviarsi (a volte, anche diveris minuti). Che cosa posso fare? R: Si è riscontrato che la maggior parte dei problemi di ritardo di startx sono provocati da dati errati nelle BIOS video relativi alle periferiche di visualizzazione possibilmente collegate o sulla porta i2c da utilizzare per il rilevamento. È possibile aggirare questi problemi con l'opzione XF86Config "IgnoreDisplayDevices" (consultarne la descrizione nella (app-d) APPENDICE D: OPZIONI DI XF86CONFIG). D: Per quale motivo X usa tanta memoria? R: Quando si misura l'impiego di memoria di qualsiasi applicazione, si dovrebbe prestare attenzione a distinguere l'utilizzo della RAM fisica di sistema e le mappature virtuali delle risorse condivise. Per esempio, la maggior parte delle librerie condivise sono presenti con una sola istanza nella memoria fisica, ma sono mappate in più processi. Questa memoria dovrebbe essere conteggiata una sola volta quando si calcola il consumo di memoria complessivo. Allo stesso modo, la memoria video su una scheda grafica o la memoria del registro di qualsiasi periferica può essere mappata su più processi. Queste mappature non consumano la normale RAM di sistema. Questo argomento è stato discusso frequentemente nelle mailing list dedicate a XFree86; consultare, per esempio: http://marc.theaimsgroup.com/?l=xfree-xpert&m=96835767116567&w=2 L'utility `pmap` descritta nel thread precedente è disponibile al seguente indirizzo: http://web.hexapodia.org/~adi/pmap.c si tratta di un utile tool che consente di distinguere tra i vari tipi di mappature di memoria. Per esempio, mentre `top` può indicare che X sta utilizzando diverse centinaia di MB di memoria, l'ultima riga dell'output di pmap: mapped: 287020 KB writable/private: 9932 KB shared: 264656 KB rivela che X in effetti sta utilizzando solo circa 10 MB di RAM di sistema (il valore "writable/private"). Si noti, inoltre, che X deve assegnare le risorse al posto dei client di X (il gestore delle finestre, il browser Web, ecc); l'utilizzo di memoria di X aumenta con l'incremento delle richieste di risorse da parte dei client quali pixmap, e si riduce chiudendo applicazioni X. D: Le applicazioni OpenGL assorbono quantità significative di memoria dal sistema! R: Se il kernel utilizza il VM -rmap, il sistema può perdere importanti quantità di memoria a causa di un'ottimizzazione di gestione della memoria introdotta nell'opzione -rmap14a. La VM -rmap è stata adottata da diverse distribuzioni molto diffuse, la perdita di memoria è notoriamente presente in alcuni dei kernel di distribuzione; il problema è stato risolto in -rmap15e. Se si sospetta che il proprio sistema possa essere affetto da questo problema, si tenti di aggiornare il kernel oppure si contatti il fornitore della distribuzione per l'assistenza necessaria. D: Alcune applicazioni OpenGL (quali per esempio Quake3 Arena) si bloccano quando le avvio con Red Hat Linux 9. R: Alcune versioni del pacchetto glibc distribuito da Red Hat che supportano TLS non gestiscono correttamente l'uso di dlopen() per accedere alle librerie condivise che utilizzano alcuni dei modelli TLS. Questo problema si riscontra, per esempio, quando Quake3 Area esegue il dlopen() della libreria libGL di NVIDIA. Si consiglia di scaricare almeno la versione 2.3.2-11.9 di glibc non appena verrà resa disponibile come aggiornamento da Red Hat. D: Ho installato il driver, ma la casella di controllo Enable 3D Acceleration è ancora disattivata! Cosa ho sbagliato? R: La maggior parte degli applet di configurazione forniti con le distribuzioni non hanno informazioni relative al driver accelerato di NVIDIA e di conseguenza non si aggiornano automaticamente all'installazione del driver. Il driver, se è stato installato correttamente, dovrebbe comunque funzionare senza problemi. D: Dove posso reperire i tarball? R: I normali tarball non sono più disponibili. Il file .run è un tarball con uno script di shell integrato. È possibile eseguire il file .run con l'opzione '--extract-only' per espandere il tarball. D: Dove posso reperire le versioni precedenti del driver? R: Visitare ftp://download.nvidia.com/XFree86_40/. D: X non ripristina la console vga quando viene eseguito su un apparecchio televisivo. Nel mio file log di XFree86 compare il seguente messaggio di errore: Unable to initialize the XFree86 int10 module; the console may not be restored correctly on your TV. R: Il driver NVIDIA XFree86 si avvale del modulo XFree86 Int10 per salvare e ripristinare lo stato della console all'uscita TV, e non sarà in grado di ripristinare la console correttamente se non si può utilizzare il modulo Int10. Se si è creato XFree86 personalmente, accertarsi di aver creato il modulo Int10. Se si sta utilizzando una build di XFree86 fornita da una distribuzione di Linux, e il modulo Int10 è assente, contattare il distributore. D: Quando si modificano le impostazioni di giochi quali Quake 3 Arena o Wolfstein Enemy Territory, l'esecuzione si interrompe e viene visualizzato il messaggio di errore: 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: Questi giochi chiudono e riaprono il driver OpenGL NVIDIA (via dlopen()/dlclose()) quando si effettuano modifiche dei loro parametri. Alcune versioni di glibc (quale ad esempio quella distribuita con Red Hat Linux 9) hanno un errore che fa trapelare elementi TLS statici. Questo errore di glibc provoca il fallimento di ogni nuovo caricamento successivo del driver OpenGL. L'errore è stato risolto nelle versioni più recenti di glibc; vedere errore Red Hat n. 89692: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89692 D: X si blocca durante l'operazione `startx` e il file XFree86.0.log contiene questo messaggio di errore: (EE) NVIDIA(0): Failed to obtain a shared memory identifier. R: Il driver NVIDIA OpenGL e il driver NVIDIA X richiedono memoria condivisa per comunicare; è necessario disporre di CONFIG_SYSVIPC abilitato nel kernel. D: Quando tento di procedere all'installazione del driver, il programma di installazione indica che X è in esecuzione, anche se sono già uscito da X. Cosa sta succedendo? R: Il programma di installazione rileva la presenza di un server X verificando la presenza di file di blocco di X: /tmp/.X[n]-lock, dove [n] è il numero dello X Display (il programma di installazione verifica la presenza di X Display 0-7). Se l'utente ha già chiuso X, ma uno di questi file è ancora presente, allora occorre eliminarlo manualmente. NON rimuovere il file mentre X è ancora in esecuzione. D: Dopo l'installazione del driver NVIDIA i font hanno dimensioni errate. R: I font di dimensioni errate sono generalmente causati da un monitor che riporta una dimensione fisica errata, condizione che, a sua volta, provoca il rendering dei font a dimensioni erronee da parte di varie applicazioni di X. È possibile verificare il valore utilizzato da X per le dimensioni fisiche del monitor utente, eseguendo: xdpyinfo | grep dimensions. Questa funzione riporta le dimensioni in pixel e in millimetri. Se le dimensioni in millimetri risultano grossolanemente errate, allora è possibile correggerle aggiungendo il campo DisplaySize alla sezione monitor del file XF86Config (vedere la XF86Config manpage per ulteriori dettagli). È possibile verificare il valore di dimensioni fisiche indicato dal monitor utente, eseguendo X con logging verboso: `startx -- -logverbose`. Quindi, sottoporre a ricerca il file XFree86.0.log sino a individuare una riga che somigli a: (II) NVIDIA(0): Max H-Image Size [cm]: horiz.: 36 vert.: 27 (i numeri saranno differenti) Il driver NVIDIA utilizza questi valori per calcolare il DPI. D: Voglio utilizzare Valgrind con le applicazioni OpenGL, ma la mia distribuzione si avvale di ELF TLS e Valgrind non riesce ancora a gestire la versione di OpenGL NVIDIA per ELF TLS. R: Potete impostare la variabile di ambiente LD_ASSUME_KERNEL a un valore precedente a "2.3.99" (per esempio: `export LD_ASSUME_KERNEL 2.3.98`). Le librerie OpenGL di NVIDIA contengono una nota OS ABI ELF che indica la versione minima del kernel richiesta per utilizzare la libreria. Le librerie OpenGL di ELF TLS hanno un OS ABI pari a 2.3.99 (il primo kernel di Linux a contenere il necessario supporto a LDT per ELF TLS), mentre le librerie OpenGL non ELF TLS contengono un OS ABI pari a 2.2.5. Il caricatore run-time non permette il caricamento di librerie con un OS ABI superiore rispetto alla versione corrente del kernel. La variabile di ambiente LD_ASSUME_KERNEL può quindi essere utilizzata per forzare la versione del kernel utilizzata dal caricatore run-time in questo test. Impostando LD_ASSUME_KERNEL su qualsiasi versione del kernel precedente a 2.3.99, è possibile costringere il caricatore a non utilizzare le librerie OpenGL di ELF TLS e tornare all'applicazione delle librerie OpenGL regolari. Se, per qualche ragione, occorre rimuovere questa nota OS ABI dalle librerie OpenGL di NVIDIA, è possibile procedere abilitando l'opzione "--no-abi-note" del file .run durante l'installazione. __________________________________________________________________________ (sec-05) COME CONTATTARE NVIDIA __________________________________________________________________________ Esiste un nuovo Web forum per i problemi relativi a NVIDIA Linux driver. È possibile accedere visitando l'indirizzo www.nvnews.net e seguendo i link "Forum" e "Linux Discussion Area". Questo è lo strumento preferenziale per richiedere aiuto; al suo interno, gli utenti possono fare domande, rispondere alle domande di altri visitatori e consultare gli archivi di edizioni precedenti. Se tutto ciò non dovesse risolvere il problema, è possibile contattare NVIDIA per richiedere supporto, all'indirizzo: linux-bugs@nvidia.com. Chiediamo cortesemente, di voler inviare e-mail a questo indirizzo, solo dopo aver seguito quanto indicato nella sezione DOMANDE FREQUENTI di questo file LEGGIMI e dopo aver chiesto aiuto al nv.new Web forum. __________________________________________________________________________ (sec-06) ULTERIORI RISORSE __________________________________________________________________________ Linux OpenGL ABI http://oss.sgi.com/projects/ogl-sample/ABI/ NVIDIA Linux HowTo http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html OpenGL www.opengl.org The XFree86 Project www.xfree86.org #nvidia (irc.openprojects.net) __________________________________________________________________________ (app-a) APPENDICE A: CHIP GRAFICI NVIDIA SUPPORTATI __________________________________________________________________________ NOME CHIP NVIDIA ID PERIFERICA PCI RIVA TNT 0x0020 RIVA TNT2/TNT2 Pro 0x0028 Vanta/Vanta LT 0x002C RIVA TNT2 Ultra 0x0029 RIVA TNT2 Model 64/Model 64 Pro 0x002D Aladdin TNT2 0x00A0 GeForce 256 0x0100 GeForce DDR 0x0101 Quadro 0x0103 GeForce2 MX/MX 400 0x0110 GeForce2 MX 100/200 0x0111 Quadro2 MXR/EX/Go 0x0113 GeForce2 Integrated GPU 0x01A0 GeForce2 GTS/GeForce2 Pro 0x0150 GeForce2 Ti 0x0151 GeForce2 Ultra 0x0152 Quadro2 Pro 0x0153 GeForce4 MX 460 0x0170 GeForce4 MX 440 0x0171 GeForce4 MX 420 0x0172 GeForce4 MX 440-SE 0x0173 Quadro4 550 XGL 0x0178 Quadro NVS 0x017A GeForce4 MX 440 with AGP8X 0x0181 GeForce4 MX 440SE with AGP8X 0x0182 GeForce4 MX 420 with AGP8X 0x0183 GeForce4 MX 4000 0x0185 Quadro4 580 XGL 0x0188 Quadro NVS with AGP8X 0x018A Quadro4 380 XGL 0x018B GeForce4 MX Integrated GPU 0x01F0 GeForce3 0x0200 GeForce3 Ti 200 0x0201 GeForce3 Ti 500 0x0202 Quadro DCC 0x0203 GeForce4 Ti 4600 0x0250 GeForce4 Ti 4400 0x0251 GeForce4 Ti 4200 0x0253 Quadro4 900 XGL 0x0258 Quadro4 750 XGL 0x0259 Quadro4 700 XGL 0x025B GeForce4 Ti 4800 0x0280 GeForce4 Ti 4200 with AGP8X 0x0281 GeForce4 Ti 4800 SE 0x0282 Quadro4 980 XGL 0x0288 Quadro4 780 XGL 0x0289 GeForce FX 5800 Ultra 0x0301 GeForce FX 5800 0x0302 Quadro FX 2000 0x0308 Quadro FX 1000 0x0309 GeForce FX 5600 Ultra 0x0311 GeForce FX 5600 0x0312 GeForce FX 5600XT 0x0314 GeForce FX 5200 0x0320 GeForce FX 5200 Ultra 0x0321 GeForce FX 5200 0x0322 GeForce FX 5200SE 0x0323 Quadro NVS 280 PCI 0x032A Quadro FX 500 0x032B GeForce FX 5900 Ultra 0x0330 GeForce FX 5900 0x0331 GeForce FX 5900XT 0x0332 GeForce FX 5950 Ultra 0x0333 Quadro FX 3000 0x0338 GeForce FX 5700 Ultra 0x0341 GeForce FX 5700 0x0342 Quadro FX 1100 0x034E GeForce2 Go 0x0112 GeForce4 440 Go 0x0174 GeForce FX Go5600 0x031A GeForce FX Go5650 0x031B Quadro FX Go700 0x031C GeForce FX Go5200 0x0324 GeForce FX Go5250 0x0325 GeForce FX Go5200 32M/64M 0x0328 GeForce FX Go5300 0x032C GeForce FX Go5100 0x032D GeForce FX Go5700 0x0348 __________________________________________________________________________ (app-b) APPENDICE B: REQUISITI SOFTWARE MINIMI __________________________________________________________________________ o linux kernel 2.2.12 # cat /proc/version o XFree86 4.0.1 # XFree86 -version o Kernel modutils 2.1.121 # insmod -V Per costruire il modulo kernel NVIDIA: o binutils 2.9.5 # size --version o GNU make 3.77 # make --version o gcc 2.91.66 # gcc --version Se si costruisce da sorgente rpm: o spec-helper rpm # rpm -qi spec-helper Tutte le versioni ufficiali stabili di 2.2.2 e superiori sono supportate; "versioni precedenti" come "2.4.3-pre2" non sono supportate, così come i kernel della serie developer, quali 2.3.x o 2.5.x. Il kernel Linux può essere recuperato da www.kernel.org o da uno dei suoi mirror. Binutils e gcc possono essere recuperati www.gnu.org o da uno dei suoi mirror. Se si sta utilizzando XFree86, ma non si dispone di un file /var/log/XFree86.0.log, probabilmente si sta utilizzando una versione 3.x di Xfree86, che deve essere aggiornata. Se si imposta Xfree86 per la prima volta, spesso è più semplice iniziare con uno degli open source driver, inviati con Xfree86, ('nv', 'vga' o 'vesa'). Quando Xfree86 funziona correttamente con l'open source driver è più semplice passare al driver Nvidia. Si noti, che le GPU NVIDIA potrebbero non funzionare con versioni più vecchie dei driver "nv", inviati con Xfree86. Per esempio, il driver "nv" inviato con Xfree86 versione 4.0.1 non riconosce la famiglia GeForce2 e le GPU Quadro2 MXR. Ciò è stato risolto in Xfree86 versione 4.0.2 (XFree86 può essere trovato attraverso www.xfree86.org). Questi pacchetti software, sono disponibili anche attraverso il vostro distributore linux. __________________________________________________________________________ (app-c) APPENDICE C: COMPONENTI INSTALLATI __________________________________________________________________________ NVIDIA Accelerated Linux Driver Set è costituito dai seguenti componenti (il file fra parentesi è il nome completo del componente dopo l'installazione; "x.y.z" indica la versione attuale - in questi casi, durante l'installazione vengono creati i symlink appropriati): o Un driver XFree86(/usr/X11R6/lib/modules/drivers/nvidia_drv.o); questo driver è necessario ad Xfree86 per utilizzare l'hardware NVIDIA. Il driver nvidia_drv.o è binariamente compatibile con XFree86 4.0.1 e superiore. o Un modulo di estensione GLX per XFree86 (/usr/X11R6/lib/modules(moduli)/extensions(estensioni)/libglx.so.x.y.z; questo modulo è utilizzato da Xfree86 per offrire supporto server-side glx. o Una libreria OpenGL(/usr/lib/libGL.so.x.y.z); questa libreria offre i punti di inserimento API per tutti i richiami delle funzioni OpenGL e GLX. È collegata al runtime con applicazioni OpenGL. o Una libreria OpenGL centrale(/usr/lib/libGLcore.so.x.y.z); questa libreria è implicitamente utilizzata da libGL e libglx. Contiene la funzionalità 3D accelerata, centrale. Non occorre espressamente caricarla nel file XF86Config - ciò viene effettuato da libglx. o Due librerie XvMC (X-Video Motion Compensation): una libreria statica e una libreria condivisa (/usr/X11R6/lib/libXvMCNVIDIA.a, /usr/X11R6/lib/libXvMCNVIDIA.so.x.y.z); consultare (app-p) APPENDICE P: SUPPORTO XVMC, per ulteriori dettagli. o Un modulo kernel(/lib/modules/`uname -r`/video/NVdriver o /lib/modules/`uname -r`/kernel/drivers/video/NVdriver). Questo modulo kernel fornisce accesso di livello basso al hardware NVIDIA a tutti i componenti citati. Generalmente viene caricato nel kernel, quando l'x server si avvia e viene utilizzato dal driver Xfree86 e da OpenGL. Il driver nvidia.o è costituito da due parti: quella centrale, solo binaria e un'interfaccia kernel, che deve essere compilata specificatamente per le versione del kernel utilizzata. Si noti che il kernel linux non ha un interfaccia binaria coerente, come Xfree86, pertanto è importante che questa interfaccia kernel sia adatta alla versione del kernel che viene utilizzata. Ciò può essere effettuato, eseguendo la compilazione stessa od utilizzando binari precompilati, forniti per i nuclei, inviati con alcune delle più comuni distribuzioni Linux. o File header OpenGL e GLX (/usr/share/doc/NVIDIA_GLX-1.0/include/GL/gl.h e /usr/share/doc/NVIDIA_GLX-1.0/include/GL/glx.h). Questi file possono anche essere installati in /usr/include/GL/ passando l'opzione "--opengl-headers" nel file .run durante l'installazione. o ELF TLS OpenGL e librerie core OpenGL (/usr/lib/tls/libGL.so.x.y.z e /usr/lib/tls/libGLcore.so.x.y.z). I sistemi Linux che si avvalgono di glibc 2.3 o maggiore con il supporto tls abilitato, utilizzano un nuovo meccanismo per il TLS (thread local storage). Questo meccanismo è incompatibile con il precedente supporto TLS di NVIDIA; pertanto, sono fornite speciali librerie ELF TLS, che vengono installate su /usr/lib/tls/ nei sistemi che le supportano. Il caricatore runtime seleziona le librerie più adatte tra le OpenGL installate in /usr/lib/ e quelle installate in /usr/lib/tls/. Si dovrebbe inoltre tenere presente che questo nuovo meccanismo TLS influenza anche il modulo di estensione GLX (libglx.so.x.y.z). Tuttavia, dal momento che il caricatore XFree86 non è in grado di discriminare tra le librerie tls e non tls, la corretta libreria libglx viene automaticamente installata in /usr/X11R6/lib/modules/extensions/. È possibile determinare se il glibc si avvale del nuovo meccanismo TLS eseguendo il comando: /lib/libc.so.6 | grep "Thread-local storage support included." Il comando precedente stampa "Thread-local storage support included." sui sistemi che supportano il nuovo meccanismo di TLS. o Il programma di installazione NVIDIA (/usr/bin/nvidia-installer) è lo strumento di NVIDIA per l'installazione e l'aggiornamento dei driver NVIDIA. Consultare la sezione (sec-03) MODIFICA DEL FILE XF86CONFIG per una descrizione più completa. Se le applicazioni dovessero utilizzare la versione sbagliata di una libreria, potrebbero manifestarsi problemi. Questo può avvenire qualora si utilizzassero librerie libGL obsolete o symlink superati. Se si ritiene che l'installazione contenga elementi errati, occorre verificare di disporre della versione appropriata o aggiornata dei seguenti file (questi sono tutti i file di NVIDIA Accelerated Linux Driver Set, più i loro symlink): /usr/X11R6/lib/modules/drivers/nvidia_drv.o /usr/X11R6/lib/modules/extensions/libglx.so.x.y.z /usr/X11R6/lib/modules/extensions/libglx.so -> libglx.so.x.y.z /usr/lib/libGL.so.x.y.z /usr/lib/libGL.so.x -> libGL.so.x.y.z /usr/lib/libGL.so -> libGL.so.x /usr/lib/libGLcore.so.x.y.z /usr/lib/libGLcore.so.x -> libGLcore.so.x.y.z /lib/modules/`uname -r`/video/nvidia.o, or /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o L'installazione crea anche i file /dev: crw-rw-rw- 1 root root 195, 0 Feb 15 17:21 nvidia0 crw-rw-rw- 1 root root 195, 1 Feb 15 17:21 nvidia1 crw-rw-rw- 1 root root 195, 2 Feb 15 17:21 nvidia2 crw-rw-rw- 1 root root 195, 3 Feb 15 17:21 nvidia3 crw-rw-rw- 1 root root 195, 255 Feb 15 17:21 nvidiactl Se vi sono altre librerie il cui "nome so" è in conflitto con quello delle librerie NVIDIA, ldconfig potrebbe creare i symlink sbagliati. Si raccomanda di rimuovere manualmente o di rinominare le librerie in conflitto (accertarsi di non rinominare librerie in conflitto utilizzando denominazioni che possano risultare omonime per ldconfig -- si è stabilito che generalmente è sufficiente anteporre "XXX" al nome di una libreria), rieseguire 'ldconfig' e controllare che vengano effettuati i symlink corretti. Alcune librerie che spesso creano conflitti sono "/usr/X11R6/lib/libGL.so*" e "/usr/X11R6/lib/libGLcore.so*". Dopo aver controllato le librerie, verificare che l'applicazione stia utilizzando le librerie corrette. Per esempio, per controllare se l'applicazione /usr/X11R6/bin/gears sta utilizzando le librerie NVIDIA, effettuare: $ 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) Annotare i file utilizzati per libGL e libGLcore -- se sono diversi dalle librerie NVIDIA, occorre rimuovere queste librerie o sistemare il percorso di ricerca ld. Se questa procedura non vi è famigliare, consultare le pagine principali relative a "ldconfig" e "ldd". __________________________________________________________________________ (app-d) APPENDICE D: OPZIONI XF86CONFIG __________________________________________________________________________ Le seguenti opzioni driver sono supportate dal driver NVIDIA Xfree86: Opzione "NvAGP" "integer" Configurazione supporto AGP. L'argomento completo può essere uno dei seguenti: 0 : disabilita agp 1 : se possibile, utilizzare il supporto AGP interno 2 : se possibile, utilizzare AGPGART 3 : utilizzare un supporto agp (tentare con AGPGART, poi con AGP NVIDIA) Si noti che il supporto AGP interno non può funzionare se AGPGART è compilato staticamente nel kernel, oppure se è costruito come modulo, ma caricato nel kernel (alcune distribuzioni caricano AGPGART nel kernel all'avvio). Preimpostazione: 3 (il valore predefinito era 1 fino alla 1.0-1251). Opzione "NoLogo" "boolean" Disabilitare il disegno della schermata a macchia del logo NVIDIA all'avvio di X. Preimpostazione: il logo viene disegnato. Opzione "RenderAccel" "boolean" Abilitare o disabilitare l'accelerazione hardware dell'estensione RENDER (Resa). QUESTA OPZIONE È SPERIMENTALE. L'ABILITAZIONE È QUINDI EFFETTUATA A PROPRIO RISCHIO E PERICOLO. Non esiste alcuna serie di prove di correttezza per l'estensione RENDER quindi NVIDIA non può verificare che l'accelerazione operi correttamente. Preimpostazione: l'accelerazione hardware dell'estensione RENDER è disabilitata. Opzione "NoRenderExtension" "boolean" Disabilita l'estensione RENDER. A prescindere dalla ricompilazione del server X, XFree86 non sembra disporre di metodi alternativi per la disabilitazione di questa opzione. Fortunatamente, è possibile controllare questa opzione dal driver per esportarla. Questo è utile alla profondità 8, nella quale RENDER normalmente si approprierebbe della maggior parte della mappa di colore predefinita. Preimpostazione: Accelerazione di RENDER, se possibile. Opzione "UBB" "boolean" Abilita o disabilita Unified Back Buffer sui chipset di Quadro (Quadro4 NVS esclusi); consultare l'appendice M per avere una descrizione di UBB. Questa opzione non interessa i chipset diversi di quelli di Quadro. Preimpostazione: BB abilitato per i chipset di Quadro. Opzione "NoFlip" "boolean" Disabilita il flipping OpenGL; consultare l' appendice M per avere una descrizione. Preimpostazione: Flipping di OpenGL abilitato se possibile. Opzione "DigitalVibrance" "integer" Abilita il Digital Vibrance Control. La gamma di valori validi va da 0 a 255. Questa funzione non è disponibile per i prodotti precedenti alla GeForce2. Preimpostazione: 0. Opzione "Dac8Bit" "boolean" La maggior parte delle schede Quadro utilizzano per impostazione predefinita una tabella di look up dei colori (LUT) a 10 bit; l'impostazione di questa opzione su TRUE costringe questi processori grafici a utilizzare una LUT a 8 bit. Preimpostazione: se disponibile, viene utilizzata una LUT a 10 bit. Opzione "Overlay" "boolean" Abilita le sovrapposizioni RGB per la workstation. Questa opzione è supportata solo dai processori delle Quadro4 e Quadro FX (Quadro4 NVS esclusa) in profondità 24. Questa opzione spinge il server all'advertising della proprietà SERVER_OVERLAY_VISUALS della finestra root e la modalità GLX esegue il reporting di sovrapposizioni a 16 bit con buffer Z e buffer singolo o doppio. La chiave della trasparenza è il pixel 0x0000 (hex). Non esiste alcun supporto della correzione gamma nel piano dell'overlay. Questa funzione richiede la versione XFree86 4.1.0 o successiva. Le Quadro basate su NV17/18 (per esempio, 500/550 XGL) hanno limitazioni aggiuntive, ovvero, le sovrapposizioni non sono supportate in modalità TwinView o con i desktop virtuali di dimensioni superiori a 2046 x 2047 in qualsiasi direzione (cioè, non funzione per modalità 2048 x 1536). Le Quadro 7xx/9xx offrono visuali in overlay in queste modalità (TwinView, o desktop virtuali superiori a 2046 x 2047), ma l'overlay verrà emulato con una sostanziale riduzione delle prestazioni. Preimpostazione: disattivata. Opzione "CIOverlay" "boolean" Abilita sovrapposizioni dell'indice di colore della workstation con limitazioni identiche all'opzione "Overlay" precedente. Il server offre visuali sia con che senza un tasto trasparenza. Si tratta di visuali PseudoColor profondità 8. L'abilitazione degli overlay dell'indice di colore sui server X più vecchi di XFree86 4.3 costringe a disabilitare l'estensione RENDER a causa dei bug nella versione di questa estensione presente nelle release più vecchie dei server X. Preimpostazione: disattivata. Opzione "TransparentIndex" "integer" Quando le sovrapposizioni dell'indice di colore sono attivate, questa opzione permette all'utente di scegliere quali pixel sono utilizzati per il pixel trasparente nelle visuali che contengono pixel trasparenti. Questo valore è compreso tra 0 e 255 (Nota: alcune applicazioni quali Maya di Alias/Wavefront richiedono l'impostazione del valore zero per funzionare correttamente). Preimpostazione: 0. Opzione "OverlayDefaultVisual" "boolean" Quando si utilizzano le sovrapposizioni, questa opzione imposta una sovrapposizione come visuale predefinita, inserendovi la finestra root. Questa opzione è sconsigliata per le sovrapposizioni RGB. Preimpostazione: disattivata. Opzione "SWCursor" "boolean" Abilita o disabilita la resa software del cursore X. Preimpostazione: disabilitato. Opzione "HWCursor" "boolean" Abilita o disabilita la resa hardware del cursore X. Preimpostazione: abilitato. Opzione "CursorShadow" "boolean" Abilita o disabilita l'uso di un'ombra con il cursore, accelerato via hardware; si tratta di un duplicato traslucido della figura di un equivalente del cursore reale. Questa opzione è disponibile solo su GeForce2 MX o hardware migliore (per esempio qualsiasi chipset eccetto TNT/TNT2, GeForce 256, GeForce DDR e Quadro. Preimpostazione: nessun ombra cursore. Opzione "CursorShadowAlpha" "integer" Il valore alfa da utilizzare per l'ombra del cursore; applicabile solo con CursorShadow abilitato. Questo valore deve trovarsi nell'ambito di [0, 255] -- 0 è completamente trasparente; 255 è completamente opaco. Preimpostazione: 64. Opzione "CursorShadowXOffset" "integer" L'equivalente in pixel, dello scostamento dell'immagine ombra alla destra dell'immagine del cursore reale; applicabile solo con CursorShadow abilitato. Questo valore deve trovarsi nell'ambito [0, 32]: Preimpostazione: 4. Opzione "CursorShadowYOffset" "integer" L'equivalente in pixel, dello scostamento dell'immagine ombra verso il basso dell'immagine del cursore reale; applicabile solo se CursorShadow è abilitato. Questo valore deve trovarsi nell'ambito [0, 32]: Preimpostazione: 2. Opzione "ConnectedMonitor" "string" Consente di saltare ciò che il modulo kernel NVIDIA rileva, se collegato alla scheda video. Ciò può essere utile, per esempio quando si utilizza un interruttore KVM (tastiera, video, mouse), la commutazione prosegue quando X è avviato. In una situazione simile, il modulo kernel NVIDIA non può rilevare quali periferiche di visualizzazione sono collegate e l'x driver NVIDIA presume la connessione di un unico CRT. Valori validi per questa opzione sono "CRT" (tubo a raggi catodici), "DPF" (schermo piatto digitale) o "TV" (televisore); utilizzando TwinView, questa opzione può essere un elenco, separato da virgole di periferiche di visualizzazione; per esempio: "CRT, CRT" oppure "CRT, DFP". NOTA: qualsiasi dispositivo collegato a un connettore VGA a 15 piedini viene considerato dal driver come un CRT. "DFP" dovrebbe essere utilizzato solo per riferirsi a monitor a schermo piatto connessi mediante una porta DVI. Preimpostazione: stinga VUOTA. Opzione "UseEdidFreqs" "boolean" Questa opzione fa utilizzare al server X gli ambiti HorizSync e VertRefresh dati in un EDID di periferica di visualizzazione, se disponibile. L'informazione sull'ambito EDID, fa saltare gli ambiti HorizSync e VertRefresh, specificati nella sezione monitor. Se una periferica di visualizzazione non fornisce unEDID, o se l'EDID non specifica un ambito hsync o vrefresh, il server X prenderà per difetto gli ambiti HorizSync e VertRefresh specificati nella sezione monitor. Opzione "IgnoreEDID" "boolean" Disabilita l'esplorazione di EDID (Extended Display Identification data) del monitor. Vengono confrontati le modalità richieste con i valori rilevati dai monitor EDID (se disponibili), durante la validazione della modalità. Alcuni monitor forniscono informazioni errate sulle proprie capacità. Per validare una determinata modalità può quindi essere necessario ignorare i valori offerti dal monitor. D'altra parte, questa procedura dovrebbe essere adottata solo dagli utenti esperti. Preimpostazione: utilizzo di EDID. Opzione "NoDDC" "boolean" Sinonimo di "IgnoreEDID" Opzione "FlatPanelProperties" "string" Richiede di indicare le proprietà specifiche di ogni flat panel collegato come elenco separato da virgole di proprietà = coppie di valori. Attualmente, le sole due proprietà disponibili sono 'Scalatura' e 'Dithering'. I possibili valori di 'Scalatura' sono: 'default' (il driver lo usa ogni qualvolta lo stato di scalatura sia corrente), 'native' (il driver usa il dispositivo di scalatura del monitor a schermo piatto, se questo ne ha uno), 'scaled' (il driver usa il dispositivo di scalatura di NVIDIA, se possibile), 'centered' (il driver centrare l'immagine, se possibile), e 'aspect-scaled' (il driver effettua la scalatura con il dispositivo apposito di NVIDIA, ma conserva le corrette proporzioni). I possibili valori di 'Dithering' sono: 'default' (il driver decide quando effettuare il dithering), 'enabled' (il driver effettua sempre il dithering se possibile), e 'disabled' (il driver non effettua mai il dithering). Se una proprietà non è specificata, il suo valore deve essere 'default'. Un esempio di stringa di proprietà può avere questo aspetto: "Scalatura = centered, Dithering = enabled" Opzione "UseInt10Module" "boolean" Abilita l'uso del modulo Xfree86 Int10 per inizializzare tutte le schede secondarie, piuttosto che effettuare POSTing delle schede attraverso il modulo kernel di NVIDIA. Preimpostazione: disabilitato (Il posting viene effettuato attraverso il modulo kernel NVIDIA). Opzione "TwinView" "boolean" Abilita o disabilita TwinView. Consultare l'APPENDICE I per i dettagli. Preimpostazione: TwinView disabilitato. Opzione "TwinViewOrientation" "string" Controlla la relazione fra le due periferiche di visualizzazione quando si utilizza TwinView. Ha uno dei seguenti valori: "RightOf" "LeftOf" "Above" "Below" "Clone". Consultare l'APPENDICE I per i dettagli. Preimpostazione: stinga VUOTA. Opzione "SecondMonitorHorizSync" "range(s)" Questa opzione è simile all'immissione HorizSync nella sezione monitor, ma è destinata al secondo monitor, quando si utilizza TwinView. Consultare l'APPENDICE I per i dettagli. Preimpostazione: nulla. Opzione "SecondMonitorVertRefresh" "range(s)" Questa opzione è simile all'immissione VertexRefresh nella sezione monitor, ma è destinata al secondo monitor, quando si utilizza TwinView. Consultare l'APPENDICE I per i dettagli. Preimpostazione: nulla. Opzione "MetaModes" "string" Questa opzione descrive la combinazione di modalità da utilizzare per ogni monitor, quando si utilizza TwinView. Consultare l'APPENDICE I per i dettagli. Preimpostazione: stinga VUOTA. Opzione "NoTwinViewXineramaInfo" "boolean" In modalità TwinView, il driver NVIDIA X normalmente fornisce un'estensione Xinerama che permette ai client X (quali i gestori di finestre) di invocare XineramaQueryScreens() per scoprire la configurazione corrente di TwinView. Questo confonde alcuni gestori di finestre: l'opzione seguente consente quindi di disabilitare questo comportamento. Preimpostazione: sono fornite informazioni relative a TwinView Xinerama. Opzione "TVStandard" "string" Consultare (app-j) APPENDICE J: CONFIGURAZIONE DI TV-OUT. Opzione "TVOutFormat" "string" Consultare (app-j) APPENDICE J: CONFIGURAZIONE DI TV-OUT. Opzione "TVOverScan" "Decimal value in the range 0.0 to 1.0" I valori validi sono compresi nell'intervallo da 0,0 a 1,0; consultare (app-j) APPENDICE J: CONFIGURAZIONE DI TV-OUT. Opzione "Stereo" "integer" Abilita l'offerta di visuali stereo a buffer quadruplo per i chip Quadro. Il valore intero indica il tipo di occhiali stereo utilizzati: 1 - occhiali DDC. Il segnale di sincronia viene inviato agli occhiali per mezzo del segnale DDC trasmesso al monitor. Questi solitamente prevedono un cavo passante tra monitor e scheda video. 2 - occhiali "Blueline". Questi solitamente prevedono un cavo passante tra monitor e scheda video. Gli occhiali individuano l'occhio da visualizzare sulla base della lunghezza di una linea blu visibile in fondo allo schermo. In questa modalità, le dimensioni della finestra root sono di un pixel più corte della dimensione Y richiesta. Questa modalità non funziona per dimensioni della finestra root virtuale maggiori della finestra root visibile (panning del desktop). 3 - Supporto stereo integrato. Solitamente, questo è presente solo sulle schede professionali. Gli occhiali si collegano per mezzo di un connettore DIN sul retro della scheda video. 4 - modalità stereo clone TwinView (anche definita come "stereo passivo"). Sulle schede video che supportano TwinView, l'occhio sinistro viene visualizzato sul primo display, e l'occhio destro viene visualizzato sul secondo. Questo viene normalmente utilizzato unitamente ai speciali proiettori per produrre 2 immagini polarizzate che vengono quindi visualizzate con occhiali polarizzati. Per usare questa modalità stereo, occorre anche configurare TwinView in modalità clone con la stessa risoluzione, scostamento di panning e domini di panning su ciascun display. Stereo è disponibile solo sulle schede Quadro. Si possono utilizzare le opzioni 1, 2 e 3 (anche definita "stereo attivo") con TwinView se tutte le modalità di ciascun metamode hanno valori di timing identici. Si veda (app-l) APPENDICE L: MODALITÀ DI PROGRAMMAZIONE per suggerimenti sulla possibilità di accertare che le modalità contenute nei metamode siano identiche. Il requisito di identicità non è invece necessario per l'opzione Stereo 4 (o "stereo passivo"). Attualmente, il funzionamento stereo può risultare "irregolare" sui processori Quadro (NV10) originali e l'inversione sinistra - destra può essere imprecisa. Stiamo tentando di risolvere questo problema per una prossima release. Preimpostazione: Stereo disattivato. Le opzioni stereo 1, 2 e 3 (il cosiddetto stereo "attivo") non sono supportate dagli schermi piatti digitali. Opzione "AllowDFPStereo" "boolean" Per opzione predefinita, il driver NVIDIA X esegue una verifica che disabilita lo stereo attivo (opzioni stereo 1, 2 e 3) se lo schermo X sta azionando un DFP. L'opzione "AllowDFPStereo" permette di ignorare questa verifica. Opzione "NoBandWidthTest" "boolean" Quale parte della validazione della modalità, il driver X testa se una specifica modalità si adatti ai limiti della banda di memoria hardware. Questa opzione disabilita il test. Preimpostazione: la prova dell'ampiezza della banda di memoria viene eseguita. Opzione "IgnoreDisplayDevices" "string" Questa opzione indica che il modulo del kernel NVIDIA ignora completamente le classi indicate di periferiche di visualizzazione quando verifica quali periferiche di visualizzazione sono connesse. Si può specificare un elenco separato da virgole che contiene tutte le istanze "CRT", "DFP" e "TV". Per esempio: L'opzione "IgnoreDisplayDevices" "DFP, TV" fa sì che il driver NVIDIA non tenti di rilevare la connessione di alcun monitor a schermo piatto o apparecchio TV. Questa opzione normalmente non è necessaria; tuttavia, alcuni BIOS video contengono informazioni errate in merito alle periferiche di visualizzazione connesse, oppure alla porta i2c utilizzata per il rilevamento. Questi errori possono provocare lunghi ritardi nell'avvio di X. Se si riscontrano tali ritardi, è possibile evitarli istruendo il driver NVIDIA ad ignorare le periferiche di visualizzazione notoriamente scollegate. NOTA: qualsiasi dispositivo collegato a un connettore VGA a 15 piedini è considerato dal driver come un CRT. "DFP" dovrebbe essere utilizzato solo per riferirsi a monitor a schermo piatto collegati per mezzo di una porta DVI. Opzione "MultisampleCompatibility" "boolean" Abilita o disabilita l'uso di buffer multisample separati anteriore e posteriore. Questo consumerà una quantità maggiore di memoria ma è necessario per correggere l'output quando si effettua il rendering sui buffer anteriore e posteriore di un multisample o di un FSAA disegnabile. Questa opzione è necessaria per il corretto funzionamento di SoftImage XSI. Preimpostazione: un singolo buffer multisample viene condiviso tra i buffer anteriore e posteriore. Opzione "NoPowerConnectorCheck" "boolean" Il driver X di NVIDIA termina l'inizializzazione del server X se rileva che una GPU che richiede un connettore di alimentazione esterna non è collegato alla rete. Questa opzione può essere utilizzata per ignorare il test. Preimpostazione: il test del connettore di alimentazione viene eseguito. __________________________________________________________________________ (app-e) APPENDICE E: IMPOSTAZIONI VARIABILI AMBIENTE OPENGL __________________________________________________________________________ ANTI-ALIASING A SCENA INTERA L'anti-aliasing è una tecnica utilizzata per levigare i bordi degli oggetti di una scena, per ridurre l'effetto frastagliato a "scalino" che a volte può comparire nell'immagine. L'anti-aliasing a scena intera è supportato dalle GPU GeForce o dall'hardware più recente. Impostando la variabile ambiente adeguata, è possibile abilitare anti-aliasing a tutta scena per ogni applicazione OpenGL di queste GPU. Sono disponibili diversi metodi di anti-aliasing ed è possibile selezionare fra questi, impostando adeguatamente la variabile ambiente __GL_FSAA_MODE. Si noti, che aumentando il numero dei campioni rilevati durante la resa SFAA la performance ne può soffrire. Le seguenti tabelle descrivono i possibili valori per __GL_FSAA_MODE e il loro effetto sulle varie GPU NVIDIA. __GL_FSAA_MODE GeForce, GeForce2, Quadro, e Quadro2 Pro ----------------------------------------------------------------------- 0 FSAA disabilitato 1 FSAA disabilitato 2 FSAA disabilitato 3 1.5 x 1.5 sovracampionamento 4 2 x 2 sovracampionamento 5 FSAA disabilitato 6 FSAA disabilitato 7 FSAA disabilitato __GL_FSAA_MODE GeForce4 MX, GeForce4 4xx Go, Quadro4 380,550,580 XGL e Quadro4 NVS ----------------------------------------------------------------------- 0 FSAA disabilitato 1 2x Multicampionamento bilineare 2 2x Multicampionamento Quincunx 3 FSAA disabilitato 4 2 x 2 sovracampionamento 5 FSAA disabilitato 6 FSAA disabilitato 7 FSAA disabilitato __GL_FSAA_MODE GeForce3, Quadro DCC, GeForce4 Ti, GeForce4 4200 Go e Quadro4 700,750,780,900,980 XGL ----------------------------------------------------------------------- 0 FSAA disabilitato 1 2x Multicampionamento bilineare 2 2x Multicampionamento Quincunx 3 FSAA disabilitato 4 4x Multicampionamento bilineare 5 4x Multicampionamento Gaussian 6 2x Multicampionamento bilineare per 4x sovracampionamento 7 FSAA disabilitato __GL_FSAA_MODE GeForce FX, Quadro FX ----------------------------------------------------------------------- 0 FSAA disabilitato 1 2x Multicampionamento bilineare 2 2x Multicampionamento Quincunx 3 FSAA disabilitato 4 4x Multicampionamento bilineare 5 4x Multicampionamento Gaussian 6 2x Multicampionamento bilineare per 4x sovracampionamento 7 2x Multicampionamento bilineare per 4x sovracampionamento FILTRAGGIO ANISOTROPICO DELLA TEXTURE Il filtraggio anisotropico automatico della texture può essere abilitato impostando la variabile dell'ambiente __GL_DEFAULT_LOG_ANISO. I valori utili sono: __GL_DEFAULT_LOG_ANISO GeForce/GeForce2/GeForce4 MX Descrizione ----------------------------------------------------------------------- 0 Nessun filtraggio anisotropico 1 Abilita filtraggio anisotropico automatico __GL_DEFAULT_LOG_ANISO GeForce3/GeForce4 Ti/GeForce FX Descrizione ----------------------------------------------------------------------- 0 Nessun filtraggio anisotropico 1 Filtraggio anisotropico basso 2 Filtraggio anisotropico medio 3 Filtraggio anisotropico massimo VBLANK SYNCING L'impostazione della variabile ambiente__GL_SYNC_TO_VBLANK su un valore diverso da zero forza glXSwapBuffers a sincronizzarsi con la refresh rate verticale del monitor (effettuare uno swap solo durante il periodo di azzeramento verticale) di GeForce o con dispositivi hardware più nuovi (ovvero, con qualsiasi prodotto, ad eccezione delle schede TNT/TNT2). Quando si usa __GL_SYNC_TO_VBLANK con TwinView, OpenGL può effettuare la sincronizzazione con uno solo dei dispositivi di visualizzazione; questo può causare danni al dispositivo al quale OpenGL non viene sincronizzato. È possibile utilizzare la variabile di ambiente __GL_SYNC_DISPLAY_DEVICE per specificare il dispositivo di destinazione dell'operazione di sincronia OpenGL. Si dovrebbe impostare questa variabile di ambiente utilizzando il nome del dispositivo di visualizzazione scelto: per esempio "CRT-1". Verificare l'istruzione "Connected display device(s):" nel file XFree86.0.log per un elenco dei dispositivi di visualizzazione presenti e dei loro nomi. DISABILITAZIONE DELLE FUNZIONI SPECIFICHE DELLA CPU L'impostazione della variabile di ambiente __GL_FORCE_GENERIC_CPU a un valore non zero inibisce l'uso delle funzioni specifiche della CPU quali MMX, SSE o 3DNOW!. L'uso di questa opzione può dare luogo a una perdita di prestazioni. Questa opzione può essere utile unitamente a software quale il debugger di memoria Valgrind. __________________________________________________________________________ (app-f) APPENDICE F: CONFIGURAZIONE AGP __________________________________________________________________________ Esistono diverse opzioni per configurare l'uso del modulo kernel Nvdriver per AGP: è possibile scegliere se utilizzare il modulo AGP NVIDIA (NVAGP) od il modulo AGP, inviato insieme al kernel linux (AGPGART). Ciò viene controllato attraverso l'opzione "NvAGP" nel file XF86Config: L'opzione "NvAgp" "0" ... disabilita il supporto AGP L'opzione "NvAgp" "1" ... utilizza NVAGP, se possibile L'opzione "NvAgp" "2" ... utilizza AGPGART, se possibile L'opzione "NvAGP" "3" ... tenta AGPGART; se fallisce, tenta NVAGP Il valore predefinito è 3 (il valore predefinito era 1 fino alla 1.0-1251). È possibile utilizzare il modulo AGP, che funziona meglio con il chipset AGP disponibile. Se si riscontrano problemi di stabilità, occorre eseguire l'avvio, disabilitando AGP, per verificare se questa opzione risolve il problema. È poi possibile utilizzare alternativamente i moduli AGP. Lo stato di AGP può essere verificato in qualsiasi momento attraverso l'interfaccia /proc filesystem (vedere APPENDICE O: INTERFACCIA PROC). Per poter utilizzare il modulo Linux AGPGART, questo deve essere compilato con il kernel utilizzato, sia collegato staticamente che costruito come modulo. Il supporto AGP NVIDIA non può essere utilizzato, se AGPGART è caricato nel kernel. È consigliabile compilare AGPGART come modulo ed accertare che non sia caricato quando si tenta di utilizzare AGP NVIDIA. Occorre anche tenere presente che la sostituzione di driver AGP in genere richiede una reinizializzazione per rendere effettivamente efficaci le modifiche. I seguenti chipset AGP sono supportati da AGP NVIDIA; per tutti gli altri chipset è consigliabile utilizzare il modulo AGPGART. o Intel 440LX o Intel 440BX o Intel 440GX o Intel 815 ("Solano") o Intel 820 ("Camino") o Intel 830 o Intel 840 ("Carmel") o Intel 845 ("Brookdale") o Intel 845G o Intel 850 ("Tehama") o Intel 860 ("Colusa") o AMD 751 ("Irongate") o AMD 761 ("IGD4") o AMD 762 ("IGD4 MP") o VIA 8371 o VIA 82C694X o VIA KT133 o VIA KT266 o RCC 6585HE o Micron SAMDDR ("Samurai") o Micron SCIDDR ("Scimitar") o nForce AGP o nForce 2 AGP o ALi 1621 o ALi 1631 o ALi 1647 o ALi 1651 o ALi 1671 o SiS 630 o SiS 633 o SiS 635 o SiS 645 o SiS 730 o SiS 733 o SiS 735 o SiS 745 Se si riscontrano problemi di stabilità di AGP, si dovrebbe tenere presente quanto segue: o Supporto per l'estensione delle dimensioni della pagina del processore sui processori Athlon Alcuni kernel linux hanno un bug che causa un conflitto negli attributi della cache che viene riscontrato utilizzando la caching speculativa avanzata dei nuovi processori della famiglia AMD Athlon (AMD Athlon XP, AMD Athlon 4, AMD Athlon MP e i Models 6 e superiori dell'AMD Duron). Questo bug del kernel solitamente compare con l'uso intensivo della grafica 3D accelerata con una scheda grafica AGP. Le distribuzioni Linux basate sul kernel 2.4.19 e successivi 'dovrebbero' incorporare la soluzione del bug. Tuttavia, i kernel più vecchi richiedono un intervento dell'utente per effettuare la disabilitazione di una piccola porzione della caching speculativa avanzata (normalmente eseguita per mezzo di una patch del kernel). Viene inoltre specificata un'opzione di boot che consente l'applicazione dell'intera soluzione. Il driver Nvidia disabilita automaticamente la piccola porzione del caching speculativo avanzato dedicata ai processori AMD affetti dal problema senza la necessità di applicare una patch al kernel. La si può quindi utilizzare anche sui kernel che incorporano già la soluzione del bug del kernel. Inoltre, per i kernel più vecchi l'utente esegue la porzione dell'opzione di avvio della soluzione disabilitando esplicitamente le pagine da 4 MB. Questo è possibile agendo sulla riga di comando di boot specificando: mem=nopentium Oppure aggiungendo la seguente riga a etc/lilo.conf: append = "mem=nopentium" o Impostazione BIOS dell'intensità dell'unità AGP (schede madri basate su Via) Numerose schede madri basate su Via permettono la regolazione dell'intensità dell'unità AGP nel BIOS di sistema. L'impostazione di questa opzione influenza in modo importante la stabilità di sistema e l'intervallo compreso tra 0xEA e 0xEE sembra il più adatto all'hardware NVIDIA. L'impostazione di entrambi i nibble a 0xF in generale produce seri problemi di stabilità. Se si decide di effettuare esperimenti con questi valori, occorre tenere presente che i risultati possono essere imprevedibili e che impostazioni errate possono dar luogo all'impossibilità di avviamento del sistema, sino a che non si ripristini un valore corretto delle impostazioni (con una scheda grafica PCI oppure ripristinando il BIOS ai valori predefiniti). o Versione del BIOS di sistema Accertarsi di disporre del BIOS di sistema più recente fornito dal fabbricante della scheda. o Velocità di AGP Si può decidere di ridurre l'impostazione della velocità AGP se il valore utilizzato sembra produrre dei blocchi di sistema. È possibile ottenere questo risultato estraendo il file .run: sh NVIDIA-Linux-ia64-1.0-5336-pkg1.run --extract-only cd NVIDIA-Linux-ia64-1.0-5336-pkg1.run/usr/src/nv/ Quindi modificando il file os-registry.c nel modo seguente: - static int NVreg_ReqAGPRate = 7; + static int NVreg_ReqAGPRate = 4; /* force AGP Rate to 4x */ oppure + static int NVreg_ReqAGPRate = 2; /* force AGP Rate to 2x */ oppure + static int NVreg_ReqAGPRate = 1; /* force AGP Rate to 1x */ e quindi rimuovendo i due trattini lunghi iniziali: - { "__ReqAGPRate", &NVreg_ReqAGPRate }, + { "ReqAGPRate", &NVreg_ReqAGPRate }, Infine, occorre ricompilare e caricare il nuovo modulo kernel. Sulle schede madre Athlon con chipset VIA KX133 o 694X, quali la scheda ASUS K7V, i driver NVIDIA passano per opzione predefinita alla modalità AGP 2x per supplire all'insufficiente intensità di uno dei due segnali. È possibile forzare il sistema a passare alla modalità AGP 4x impostando NVreg_EnableVia4x su 1. Si noti che questa impostazione può rendere instabile il sistema. Su chipset ALi1541 ed ALi1647, i driver NVIDIA disabilitano la funzione di AGP in relazione a problemi di temporizzazione e problemi di integrità del segnale. È possibile forzare l'abilitazione della modalità AGP su questi chipset impostando NVreg_EnableALiAGP su 1. Si noti che questo potrebbe rendere instabile il sistema. __________________________________________________________________________ (app-g) APPENDICE G: PROBLEMI SPECIFICI ALI __________________________________________________________________________ I seguenti suggerimenti possono aiutare a stabilizzare i sistemi ALI: o Disabilitare TURBO AGP MODE nel BIOS. o Utilizzando P5A, effettuare l'aggiornamento BIOS versione 1002 BETA 2. o Utilizzando 1007, 1007A o 1009 regolare IO Recovery Time a 4 cicli. o AGP su alcuni chipset ALI (ALi1541, ALi1647)è disabilitato per opzione predefinita, per poter risolvere gravi problemi di stabilità del sistema con questi chipset. Per forzare AGP comunque, consultare i commenti relativi a NVreg_EnableALiAGP in os-registry.c. __________________________________________________________________________ (app-h) APPENDICE H: PROBLEMI SPECIFICI TNT __________________________________________________________________________ Molti problemi relativi alle schede SGRAM/SDRAM TNT possono essere risolti. Ma esiste una possibilità remota, che la scheda video abbia installato un BIOS non corretto, in questo caso il driver continuerà a non funzionare correttamente. Se accade questo, effettuare quanto segue: o Controllare il monitor quando il sistema viene inizializzato. Il primissimo schermo delle annotazioni identificherà il tipo della memoria video della vostra scheda. Questa sarà SGRAM o SDRAM. o Editare il file "os-registry.c" dalle sorgenti del modulo kernel. Cercare la variabile "NVreg_VideoMemoryTypeOverride". Impostare il valore della variabile del tipo di memoria posseduta (numericamente, consultare la riga appena soprastante). Dato che normalmente questa variabile non viene utilizzata, sostituire "#if 0" che si trova 10 righe al di sopra della variabile a "#if 1". o Ricostruire e reinstallare il nuovo driver ("make") __________________________________________________________________________ (app-i) APPENDICE I: CONFIGURAZIONE DI TWINVIEW __________________________________________________________________________ La caratteristica TwinView è supportata unicamente dalle GPU NVIDIA che supportano la funzione display-doppio, come GeForce2 MX, GeForce2 Go, Quadro2 MXR, Quadro2 Go e qualsiasi modello delle serie GeForce4 o Quadro4. Verificare con il venditore della scheda video, che TwinView sia supportato dalla scheda. TwinView è una modalità operativa che consente la visualizzazione del contenuto di un'unica schermata X su due periferiche di visualizzazione (schermi piatti digitali, CRT e TV) con qualsiasi configurazione arbitraria. Questo metodo di utilizzo di molteplici monitor ha diversi vantaggi rispetto ad altre tecniche (come Xinerama): o Si utilizza un unico schermo X. Il driver NVIDIA nasconde tutte le informazioni sulle periferiche di visualizzazione multipla di X server; per quanto sia lontano X, si ha solo uno schermo. o Entrambe le periferiche di dividono un unico frame buffer. Pertanto, tutte le funzioni di un singolo display (per esempio, OpenGL accelerate), sono disponibili per TwinView. o Non sono necessarie risorse aggiuntive per emulare un desktop singolo. Se l'utente è interessato all'uso di ciascun dispositivo di visualizzazione come schermo X separato, consultare (app-r) APPENDICE R: CONFIGURAZIONE DI PIÙ SCHERMI X SU UNA SOLA SCHEDA. OPZIONI XF86CONFIG TWINVIEW per abilitare TwinView, occorre specificare le seguenti opzioni nella sezione Dispositivo del file XF86Config: Opzione "TwinView" Opzione "SecondMonitorHorizSync" "" Opzione "SecondMonitorVertRefresh" "" Opzione "MetaModes" "" È inoltre possibile utilizzare una delle seguenti opzioni, sebbene non siano necessarie: Opzione "TwinViewOrientation""" Opzione "ConnectedMonitor" "" Consultare la descrizione dettagliata di ogni opzione, qui sotto: o TwinView Questa opzione è necessaria per abilitare TwinView; senza di essa tutte le altre opzioni TwinView correlate vengono ignorate. o SecondMonitorHorizSync, SecondMonitorVertRefresh Attraverso queste opzioni si specificano i limiti del secondo monitor. I valori dati, seguiranno la stessa convenzione delle immissioni "HorizSync" e "VertRefresh" della sezione monitor. Come spiega la pagina principale: gli ambiti possono essere un elenco, separato da virgola, di valori distinti e/o ambiti di valori, in cui un ambito è dato da due valori distinti, separati da uno spazio. HorizSync è dato in kHz, e VertRefresh in Hz. Se ci si affida alle periferiche di visualizzazione EDID, è possibile utilizzare l'opzione "UseEdidFreqs", invece di queste opzioni (consultare l'appendice D per avere una descrizione dell'opzione "UseEdidFreqs"). o MetaMode Un MetaMode singolo descrive quale modalità utilizzare per una periferica di visualizzazione in un determinato momento. Più MetaMode elencano le combinazioni di modalità e la sequenza in cui devono essere utilizzate. Quando il driver NVIDIA comunica a X quali modalità sono disponibili, si tratta effettivamente del perimetro di delimitazione minimo del MetaMode che viene comunicato a X, mentre la modalità "per display device" viene mantenuta interna al driver NVIDIA. In sintassi MetaMode, le modalità all'interno di un MetaMode sono separate da virgole, e più MetaMode sono separati da punti e virgola. Per esempio: ", ; , " Dove è il nome della modalità da utilizzare nel dispositivo di visualizzazione 0 in modo concomitante con utilizzato sul dispositivo di visualizzazione 1. Uno switch di modalità provoca quindi l'utilizzo di sul dispositivo di visualizzazione 0 e sul dispositivo di visualizzazione 1. Ecco una voce MetaMode effettiva da un file di configurazione XF86Config di esempio: Opzione "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768" Se si desidera che un dispositivo di visualizzazione non sia attivo in uno specifico MetaMode, è possibile utilizzare il nome della modalità "NULL", o semplicemente omettere integralmente il nome della modalità: "1600x1200, NULL; NULL, 1024x768" oppure "1600x1200; , 1024x768" Facoltativamente, i nomi di modalità possono essere seguiti da informazioni sullo scostamento per controllare il posizionamento dei dispositivi di visualizzazione all'interno dello spazio dello schermo virtuale; per esempio: "1600x1200 +0+0, 1024x768 +1600+0; ..." Le descrizioni degli scostamenti seguono le convenzioni utilizzate nell'opzione riga comando X "-geometry"; ovvero, sono validi sia scostamenti positivi che negativi, sebbene quelli negativi siano consentiti solo quando il file XF86Config fornisce esplicitamente una dimensione schermo, virtuale. Quando per un MetaMode non viene fornito alcuno scostamento, questi vengono calcolati in base al valore dell'opzione TwinViewOrientation (vedi sotto). Si noti, che quando si specificano scostamenti per una delle modalità in un MetaMode singolo, questi scostamenti vengono poi richiesti da tutte le modalità comprese nel Metamode singolo; se non vengono specificati scostamenti, si presume un valore scostamento di +0+0. Se non esplicitamente data, la misura dello schermo virtuale, sarà calcolata come il perimetro di delimitazione di tutti i perimetri di delimitazione MetaMode. I MetaMode con perimetri di delimitazione superiori ad una dimensione di schermo virtuale specificata saranno eliminati. Una stringa MetaMode può essere ulteriormente modificata attraverso una specificazione "Panning Domain", per es.: "1024x768 @1600x1200, 800x600 @1600x1200" Un panning domain, è l'area in cui la viewport di una periferica di visualizzazione sarà mossa per seguire il mouse. Panning, con TwinView, avviene su due livelli: prima, la viewport di una periferica di visualizzazione individuale sarà mossa entro il suo "panning domain", fino a che la viewport sarà compresa nel perimetro di delimitazione del MetaMode. Quando il mouse lascia il perimetro di delimitazione del MetaMode, il MetaMode completo (per esempio tutte le periferiche di visualizzazione), sarà mosso per seguire il mouse sullo schermo virtuale. Si noti che i panning domain delle periferiche di visualizzazione individuali, per opzione predefinita, sono chiusi nella posizione delle viewport delle periferiche di visualizzazione, così il comportamento per opzione predefinita è soltanto quello mantenere "bloccate" le viewport insieme, eseguendo solo il secondo tipo di movimento. L'uso principale dei panning domain, probabilmente è quello destinato ad eliminare zone morte- regioni dello schermo virtuale che sono inaccessibili, a causa di periferiche di visualizzazione con risoluzioni diverse. Per esempio: "1600x1200, 1024x768" produce una regione inaccessibile al di sotto del display 1024x768. Specificare un panning domain per la seconda periferica di visualizzazione: "1600x1200, 1024x768 @1024x1200" offre accesso a quella zona morta, consentendo di muovere la viewport 1024x768 su e giù entro il panning domain 1024x1200. Gli scostamenti possono essere utilizzati insieme al panning domain per posizionare i panning domain negli spazi dello schermo virtuale (nota che lo scostamento descrive il panning domain e interessa la viewport unicamente per ciò che concerne la viewport compresa entro il panning domain). Per esempio, di seguito vengono descritti due modalità, con una larghezza di panning domain di 1900 pixel ed il secondo display posizionato sotto al primo: "1600x1200 @1900x1200 +0+0, 1024x768 @1900x768 +0+1200" Se non è specificata nessuna stringa MetaMode, l'X driver utilizzerà le modalità elencate nella sottosezione "display", tentando di piazzare le modalità corrispondenti su ogni periferica di visualizzazione. o TwinViewOrientation Questa opzione controlla il posizionamento della seconda periferica di y visualizzazione, relativamente alla prima, all'interno dello schermo X virtuale, quando gli scostamenti non sono esplicitamente previsti in un MetaMode. i valori possibili sono: "RightOf" (default) "LeftOf" "Above" "Below" "Clone" quando è specificato "clona", ad entrambe le periferiche di visualizzazione sarà assegnato uno scostamento di 0,0. o ConnectedMonitor Questa opzione consente di saltare ciò che il modulo kernel NVIDIA rileva, se collegato alla scheda video. Ciò può essere utile, per esempio, se una delle periferiche di visualizzazione non supporta il rilevamento, utilizzando i protocolli Display Data Channel (DDC). Valori validi per questa opzione sono "CRT" (tubo a raggi catodici), "DFP" (schermo piatto digitale) o "TV" (televisione); utilizzando TwinView, questa, opzione può essere un elenco, separato da virgole, di periferiche di visualizzazione; per esempio: "CRT, CRT" oppure "CRT, DFP". Come per tutte le immissioni XF86Config, gli spazi vengono ignorati e tutte le immissioni possono essere fatte indifferentemente con lettere maiuscole o minuscole. DOMANDE FREQUENTI SU TWINVIEW D: Sul secondo monitor non viene visualizzato nulla; perché? R: I monitor che non supportano il rilevamento attraverso protocolli Display Data Channel (DDC) (che comprendono la maggior parte dei monitor più vecchi) non possono essere rilevati dalla scheda NVIDIA. I monitor che non supportano il rilevamento attraverso protocolli Display Data Channel (DDC) (che comprendono la maggior parte dei monitor più vecchi) non possono essere rilevati dalla scheda NVIDIA; per esempio: Opzione "ConnectedMonitor" "CRT, CRT" D: La gestione finestre è in grado di disporre appropriatamente le finestre (per esempio evitando di sistemare le finestre attraverso entrambe le periferiche di visualizzazione o in zone inaccessibili del desktop virtuale)? R: Sì. L'X driver NVIDIA fornisce un'estensione Xinerama, che consente agli X client (come la gestione finestre), di far conoscere a XineramaQueryScreens l'attuale configurazione TwinView. Si noti, che il protocollo Xinerama non offre un modo per informare i client della necessità di una modifica della configurazione. Così, passando ad un altro MetaMode, la gestione finestre penserà che venga ancora utilizzata la configurazione precedente. Utilizzando l'estensione Xinerama, insieme all'estensione XF86ViMode per eventi modeswitch, la gestione finestre sarà in grado di determinare la configurazione TwinView in un determinato momento. Sfortunatamente, i dati offerti da XineramaQueryScreens() sembrano confondere alcuni gestori di finestre; per risolvere questi problemi, è possibile disabilitare la comunicazione della disposizione dello schermo di TwinView con l'opzione XF86Config "NoTwinViewXineramaInfo" (consultare l'Appendice D per ulteriori dettagli). Si tenga presente che il driver NVIDIA non può offrire l'estensione Xinerama se si utilizza l'estensione XFree86 di Xinerama. La specificazione esplicita di Xinerama nel file XF86Config o nella riga di comando di XFree86 impedisce l'installazione dell'estensione Xinerama di NVIDIA, quindi è necessario verificare che il file /var/log/XFree86.0.log di XFree86 non riporti: (++) Xinerama: enabled se si desidera che il driver NVIDIA sia in grado di fornire l'estensione Xinerama mentre ci si trova in TwinView. Un'altra soluzione è quella di utilizzare i panning domain, per eliminare zone inaccessibili dello schermo virtuale (vedi descrizione MetaMode qui sopra). Una terza soluzione consiste nell'utilizzare due schermate X separate, invece di utilizzare TwinView. Consultare (app-r) APPENDICE R: CONFIGURAZIONE DI PIÙ SCHERMI X SU UNA SOLA SCHEDA. D: Perché non è possibile ottenere una risoluzione di 1600x1200 sulla seconda periferica di visualizzazione quando si usa una GeForce2 MX? R: Perché la seconda periferica di visualizzazione è stata studiata per essere uno schermo piatto digitale, pertanto il ciclo pixel della seconda periferica di visualizzazione è solo 150 MHz. Ciò effettivamente limita la risoluzione della seconda periferica di visualizzazione intorno a 1280x1024 (per una descrizione di come un ciclo di pixel limiti le modalità programmabili, consultare Video Timings HOWTO). Questa limitazione non è presente sui chip GeForce4 o GeForce FX -- il clock massimo di pixel è lo stesso su entrambe le testine. D: Le sovrapposizioni video lavorano attraverso entrambe le periferiche di visualizzazione? R: Le sovrapposizioni video hardware lavorano solo sulla prima periferica di visualizzazione. La soluzione generale, è quella di utilizzare blitted video anziché TwinView. D: Come vengono determinate le misure dello schermo virtuale in TwinView? R: Dopo che tutti le modalità richieste sono stati validate e lo scostamento per ogni viewport MetaMode è stato calcolato, il driver NVIDIA calcolerà il perimetro di delimitazione del panning domain, per ogni MetaMode. Verranno poi determinate la larghezza e l'altezza massima del perimetro di delimitazione. Si noti che l'effetto collaterale di ciò, è che la larghezza e l'altezza virtuale possono derivare da MetaMode diversi. Data la seguente stringa MetaMode: "1600x1200,NULL; 1024x768+0+0, 1024x768+0+768" risulterà la dimensione dello schermo virtuale 1600 x 1536. D: È possibile giocare a schermo intero utilizzando entrambe le periferiche di visualizzazione? R: Sì. Mentre i dettagli di configurazione possono variare da gioco a gioco, l'idea di base è che un MetaMode presenti a X una modalità la cui risoluzione sia il perimetro di delimitazione dei viewport di quel MetaMode. Per esempio, si consideri quanto segue: Opzione "MetaModes" "1024x768,1024x768; 800x600,800x600" Opzione "TwinViewOrientation" "RightOf" produce due modalità: una con risoluzione 2048x768 e l'altra con risoluzione 1600x600. Giochi come Quake 3 Arena, utilizzano l'estensione VidMode per scoprire le modalità di risoluzione attualmente disponibili. Per configurare Quake 3 Arena per l'utilizzo della stringa MetaMode suddetta, aggiungere quanto segue al file q3config: seta r_customaspect "1" seta r_customheight "600" seta r_customwidth "1600" seta r_fullscreen "1" seta r_mode "-1" Si tenga presente, che data la configurazione soprastante, non esiste modalità con risoluzione 800x600 (occorre ricordare che MetaMode "800x600, 800x600" ha una risoluzione di 1600x600"), così se si modifica Quake 3 Arena, affinché utilizzi una risoluzione di 800x600, sarà visualizzato nell'angolo inferiore sinistro dello schermo, con il resto dello schermo oscurato. Per avere un singolo modello head disponibile, la stringa MetaMode adeguata può assomigliare a: "800x600,800x600; 1024x768,NULL; 800x600,NULL; 640x480,NULL" L'informazione più dettagliata sulla configurazione di giochi specifici, va al di là dello scopo di questa pubblicazione, ma gli esempi fatti, insieme a diverse fonti on-line, possono essere sufficienti per segnare la giusta direzione. __________________________________________________________________________ (app-j) APPENDICE J: CONFIGURAZIONE DI TV-OUT __________________________________________________________________________ Le schede video su base GPU NVIDIA con connettore TV-Out (S-video) possono essere utilizzate per usare il televisore come altra periferica di visualizzazione, come CRT o come uno schermo piatto digitale. Il televisore può essere utilizzato da solo (o con scheda video appropriata) in collegamento con un'altra periferica di visualizzazione in una configurazione TwinView. Se il televisore è l'unica periferica di visualizzazione collegata alla scheda video, potrà essere utilizzato come display principale quando si inizializza il sistema (per esempio, la console verrà portata sul televisore, come se si trattasse di un CRT). Per utilizzate il televisore con X, occorre fare attenzione ad alcuni parametri del file XF86Config: o valori VertRefresh e HorizSync della sezione monitor; occorre verificare, che siano adatti al televisore. Generalmente i valori sono: HorizSync 30-50 VertRefresh 60 o Le modalità nella sezione schermo; le modalità valide per il codificatore TV vengono riportate in un file verboso di XFree86.0.log (generato con `startx -- -logverbose 5`) quando X viene eseguito su un apparecchio TV. Alcune modalità possono essere limitate ad alcuni standard televisivi; in tal caso, questa circostanza verrà annotata nel file XFree86.0.log. In genere, sono supportate almeno le modalità 800x600 e 640x480. o L'opzione "TVStandard" può essere aggiunta alla sezione schermo; valori validi sono: "PAL-B" : utilizzato in Belgio, Danimarca, Finlandia, Germania, Guinea, Hong Kong, India, Indonesia, Italia, Malesia, Paesi Bassi, Norvegia, Portogallo, Singapore, Spagna, Svezia e Svizzera "PAL-D" : utilizzato in Cina e nella Corea del Nord "PAL-G" : utilizzato in Danimarca, Finlandia, Germania, Italia, Malesia, Paesi Bassi, Norvegia, Portogallo, Spagna, Svezia e Svizzera "PAL-H" : utilizzato in Belgio "PAL-I" : utilizzato ad Hong Kong e nel Regno Unito "PAL-K1" : utilizzato in Guinea "PAL-M" : utilizzato in Brasile "PAL-N" : utilizzato in Francia, Paraguay ed Uruguay "PAL-NC" : utilizzato in Argentina "NTSC-J" : utilizzato in Giappone "NTSC-M" : utilizzato in Canada, Cile, Colombia, Costa Rica, Ecuador, Haiti, Honduras, Messico, Panama, Puerto Rico, Corea del sud, Taiwan, Stati Uniti d'America e Venezuela La riga del file XF86Config deve essere simile a: Opzione "TVStandard" "NTSC-M" Se non viene specificato TVStandard o viene specificato un valore non valido, verrà utilizzato per opzione predefinita "NTSC-M". Nota: se il vostro paese non è presente nell'elenco qui sopra, scegliere il paese più vicino al vostro. o L'opzione "ConnectedMonitor" può essere utilizzata per chiedere a X di utilizzare il televisore come display. Ciò è necessario solo se il televisore non viene rilevato dalla scheda video o se si utilizza un CRT (o schermo piatto digitale) come display di inizializzazione, ma si vuole reindirizzare X ad utilizzare il televisore. La riga nel file config dovrebbe essere: Opzione "ConnectedMonitor" "TV" o L'opzione "TVOutFormat" (formato TVOut) può essere utilizzata per forzare l'uscita SVIDEO o COMPOSITE. Senza questa opzione, il driver autorileva il formato output. Purtroppo, non sempre ciò avviene in modo corretto. Il formato output può essere forzato con le opzioni: Opzione "TVOutFormat" "SVIDEO" oppure Opzione "TVOutFormat" "COMPOSITE" o L'opzione "TVOverScan" può essere utilizzata per attivare la funzione overscan qualora sia supportata. I valori validi sono decimali nell'intervallo 1.0 (che significa quanto più overscan possibile: massimizza le dimensioni dell'immagine) e 0.0 (che disabilita l'overscan: minimizza l'immagine). L'overscan è disabilitato (0.0) per opzione predefinita. L'overscan attualmente è disponibile solamente sulle GPU GeForce4 o più nuove con codificatori TV NVIDIA o Conexant. Il driver NVIDIA XFree86 non può ripristinare la console correttamente con le versioni XFree86 precedenti alla 4.3 quando la console è una TV. Questo è provocato da incompatibilità binarie tra i moduli XFree86 e int10. Se si utilizza una TV come console si raccomanda di passare alla versione XFree86 4.3. __________________________________________________________________________ (app-k) APPENDICE K: CONFIGURAZIONE DI UN PORTATILE __________________________________________________________________________ INSTALLAZIONE E CONFIGURAZIONE Le operazioni di installazione e configurazione di NVIDIA Accelerated Linux Driver Set su un portatile si svolgono allo stesso modo per qualsiasi ambiente desktop, con poche eccezioni di portata minore, elencate di seguito. A partire dalla release 1.0-2802, le informazioni in merito al monitor a schermo piatto interno da utilizzare per l'inizializzazione dello schermo sono generate per opzione predefinita dai dati archiviati nel BIOS video. Questa opzione può essere disabilitata impostando l'opzione "SoftEDID" del kernel sul valore 0. Se "SoftEDIDs" è disattivata, allora i dati necessari vengono selezionati da una tabella, basata sul valore dell'opzione "Mobile" del kernel. L'opzione "Mobile" del kernel può essere impostata su uno qualsiasi dei valori seguenti: 0xFFFFFFFF : il modulo del kernel rileva automaticamente il valore corretto 1 : per i portatili Dell 2 : per i portatili Toshiba non Compal 3 : per tutti gli altri portatili 4 : per i portatili Toshiba Compal 5 : per i portatili Gateway Di nuovo, l'opzione "Mobile" del kernel è necessaria soltanto se SoftEDIDs è disabilitato; se viene utilizzata, è solitamente più sicuro lasciare che il modulo kernel rilevi automaticamente il valore corretto (si tratta del comportamento predefinito). Qualora fosse necessario alterare queste opzioni, procedere come segue: o modificare il file os-registry.c nella directory usr/src/nv/ del file .run. o impostare il valore nella riga di comando modprobe (per esempio: `modprobe nvidia NVreg_SoftEDIDs=0 NVreg_Mobile=3`) o aggiungere una riga "opzioni" al file di configurazione del modulo, solitamente /etc/modules.conf (per esempio: "options nvidia NVreg_Mobile=5") FUNZIONI AGGIUNTIVE TWINVIEW Tutti i processori mobili NVIDIA supportano TwinView. TwinView, su un portatile, può essere configurato nello stesso modo che su un PC desktop (consultare APPENDICE I qui sopra); si noti che in una configurazione TwinView che utilizza lo schermo piatto interno ed il CRT esterno, CRT è la periferica di visualizzazione primaria (specificare HorizSync e VertRefresh nella sezione monitor del file XF86Config) e lo schermo piatto è la seconda periferica di visualizzazione(specificare HorizSync e VertRefresh attraverso le opzioni SecondMonitorHorizSync e SecondMonitorVertRefresh). È anche possibile utilizzare l'opzione UseEdidFreqs per acquisire HorizSync e VertRefresh dall'EDID di ogni periferica di visualizzazione e non preoccuparsi di effettuare l'impostazione nel file XF86Config (ciò deve essere effettuato solo se si può fare affidamento sugli EDID riportati della periferica di visualizzazione-consultare la descrizione dell'opzione UseEdidFreqs in APPENDICE D per ottenere dettagli). HOTKEY SWITCHING DELLE PERIFERICHE DI VISUALIZZAZIONE Oltre a TwinView, i processori mobili NVIDIA hanno anche la capacità di reagire ad un avvenimento hotkey, commutando fra ognuna delle periferiche di visualizzazione collegate ed ogni combinazione possibile di queste (si consideri, che possono essere attive solo 2 periferiche di comunicazione per volta). TwinView, come configurato nel file XF86Config, e la funzione hotkey sono reciprocamente esclusive - se si abilita TwinView nel file XF86Config il driver NVIDIA X ignorerà gli avvenimenti LCD/CRT hotkey. Un altro aspetto importante della funzione hotkey è che e possibile collegare e rimuovere dinamicamente una periferica di visualizzazione al/dal portatile ed il relativo hotkey, senza riavviare X. Un quesito relativo a tutto ciò, è come validare e determinare quali modalità possono essere programmate per ogni periferica di visualizzazione. Per prima cosa, è molto utile utilizzare UseEdidFreqs, in modo che hsync e vrefresh per ogni periferica di visualizzazione possano essere trovati dall'EDID delle periferiche di visualizzazione, altrimenti, la semantica di ciò che il contenuto della sezione monitor cambierebbe costantemente con ogni avvenimento hotkey. Quando si avvia X o quando viene rilevata una modifica nell'elenco delle periferiche di visualizzazione collegate, viene costruito un nuovo elenco di sequenze hotkey -- questo elenca quale periferica di visualizzazione viene usata per ogni avvenimento hotkey. Quando si verifica un avvenimento hotkey, viene scelto lo stato hotkey successivo della sequenza. Ogni modalità richiesta dal file XF86Config viene convalidata nei confronti di ogni vincolo della periferica di visualizzazione e la modalità risultante è resa disponibile per quella periferica di visualizzazione. Qualora risulti necessario attivare più periferiche di visualizzazione contemporaneamente, le modalità di ognuna di queste devono essere accoppiate; se non è possibile trovare una corrispondenza esatta (stessa risoluzione), viene trovata la corrispondenza più vicina e si utilizza il panning della periferica di visualizzazione con la risoluzione più bassa, entro la risoluzione dell'altra periferica di visualizzazione. Quando avviene la commutazione vt da X, la console vga viene sempre ripristinata alla periferica di visualizzazione su cui si trovava all'avvio di X. Allo stesso modo, quando si riesegue la commutazione vt a X, viene utilizzata la stessa configurazione della periferica di visualizzazione sfruttata per la commutazione vt da X, senza considerare quale attività LCD/CRT hotkey fosse corso durante la commutazione vt da X. MODALITÀ NON STANDARD SU DISPLAY LCD Alcuni utenti hanno riscontrato difficoltà nel programmare una modalità 1400x1050 (la risoluzione nativa di alcuni LCD di portatili). Alla versione 4.0.3 di Xfree86 sono stati aggiunti diversi modalità 1400x1050 al database di modalità predefinite, ma se si sta utilizzando una versione precedente di Xfree86, può essere utilizzata la seguente riga: # -- 1400x1050 -- # 1400x1050 @ 60 Hz, 65.8 kHz hsync Modeline "1400x1050" 129 1400 1464 1656 1960 1050 1051 1054 1100 +HSync +VSync PROBLEMI NOTI RELATIVI A PORTATILI o La commutazione LCD/CRT hotkey attualmente non funziona sui portatili Toshiba, con l'eccezione della serie Toshiba Satellite 3000. o Attualmente TwinView non funziona sui portatili Toshiba della serie Satellite 2800. o Le sovrapposizioni video hardware lavorano solo sulla prima periferica di visualizzazione su cui è stato avviato X. Per esempio, se X viene avviato sul LCD interno, avviando un'applicazione video che utilizza sovrapposizione video (utilizzare l'adattatore "Video overlay", annunciato attraverso l'estensione XV) e poi commutando hotkey per aggiungere la seconda periferica di visualizzazione, il video non apparirà sulla seconda periferica di visualizzazione. È possibile sia configurare l'applicazione video per utilizzare l'adattatore "Video Bitter", annunciato attraverso l'estensione XV ( ciò è sempre possibile) o commutare hotkey alla periferica di visualizzazione su cui si desidera utilizzare la sovrapposizione video "prima" di avviare X. __________________________________________________________________________ (app-l) APPENDICE L: MODALITÀ DI PROGRAMMAZIONE __________________________________________________________________________ NVIDIA Accelerated Linux Driver Set supporta tutte le modalità standard VGA e VESA e la maggior parte di quelle definite dall'utente; il double-scan e le modalità interfacciate sono supportate da qualsiasi hardware. In genere la periferica di visualizzazione (monitor/schermo piatto/televisione) sarà più vincolata alla modalità da utilizzare, che la scheda video basata su GPU NVIDIA o Accelerated Linux Driver Set. Per richiedere una o più modalità standard da utilizzare con X, è possibile aggiungere semplicemente righe "Modes", come: Modes "1600x1200" "1024x768" "640x480" nella corrispondente sottosezione Display, del file XF86Config (consultare la pagina principale XF86Config(4/5) per avere dettagli). La seguente documentazione è di interesse primario, se si intende comporre righe modalità, su misura, provare xvidtune(1) o semplicemente se si desidera apprendere di più. Si noti che questa non è una spiegazione, né una guida destinata alla preparazione di righe modalità per Xfree86. Serve piuttosto per documentare XFree86 Video Timings HOWTO (che può essere trovato su www.tldp.org). PROFONDITÀ, BIT PER PIXEL E PITCH Pur non interessando direttamente la programmazione di modalità, i bit utilizzati per i pixel sono un problema se si considera la massima risoluzione programmabile; per questo motivo, è utile chiarire la definizione di "profondità" e "bit per pixel". La profondità è la quantità di bit dei dati memorizzata per pixel. Le profondità supportate sono 8, 15, 16 e 24. La maggior parte dei video hardware memorizza dati pixel in misura di 8, 16 o 32 bit; questa è la quantità di memoria allocata per pixel. Quando si specifica la profondità, X seleziona la dimensione bit per pixel (bpp) in cui memorizzare i dati. Qui sotto compare una tabella dei valori bpp utilizzati per ogni possibile profondità: profondità bpp ===== ===== 8 8 15 16 16 16 24 32 Il "Pitch" è invece la quantità di byte nel frame buffer lineare che si trova fra un dato pixel e quello immediatamente sottostante. Si può definire questa quantità come la risoluzione orizzontale moltiplicata per i byte per pixel (bit per pixel diviso 8). In pratica, i pitch possono essere in numero superiore a quanto indicato da questa moltiplicazione a causa di problemi di allineamento. RISOLUZIONI MASSIME NVIDIA Accelerated Linux Driver Set e video basato su GPU NVIDIA, supportano risoluzioni fino a 2048x1536, quindi la risoluzione massima supportata dal sistema è limitata anche dalla quantità di memoria video (vedi FORMULE UTILI) e dalla risoluzione massima supportata dalla periferica di visualizzazione (monitor/schermo piatto/televisione). Si consideri anche che se l'utilizzo di sovrapposizioni video non limita la risoluzione massima, la refresh rate, la larghezza di banda utilizzata dalla modalità programmata influisce sulla qualità di sovrapposizione. FORMULE UTILI La risoluzione massima è la funzione relativa sia alla quantità di memoria video che ai bit per pixel che si vogliono utilizzare: HR * VR * (bpp/8) = memoria video utilizzata In altre parole, la quantità di memoria video utilizzata è uguale alla risoluzione orizzontale (HR), moltiplicata per la risoluzione verticale (VR), moltiplicata per i byte per pixel (bit per pixel diviso otto). Tecnicamente, la memoria video è effettivamente il pitch che fissa la risoluzione verticale e il pitch può essere leggermente superiore a (HR * (bpp/8)), per provvedere all'esigenza del hardware, che chiede che pitch sia un multiplo di alcuni valori. Si noti che ciò costituisce semplicemente uso di memoria per il frame buffer; la memoria video viene utilizzata anche da altre cose, come OpenGL o pixmap caching. Un'altra relazione importante è quella fra la risoluzione, il ciclo pixel (anche definito come dot clock) e la refresh rate verticale: RR = PCLK / (HFL * VFL) In altre parole, la refresh rate (RR) è uguale al ciclo pixel diviso per il numero totale di pixel: la lunghezza frame orizzontale (HFL) moltiplicata per la lunghezza frame verticale (VFL) (si noti che queste sono lunghezze frame e non le risoluzioni visibili). Come descritto in XFree86 Video Timings HOWTO, la formula soprastante può essere riscritta come: PCLK = RR * HFL * VFL Considerando un ciclo di pixel massimo, è possibile regolare RR, HFL e VFL come desiderato, fino a che il prodotto dei tre diventa consistente. Il ciclo pixel viene riportato nel file log, quando si avvia X con jogging verboso: `startx -- -logverbose 5`. Il file XFree86.0.log può contenere diverse righe come: (--) 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 che indicano il massimo ciclo pixel di ogni bit per dimensione pixel. VALIDAZIONE DEI MODALITÀ Durante la fase PreInit del server X server, il driver X NVIDIA convalida tutti le modalità necessarie, come segue: o Rileva l'intersezione degli ambiti HorizSync e VertRefresh, dati dall'utente in XF86Config con gli ambiti riportati dal monitor in EDID (Extended Display Identification Data); questo può essere disabilitato utilizzando l'opzione "IgnoreEDID", in questo caso X driver accetterà incondizionatamente gli ambiti HorizSync e VertRefresh, dati dall'utente. o Richiama la funzione aiuto conxf86ValidateModes, che trova le modalità con i nomi specificati dall'utente nel file XF86Config, eliminando le modalità con frequenze sync orizzontali non valide o refresh rate verticali, cicli pixel superiori al ciclo pixel massimo della scheda grafica o risoluzioni superiori alla dimensione dello schermo virtuale (se ne è stata specificata una nel file XF86Config). Vengono applicati diversi altri vincoli; vedi xc/programs/Xserver/hw/xfree86/common/xf86Mode.c:xf86ValidateModes(). o Tutti le modalità restituite da xf86ValidateModes() vengono poi esaminate per garantire che le risoluzioni non siano superiori a quella della modalità massima riportata dall'EDID monitor (questa opzione può essere disabilitata mediante il comando "IgnoreEDID"). Se il display è un televisore, ogni modalità viene controllata per garantire che abbia una risoluzione supportata dal codificatore TV (generalmente solo 800x600 e 640x480 sono supportate dal codificatore). o Tutte le modalità sono inoltre sottoposte a test per confermare che si adattino ai limiti di ampiezza di banda di memoria dell'hardware. Questo test può essere disabilitato con l'opzione del file NoBandWidthTest XF86Config. o Tutti le restanti modalità vengono controllate per garantire che superino i vincoli descritti qui sotto in VINCOLI MODALITÀ AGGIUNTIVI. Gli ultimi tre passi vengono effettuati anche quando viene programmato ogni modalità, per rilevare modalità potenzialmente non valide attraverso XF86VidModeExtension (eg xvidtune(1)). Per TwinView, la validazione precedente viene effettuata per le modalità richieste per ogni periferica di visualizzazione. VINCOLI AGGIUNTIVI MODALITÀ Qui sotto si trova un elenco dei vincoli aggiuntivi relativi ai parametri di una modalità che devono essere soddisfatti. In alcuni casi, queste sono specifiche di alcuni particolari processori. o La risoluzione orizzontale (HR) deve essere un multiplo di 8 e uguale o inferiore al valore della tabella sottostante. o L'ampiezza vuota (il massimo della lunghezza frame orizzontale e sync end orizzontale meno il minimo della risoluzione orizzontale e sync start orizzontale (max(HFL, HSE) - min (HR,HSS)) o deve essere un multiplo di 8 e uguale o inferiore al valore della tabella sottostante. o La sync start orizzontale (HSS) deve essere un multiplo di 8 e uguale o inferiore al valore della tabella sottostante. o L'ampiezza sync orizzontale (sync end orizzontale meno sync start orizzontale (HSE - HSS)) un multiplo di 8 e uguale o inferiore al valore della tabella sottostante. o La lunghezza frame orizzontale (HFL) deve essere un multiplo di 8 e uguale o inferiore al valore della tabella sottostante. o La risoluzione verticale (VR) deve essere uguale o inferiore al valore della tabella sottostante. o L'ampiezza vuota verticale (il massimo della lunghezza frame verticale e la sinc end verticale meno il minimo della risoluzione verticale ed il sync start verticale (max(VFL, VSE) - min (VR,VSS)) deve essere uguale o inferiore al valore della tabella sottostante. o Sync start verticale (VSS) deve essere uguale o inferiore al valore della tabella sottostante. o L'ampiezza sync verticale (sync end verticale meno sync start verticale (Vse - VSS)) deve essere uguale o inferiore al valore della tabella sottostante. o La lunghezza frame verticale (VFL) deve essere maggiore o uguale a 2 e uguale o inferiore al valore della tabella sottostante. Valori massimi DAC ------------------ | GeForce/TNT Geforce2 e 3 Geforce4 o più nuove ______|_______________________________________________ | HR | 4096 4096 8192 HBW | 1016 1016 2040 HSS | 4088 4088 8224 HSW | 256 256 512 HFL | 4128 4128 8224 VR | 2048 4096 8192 VBW | 128 128 256 VSS | 2047 4095 8192 VSW | 16 16 16 VFL | 2049 4097 8192 Ecco un esempio di riga di modalità che dimostra l'uso di ciascuna delle abbreviazioni appena ricordate: # Riga modalità personalizzata per il monitor a schermo piatto SGI 1600SW #name PCLK HR HSS HSE HFL VR VSS VSE VFL Modeline "sgi1600x1024" 106.9 1600 1632 1656 1672 1024 1027 1030 1067 TIMING DI MODALITÀ IDENTICI Alcune funzionalità, quali Active Stereo con TwinView, richiedono di esercitare un controllo sui timing di modalità effettivamente impiegati. Esistono diverse strategie per arrivare a questo risultato: o Se si desidera soltanto essere certi che entrambi i dispositivi di visualizzazione stiano impiegando la stessa modalità, occorre solo accertarsi che entrambi si avvalgano degli stessi valori di HorizSync e VertRefresh quando si esegue la convalida della modalità; questo può essere effettuato accertandosi che HorizSync e SecondMonitorHorizSync corrispondano, verificando poi anche la coppia VertRefresh e SecondMonitorVertRefresh. o Un approccio più esplicito consiste nella definizione della modeline da utilizzare (impiegando uno dei generatori di modeline disponibili), e avvalendosi poi di un nome esclusivo. Per esempio, se si desidera utilizzare una risoluzione 1024 x 768 a 120 Hz su ciascun monitor in TwinView con stereoscopia attiva, si deve aggiungere un'istruzione simile a: # 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 Nella sezione Monitor e quindi nella sezione Screen del file XF86Config, definire una MetaMode simile alla seguente: Option "MetaModes" "1024x768_120, 1024x768_120" VEDERE ANCHE: Un generatore di modeline XFree86, conforme allo standard GTF è disponibile all'indirizzo: http://gtf.sourceforge.net/ Per reperire altri generatori di modeline, tentare la ricerca di "modeline" su freshmeat.net. __________________________________________________________________________ (app-m) APPENDICE M: FLIPPING E UBB __________________________________________________________________________ Il nuovo NVIDIA Accelerated Linux Driver Set supporta il flipping di Unified Back Buffer (UBB) e OpenGL. Queste funzionalità possono fornire vantaggi prestazionali in alcune situazioni specifiche. o Unified Back Buffer (UBB): Lo UBB è disponibile solo sulla famiglia Quadro di GPU (Quadro4 NVS esclusa) ed è abilitato per opzione predefinita quando vi è una quantità sufficiente di memoria video disponibile. Questa funzione può essere disabilitata con l'opzione UBB XF86Config descritta nell'Appendice D. Quando la UBB è abilitata, tutte le finestre condividono gli stessi buffer per back, stencil e depth. Quando le finestre sono numerose, l'uso di back, stencil e depth non supera mai le dimensioni di quelle utilizzate da una finestra a schermo intero. Tuttavia, anche per una singola finestra di dimensioni ridotte l'uso di back, stencil e depth sono identici a quelli di una finestra a schermo intero, quindi in tal caso la ram video potrebbe essere utilizzata con un'efficienza minore rispetto alla funzione UBB. o Flipping: quando il flipping OpenGL è abilitato, OpenGL può eseguire buffer swapping modificando il buffer di scansione DAC invece di copiare il contenuto del back buffer sul front buffer; in genere, si tratta di un metodo che offre livelli prestazionali nettamente più elevati e consente la possibilità di swapping ottimizzato durante il rintracciamento verticale (quando __GL_SYNC_TO_VBLANK è definito). Le condizioni per il flipping OpenGL sono leggermente più complesse, ma, in generale: su hardware Geforce o più nuovo, OpenGL può effettuare il flipping quando una singola applicazione OpenGL non oscurata a schermo intero è in esecuzione e __GL_SYNC_TO_VBLANK risulta definito. Inoltre, OpenGL può eseguire il flipping su hardware Quadro anche quando una finestra OpenGL è parzialmente oscurata o non visibile a schermo intero o __GL_SYNC_TO_VBLANK non risulta definito. __________________________________________________________________________ (app-n) APPENDICE N: PROBLEMI NOTI __________________________________________________________________________ I seguenti problemi non sono stati risolti con la corrente release e sono tuttora in corso di soluzione. o OpenGL + Xinerama Attualmente, OpenGL viene visualizzato solo sulla prima testina di un ambiente Xinerama. o OpenGL e dlopen() Vi sono alcuni problemi con le versioni più vecchie del caricatore dinamico glibc (per esempio, la versione distribuita con Red Hat Linux 7.2) e applicazioni quali Quake3 e Radiant, che utilizzano dlopen(). Consultare la sezione DOMANDE FREQUENTI per ulteriori dettagli. o DPMS e TwinView Le modalità di DPMS "suspend" e "standby" non funzionano correttamente con un secondo CRT quando si usa TwinView. Invece di impostare il monitor allo stato DPMS richiesto, lo schermo si svuota. o DPMS e Flat Panel Le modalità di DPMS "suspend" e "standby" non funzionano correttamente con una periferica di visualizzazione a schermo piatto. Invece di impostare il monitor allo stato DPMS richiesto, lo schermo si svuota. o Multicard, Multimonitor In alcuni casi, la scheda secondaria non viene inizializzata correttamente dal modulo kernel di NVIDIA. È possibile evitare il problema abilitando il modulo XFree86 Int10 all'avvio software di tutte le schede secondarie. Vedere "APPENDICE D: OPZIONI DI XF86CONFIG" per ulteriori dettagli. o Portatili Se si sta usando un portatile, si consiglia di consultare la sezione "Problemi noti dei portatili" nell'APPENDICE D. o FSAA Quando si attiva l'opzione FSAA (la variabile di ambiente __GL_FSAA_MODE è impostata su un valore che abilita FSAA e si sceglie una visuale multicampione), il rendering può essere danneggiato quando si ridimensiona la finestra. o Interazione con pthreads Le applicazioni a single thread che eseguono dlopen() sulla libreria libGL di NVIDIA, e quindi eseguono dlopen() su qualsiasi altra libreria collegata a pthreads si bloccano sulla libreria libGL di NVIDIA. Questo non si verifica con le nuove librerie ELF TLS OpenGL di NVIDIA (consultare (app-c) APPENDICE C: COMPONENTI INSTALLATI per un'accurata descrizione delle librerie ELF TLS OpenGL). Possibili soluzioni per questo problema: 1) Caricare la libreria collegata con pthreads prima del caricamento di libGL.so. 2) Collegare l'applicazione a pthreads. PROBLEMI HARDWARE Questa sezione descrive problemi che non sono ancora stati risolti. In genere, si tratta di problemi originati da fattori del tutto incontrollabili per NVIDIA. Segue un elenco dei problemi: o Scheda madre Gigabyte GA-6BX Questa scheda madre si avvale di un regolatore LinFinity del percorso a 3,3 V con una classificazione di soli 5 A -- inferiore alla specifica AGP, che richiede 6 A. Quando la diagnostica o le applicazioni sono in esecuzione, la temperatura del regolatore si alza, provocando la caduta di tensione del processore NVIDIA sino a 2,2 V. In queste circostanze, il regolatore non è in grado di fornire la corrente al percorso a 3,3 V che il processore NVIDIA richiede. Questo problema non si verifica quando la scheda grafica dispone di un regolatore a commutazione o quando una sorgente di alimentazione esterna viene collegata al percorso a 3,3 V. o Chipset VIA KX133 e 694X con AGP 2x Sulle schede madre Athlon con chipset VIA KX133 o 694X, quali la scheda ASUS K7V, i driver NVIDIA passano per opzione predefinita alla modalità AGP 2x per supplire all'insufficiente intensità di uno dei due segnali. o Chipset Irongate con AGP 1x I trasferimenti AGP 1x sono utilizzati dalle schede madri Athlon con il chipset Irongate per aggirare un problema di integrità del segnale del chipset. o Chipset ALi1541 e ALi1647 Su chipset ALi1541 ed ALi1647, i driver NVIDIA disabilitano la funzione di AGP in relazione a problemi di temporizzazione e problemi di integrità del segnale. Vedere "APPENDICE G: PROBLEMI SPECIFICI ALI" per ulteriori informazioni sui chipset ALi. o I/O APIC (SMP) Se si riscontrano problemi di stabilità con una macchina SMP Linux e si notano messaggi di avvertimento I/O APIC dal kernel Linux, l'affidabilità di sistema può essere nettamente migliorata dall'impostazione del parametro del kernel "noapic". o APIC locale (UP) Su alcuni sistemi, l'impostazione dell'opzione di configurazione del kernel su "Local APIC Support on Uniprocessors" può avere effetti negativi sulla stabilità e sulle prestazioni. Se si riscontrano blocchi con macchine UP Linux e questa opzione attivata, provare a disabilitare il supporto APIC locale. __________________________________________________________________________ (app-o) APPENDICE O: INTERFACCIA PROC __________________________________________________________________________ L'interfaccia del filesystem /proc permette di ottenere informazioni di runtime in merito al driver, a qualsiasi scheda grafica NVIDIA installata e allo status AGP. Queste informazioni sono contenute in diversi file di /proc/driver/nvidia. o/proc/driver/nvidia/version Elenca la revisione del driver installato e la versione del compilatore GNU C utilizzato per creare il modulo kernel Linux. o /proc/driver/nvidia/cards/0...3 Fornisce informazioni su ciascuno degli adattatori grafici NVIDIA installati (nome modello, IRQ, versione BIOS, tipo Bus). Si noti che la versione del BIOS è disponibile solo mentre X è in esecuzione. o /proc/driver/nvidia/agp/card Le informazioni sulle capacità AGP della scheda installata. o /proc/driver/nvidia/agp/host-bridge Le informazioni sul bridge host (modello e capacità AGP). o /proc/driver/nvidia/agp/status Lo stato AGP corrente. Se sul sistema è stato abilitato il supporto AGP, vengono mostrati il driver AGP in corso di utilizzo, la velocità AGP e le informazioni sullo stato di AGP Fast Writes e Side Band Addressing. Il driver AGP è NVIDIA (il driver AGP NVIDIA incorporato) o AGPGART (il driver agpgart.o del kernel linux). Se si nota la voce "inactive" accanto ad AGPGART, questo significa che il chipset AGP è stato programmato da AGPGART, ma non è attualmente in uso. SBA e Fast Writes indicano se una di queste funzionalità è attualmente in uso. Si noti che sono numerosi i fattori che concorrono all'eventuale attivazione del supporto a entrambe le opzioni. Prima di tutto, sia la scheda AGP che il bridge host devono essere in grado di supportare la funzione. Anche se entrambi la supportano, il driver può decidere di non utilizzarla a favore di una migliore stabilità del sistema. Questo è particolarmente vero nel caso di AGP Fast Writes. __________________________________________________________________________ (app-p) APPENDICE P: SUPPORTO XVMC __________________________________________________________________________ La presente release include il supporto di X-Video Motion Compensation (XvMC) versione 1.0 API sui soli prodotti GeForce4 e GeForce FX. Esiste una libreria statica "libXvMCNVIDIA.a" e una dinamica "libXvMCNVIDIA_dynamic.so" che è adatta alle operazioni di dlopening. I prodotti GeForce4 MX e GeForce FX supportano sia i livelli di accelerazione "IDCT" che quelli "motion-compensation" di XvMC. I prodotti GeForce4 Ti supportano solo il livello di compensazione del movimento. Le sottoimmagini AI44 e IA44 sono supportate. Sono supportate le superfici 4:2:0 sino a 2032 x 2032. libXvMCNVIDIA osserva la variabile di ambiente XVMC_DEBUG e offre output di debug a stderr se impostata a un valore intero appropriato. '0' disabilita l'output di debug. '1' abilita l'output di debug per le condizioni di guasto. '2' o maggiore abilita l'output dei messaggi di avvertimento. __________________________________________________________________________ (app-q) APPENDICE Q: SUPPORTO GLX __________________________________________________________________________ La presente release supporta GLX 1.3 con le seguenti estensioni: GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_ARB_get_proc_address Per una descrizione di queste estensioni, si prega di esaminare il registro delle estensioni OpenGL all'indirizzo http://oss.sgi.com/projects/ogl-sample/registry/index.html Alcune delle suddette estensioni esistono quale parte della funzionalità core GLX 1.3, tuttavia, e sono esportate anche come estensioni solo per assicurare la retrocompatibilità. __________________________________________________________________________ (app-r) APPENDICE R: CONFIGURAZIONE DI PIÙ SCHERMI X SU UNA SOLA SCHEDA __________________________________________________________________________ I processori grafici che supportano TwinView (vedere (app-i) APPENDICE I: CONFIGURAZIONE DI TWINVIEW) possono anche essi essere configurati per trattare ciascuna periferica di visualizzazione collegata come uno schermo X separato. Sebbene questo approccio presenti diversi svantaggi rispetto all'opzione TwinView (per esempio: le finestre non possono essere trascinate tra i vari schermi X, non è possibile suddividere contenuto OpenGL con accelerazione hardware tra due schermi X), questo offre diversi vantaggi rispetto a TwinView: o Se ciascuna periferica di visualizzazione costituisce uno schermo X separato, allora le proprietà che possono variare tra gli schermi X possono variare anche tra i display (per esempio: profondità, dimensione della finestra root, ecc). o L'hardware che può essere utilizzato solo su un display alla volta (per esempio: sovrapposizioni video, sovrapposizione RGB ad accelerazione hardware), e che conseguentemente non può essere assolutamente utilizzato in modalità TwinView, può essere esposto sul primo schermo X quando ciascun display è uno schermo X separato. o L'associazione 1 a 1 delle periferiche di visualizzazione agli schermi X storicamente è maggiormente in linea con X. Ecco la procedura necessaria per configurare due schermi X separati per condividere un processore grafico: Per prima cosa, creare due sezioni Device separate, ciascuna con il codice BusID delle schede grafiche da condividere, ciascuna che elenca il driver come "nvidia", e gli assegna una schermata separata: Section "Device" Identifier "nvidia0" Driver "nvidia" # Modifica il BusID includendo la posizione della scheda grafica BusID "PCI:2:0:0" Screen 0 EndSection Section "Device" Identifier "nvidia1" Driver "nvidia" # Modifica il BusID includendo la posizione della scheda grafica BusID "PCI:2:0:0" Screen 1 EndSection Quindi creare, due sezioni Screen, ciascuna delle quali utilizza una delle sezioni 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 (nota: occorre creare anche una seconda sezione Monitor) Infine, aggiornare la sezione ServerLayout in modo che faccia uso di entrambe le sezioni Screen: Section "ServerLayout" ... Screen 0 "Screen0" Screen 1 "Screen1" leftOf "Screen0" ... EndSection Per ulteriori dettagli, fare riferimento alla pagina XF86Config. (app-s) APPENDICE S: SUPPORTO DELLA GESTIONE DELL'ALIMENTAZIONE __________________________________________________________________________ Questa release include il supporto per la gestione dell'alimentazione basata su APM. Questo significa che il nostro driver supporterà le funzioni di sospensione e ripresa, ma non supporterà lo standby. La bios dei sistemi laptop deve supportare APM, e non semplicemente ACPI. Numerosi, ma non tutti, dei sistemi laptop basati su GeForce2 e GeForce4 includono il supporto di APM. È possibile verificare la presenza del supporto APM mediante l'interfaccia procfs (controllate l'esistenza di /proc/apm), oppure via l'output di boot del kernel: % dmesg | grep -i apm un messaggio simile a questo indica il supporto apm: apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16) mentre un messaggio come questo indica la mancanza del supporto apm: No APM support in Kernel Sebbene il supporto ACPI stia compiendo progressi nello sviluppo dei kernel ed esistano alcune patch per i kernel 2.4, il driver grafico di NVIDIA non fornisce tuttora supporto all'ACPI. Speriamo di proporvi questa opzione nel prossimo futuro. Si noti che la funzione di standby non è supportata, ma anche che il kernel non tenterà di accedere allo standby se istruito a farlo. Quando si alterano i livelli di potenza, numerosi servizi di sistema sono avvertiti della variazione per consentire loro di gestirla in modo appropriato. Per esempio, il networking viene disabilitato prima della sospensione, quindi riabilitato quando si riprende. Quando il kernel tenta di accedere allo standby, il bios non riesce a portare a termine con successo il tentativo. Il kernel stampa il messaggio di errore "standby: Parameter out of range", ma non notifica il problema ai servizi di sistema. Di conseguenza, il sistema non va in sospensione, ma tutti i servizi di sistema vengono disabilitati e il sistema sembra bloccato. Il modo migliore per recuperare da questa situazione consiste nella disattivazione e quindi nella ripresa. Alcuni laptop fanno riscontrare un danno al bus agp quando riprendono l'attività in seguito a una sospensione che porti a un blocco di sistema. La disabilitazione dell'AGP permette di aggirare questo problema (vedere APPENDICE F: CONFIGURAZIONE DELL'AGP per ulteriori dettagli sulla disabilitazione dell'agp).