LEGGIMI & Guida all'installazione NVIDIA Accelerated Linux Driver Set Ultimo aggiornamento: DatR: 2001/11/26 $ Driver più recente: 1.0-2313 NVIDIA Accelerated Linux Driver Set, offre a Linux x86 sia supporto per le funzioni 2D accelerate, che per OpenGL ad alta prestazione, con l'uso dei processori grafici di NVIDIA. Questi drivers consentono un'accelerazione hardware ottimizzata delle applicazioni OpenGL, attraverso un server X di resa diretta e supporto per i chipset di TNT, TNT2(M64/Pro/Ultra), GeForce 256, GeForce2 GTS, GeForce2 MX (200/400),GeForce2 Pro, GeForce2 Ti, GeForce 2 Ultra, GeForce2 Go, GeForce3,GeForce3 Ti (200/500), Quadro, Quadro DDC, Quadro2 (MXR/EX), Quadro2 Pro e Quadro2 Go. Vengono supportati anche TvinView, TV-Out e display a schermo piatto. Questo file descrive come installare, configurare ed utilizzare NVIDIA Accelerated Linux Driver Set. Il contenuto di diversi file LEGGIMI, che in precedenza erano separati, è stato incluso in questo file, per comodità (questi file separati erano: ALI_USERS_README, TNT_USERS_README, LAPTOP_README,TWINVIEW_README e TVOUT_README). Questo file LEGGIMI si trova sul sito di NVIDIA e viene fornito con il pacchetto NVIDIA_GLX (installato in/usr/share/doc/NVIDIA_GLX-1.0/). __________________________________________________________________________ CONTENUTO: (sez-01) SCELTA DEI PACCHETTI NVIDIA ADATTI AL SISTEMA (sez-02) INSTALLAZIONE DEI PACCHETTI NVIDIA_KERNEL E NVIDIA_GLX (sez-03) EDITAZIONE DEL PROPRIO FILE XF86CONFIG (sez-04) RICERCA ED ELIMINAZIONE DI GUASTI (sez-05) DOMANDE FREQUENTI (sez-06) CONTATTARCI (sez-07) ULTERIORI RISORSE (app-a) APPENDICE R: 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: CONFIGURAZINE 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: MODALITA' DI PROGRAMMAZIONE (app-m) APPENDICE M: PAGE FLIPPING, WINDOW FLIPPING, ED UBB (app-n) APPENDICE N: PROBLEMI NOTI 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 nelle sezioni ricerca ed eliminazione di guasti e FAQ. Si raccomanda, pertanto, di leggere completamente il presente file LEGGIMI,prima di eseguire i passi descritti. __________________________________________________________________________ (sez-01) SCELTA DEI PACCHETTI NVIDIA ADATTI AL SISTEMA __________________________________________________________________________ NVIDIA ha un modello di architettura driver unificata; ciò significa che un driver set, può essere utilizzato con ogni hardware NVIDIA supportato. Consultare l'appendice A, in relazione all'elenco del hardware NVIDIA supportato dei driver attuali. NVIDIA Accelerated Linux Driver Set, è composto da due pacchetti che dovranno essere scaricati ed installati: il pacchetto NVIDIA_GLX che contiene le biblioteche OpenGL ed il driver Xfree86 ed il pacchetto NVIDIA_kernel, che contiene il modulo kernel driver NV, necessario per l'X driver e le biblioteche OpenGL del pacchetto NVIDIA_GLX (per maggiori dettagli sui componenti di ogni pacchetto, consultare l'appendice C). Dovranno essere installati entrambi i pacchetti, con numero di versione corrispondente (p.e. NVIDIA_GLX-0.9-6 potrà essere utilizzato esclusivamente con NVIDIA_kernel-0.0-6 e non con NVIDIA_kernel-0.9-3). I pacchetti sono disponibili in diversi formati: rpm, srpm, e file tar. L'installazione di ogni tipo di pacchetto è descritta qui sotto. Il tipo di pacchetto dipende dalla preferenza personale, ma occorre notare, che i binari rpms sono utilizzabili esclusivamente con il kernel, inviato con una diffusione particolare (p.e. NVIDIA_kernel-0.9-6.rh62.i386.rpm potrà essere utilizzato esclusivamente con il kernel monoprocessore, inviato con RedHat 6.2). Dove necessario, NVIDIA ha fornito rpm separati per i diversi SMP ed i nuclei monoprocessore di ogni diffusione. Se avete aggiornato il kernel(sia manualmente, che attraverso aggiornamento della diffusione), o se un rpm NVIDIA-kernel non è disponibile per la vostra diffusione, occorre utilizzare srpm NVIDIA_kernel od il file tar. Nel caso in cui i distributori dovessero inviare molteplici nuclei (come accade spesso nel caso di macchine monoprocessore e SMP), saranno disponibili molteplici rpm, p.e.: NVIDIA_kernel-0.9-7.rh62.i386.rpm e NVIDIA_kernel-0.9-7.rh62.smp.i386.rpm. Ma l'rpm NVIDIA_GLX non dipende dalla versione del kernel e pertanto srpm non è necessario. Installare il pacchetto NVIDIA_GLX con rpm o con il file tar. __________________________________________________________________________ (sez-02) INSTALLAZIONE DEI PACCHETTI NVIDIA_KERNEL E NVIDIA_GLX __________________________________________________________________________ PRIMA DI INIZIARE L'INSTALLAZIONE DEL DRIVER Prima di iniziare l'installazione del driver, uscire del server X. Inoltre è possibile impostare il livello di funzionamento di default, per accedere alla console senza avviare X (consultare la documentazione inviata insieme alla diffusione Linux, se non si è sicuri su come procedere). Ciò renderà più semplice il ripristino, se durante l'installazione dovessero verificarsi problemi. Si noti, che i numeri di revisione dei pacchetti, sono stati omessi nelle seguenti istruzioni, per renderle il più generale possibile. Se le istruzioni riportano "NVIDIA_kernel.tar.gz" ciò dovrà essere sostituito con il nome della versione del driver che state installando; p.e.: "NVIDIA_kernel.0.9-6.tar.gz". INSTALLAZIONE ATTRAVERSO RPM Istruzioni brevi: $ rpm -ivh NVIDIA_kernel.i386.rpm $ rpm -ivh NVIDIA_GLX.i386.rpm Istruzioni: Prima di effettuare l'installazione da rpm, accertarsi di aver scaricato l'rpm NVIDIA-kernel adeguato per il proprio kernel. Dopo aver accertato di disporre del rpm, installare NVIDIA_kernel attraverso: $ rpm -ivh NVIDIA_kernel.i386.rpm Successivamente installare l'rpm NVIDIA_GLX, attraverso: $ rpm -ivh NVIDIA_GLX.i386.rpm AGGIORNAMENTO ATTRAVERSO RPM Istruzioni brevi: $ rpm -Uvh NVIDIA_kernel.i386.rpm $ rpm -e NVIDIA_GLX $ rpm -ivh NVIDIA_GLX.i386.rpm Istruzioni: Prima di effettuare l'aggiornamento da rpm, accertarsi di aver scaricato l'rpm NVIDIA-kernel adeguato per il proprio kernel. Dopo aver accertato di disporre del rpm adeguato, installare NVIDIA_kernel attraverso il pacchetto, effettuando: $ rpm -Uvh NVIDIA_kernel.i386.rpm Non è possibile utilizzare l'opzione '-U' di rpm, per aggiornare l'rpm NVIDIA_GLX, in quanto un'imperfezione della sezione disinstallazione degli rpm NVIDIA più vecchi,potrebbe rimuovere alcuni file, che non devono essere rimossi. Utilizzare invece '-e' per eliminare gli rpm NVIDIA_GLX vecchi e poi installare quelli nuovi: $ rpm -e NVIDIA_GLX $ rpm -ivh NVIDIA_GLX.i386.rpm INSTALLAZIONE/AGGIORNAMENTO ATTRAVERSO SRPM Istruzioni brevi: $ rpm --rebuild NVIDIA_kernel.src.rpm $ rpm -ivh /path/to/rpms/RPMS/i386/NVIDIA_kernel.i386.rpm $ rpm -ivh NVIDIA_GLX.i386.rpm Istruzioni: Per costruire un rpm NVIDIA-kernel, su misura per il proprio sistema, utilizzare per rpm l'indicatore '--rebuild' (ricostruzione) $ rpm --rebuild NVIDIA_kernel.src.rpm Trovare la riga simile (il percorso può essere diverso): Scrivere: /usr/src/redhat/RPMS/i386/NVIDIA_kernel.i386.rpm ed utilizzare quanto detto come input per rpm, per installare: $ rpm -ivh /usr/src/redhat/RPMS/i386/NVIDIA_kernel.i386.rpm od aggiornare: $ rpm -Uvh /usr/src/redhat/RPMS/i386/NVIDIA_kernel.i386.rpm per l'X driver e le biblioteche OpenGL del pacchetto NVIDIA_GLX (per installare od aggiornare NVIDIA_GLX da rpm). INSTALLAZIONE/AGGIORNAMENTO ATTRAVERSO FILE TAR Istruzioni brevi: $ tar xvzf NVIDIA_kernel.tar.gz $ tar xvzf NVIDIA_kernel.tar.gz $ cd NVIDIA_kernel $ make install (installa) $ cd ../NVIDIA_GLX $ make install (installa) Istruzioni: Per installare dal file tar, disimpacchettare ogni file: $ tar xvzf NVIDIA_kernel.tar.gz $ tar xvzf NVIDIA_kernel.tar.gz cd nella cartella NVIDIA_kernel. Immettere 'make install' (installa) Ciò renderà compatibile l'interfaccia kernel con l'Nvdriver, collegherà Nvdriver, copierà Nvdriver al posto giusto e tenterà di inserire Nvdriver nel kernel funzionante: $ cd NVIDIA_kernel $ make install (installa) Spostarsi alla cartella NVIDIA_GLX. Immettere 'make install' (installa)ciò copierà i file OpenGL e Xfree al posto giusto: $ cd ../NVIDIA_GLX $ make install (installa) Si noti, che 'installa', per ogni pacchetto, rimuoverà ogni precedente driver NVIDIA installato. __________________________________________________________________________ (sez-03) EDITAZIONE DEL PROPRIO 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 (file di config utilizzato):" nel file log XF86CONFIG ("/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 diversi modi per iniziare: 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/). Può essere utilizzato anche un programma come 'xf86config'; alcune diffusioni forniscono uno strumento proprio 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'), basta trovare la pertinente sezione del dispositivo e sostituire la rig: Driver "nv" con Driver "nvidia" Nella sezione modulo, accertarsi di avere: Load (carica) "glx" Dovranno essere eliminate anche le seguenti righe: Load (carica) "dri" Load 8carica) "GLcore" se esistono. Possono essere aggiunte diverse opzioni al file XF86Config, per adattare con precisione 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 ed iniziare ad utilizzare le biblioteche OpenGL accelerate. Dopo aver riavviato X, è possibile far funzionare qualsiasi applicazione OpenGL e saranno automaticamente utilizzate le nuove biblioteche NVIDIA. In caso di problemi, consultare la sezione ricerca ed eliminazione di guasti, qui sotto. __________________________________________________________________________ (sez-04) RICERCA ED ELIMINAZIONE DI GUASTI __________________________________________________________________________ Qui sotto sono elencate alcune strategie da ricordare in caso di problemi con NVIDIA Accelerated Linux Driver Set: o 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 (p.e. 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'; cercando: "(II) LoadModule: "nvidia"", e righe del driver che iniziano con: "(II) NVIDIA(0)". o Di default, il driver NVIDIA X produce relativamente pochi messaggi per stderr ed per il file log XFree86. Se è necessario risolvere un problema, può essere utile, abilitare un'uscita più verbosa, utilizzando le opzioni riga di comando "-verbose" (verboso) e "-logverbose", che possono essere utilizzate per impostare, rispettivamente, il livello di verbosità dei messaggi stderr , e file log. Il driver NVIDIA X emetterà più messaggi quando il livello di verbosità è uguale o superiore a 5 (l'impostazione default 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'. o Non funzionerà nulla, se il modulo kernel Nvdriver non funziona adeguatamente. Se nel file X log si riscontra qualcosa come "(EE) NVIDIA(0): Failed to initialize the NVdriver kernel module!"(mancata inizializzazione del modulo kernel Nvdriver), probabilmente esiste un problema relativo al modulo kernel Nvdriver). Per prima cosa,se l'installazione è stata effettuata da rpm, verificare che 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 X server prima di installare un nuovo modulo kernel). Se si riscontrano errori in relazione a simboli, non risolti, probabilmente, il modulo kernel è stato costruito utilizzando un file iniziale per una revisione kernel,diversa da quella utilizzata. E'specificatamente possibile verificare quali file kernel iniziale sono stati utilizzati, costruendo l'Nvdriver dal file tar NVIDIA_kernel, attraverso: 'make install SYSINCLUDE=/path/to/kernel/headers' (installa SYSINCLUDE=/percorso/a/kernel/iniziali). Si noti, che per consuetudine, la posizione dei file kernel iniziali, si trova in uno stato di transizione, 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). cd'ing nella cartella con il nuovo modulo kernel ed effettuare 'insmod ./NVdriver' potrebbe essere di aiuto. Nvdriver potrebbe anche produrre messaggi di errore che indicano un problema-- per visualizzare questi messaggi, scegliere /var/log/messages /var/log/messaggi, o la direzione di syslog per il posizionamento di messaggi kernel. o Se X si avvia, ma OpenGL dovesse causare problemi, presumibilmente esiste un problema relativo ad altre biblioteche o si tratta di symlinks non più attuali. Consultare l'appendice C, per avere dettagli. A volte basta ritornare a 'ldconfig'. o 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 o non è in grado di caricare completamente Glcore. Verificare il file XF86Config ed accertarsi di caricare glx (vedi "editazione del file XF86Config" qui sopra. Se il file XF86Config è quello giusto, controllare il file log Xfree86 per ricercare errori riguardanti GLX. Controllare anche che tutti i symlinks necessari siano a posto (consultare l'appendice C). o Se state tentando di installare/aggiornare da srpm ed il commando: rpm -rebuild (ricostruire) NVIDIA_kernel-1.0-2313.src.rpm stampa solo un elenco di opzioni di riga di comando rpm, probabilmente non è stato installato il pacchetto sviluppo rpm. Nella maggior parte delle situazioni questo problema può essere risolto, installando il pacchetto rpm-svil relativo alla propria diffusione. In alternativa, l'installazione/aggiornamento, può avvenire attraverso il file tar, in quanto i file tar, non richiedono rpm. o Se state tentando di installare/aggiornare da srpm ed il commando: rpm -rebuild (ricostruire) NVIDIA_kernel-1.0-2313.src.rpm' riporta un errore di: ' NVIDIA_kernel-.src.rpm:no such file or directory (nessun file o cartella simili) è necessario installare il pacchetto rpm-build relativo alla propria diffusione. In alternativa, l'installazione/aggiornamento, può avvenire attraverso il file tar, in quanto i file tar, non richiedono rpm. o Se installando NVIDIA_kernel, il modulo dà un messaggio del tipo: #(errore i moduli non utilizzano mai headers di sistema headers kernel) Modules should never use kernel-headers system headers #error but headers from an appropriate kernel-source (errore ma headers di una fonte kernel appropriata è necessario installare la fonte relativa al kernel Linux. Nella maggior parte delle situazioni, questo problema può essere risolto, installando il pacchetto sorgente kernel relativo alla propria diffusione. o Se le apps OpenGL danno il seguente messaggio: Error (errore): Could not open /dev/nvidiactl because the permissions are too restrictive (non è possible aprire /dev/nvidiaactl perchè i permessi sono troppo restrittivi). Consultare la sezione ricerca ed eliminazione di guasti di /usr/share/doc/NVIDIA_GLX-1.0/README, in relazione ai punti da correggere. E' probabile che un modulo di protezione del sistema PAM cambi i permessi dei file periferica NVIDIA. Nella maggior parte dei casi questo sistema di protezione funziona, ma può esserci confusione. Per correggere questo problema, si raccomanda di disattivare questa configurazione di protezione. Le diverse diffusioni Linux, hanno file diversi per controllare se il sistema dispone del file /etc/security/console.perms (etc/protezione/console.perms occorre editare il file e rimuovere la riga che inizia con "". Se invece il sistema dispone del file /etc/logindevperms occorre editare il file e rimuovere la riga che elenca /dev/nvidiactl. I passi citati, prevengono che il sistema di protezione PAM modifichi i permessi dei file periferica NVIDIA. Successivamente, i permessi dei file periferica dovranno essere resettati allo stato di permesso e proprietario originale. Ciò può essere effettuato attraverso i seguenti comandi: chmod 0666 /dev/nvidia* chown root /dev/nvidia* o Se le apps OpenGL subiscono un blocco e danno il seguente messaggio: WARNING (AVVISO): Your system is running with a buggy dynamic loader (il sistema sta funzionando con un caricatore dinamico infestato. Ciò può provocare il blocco di alcune applicazioni. Se si riscontrano blocchi, si può tentare di impostare la variabile ambiente __GL_SINGLE_THREADED. Per ulteriori informazioni, consultare (sez-04) RICERCA ED ELIMINAZIONE DI GUASTI nel file /usr/share/doc/NVIDIA_GLX-1.0/README. Il caricatore dinamico del sistema è infestato, cosa che bloccherà diverse volte le applicazioni collegate con pthreads e dlopen() libGL. Questo bug si trova in versioni più vecchie del caricatore dinamico. Le diffusioni, inviate con questo caricatore, comprendono, ma non solo, RedHat Linux 6.2 e Mandrake Linux 7.1. Se l'applicazione che si blocca, è a filone semplice, l'impostazione della variabile ambientale __GL_SINGLE_THREADED, su un valore qualsiasi, eviterà il blocco. Immettere in bash shell export __GL_SINGLE_THREADED ed in cash e derivati, utilizzare setenv __GL_SINGLE_THREADED Versioni precedenti di NVIDIA Accelerated Linux Driver Set tentano di risolvere questo problema, ma ciò causa problemi con altre applicazioni; è stato eliminato dopo la versione 1.0-1541. o Se Quake3 si blocca, cambiando i modi video, probabilmente si tratta del problema descritto qui sopra. Controllare l'uscita testo in relazione al messaggio "AVVISO", descritto. Impostare __GL_SINGLE_THREADED come descritto qui sopra, prima di far funzionare Quake 3, risolverà il problema. __________________________________________________________________________ (sez-05) DOMANDE FREQUENTI __________________________________________________________________________ D: L'avvio di X fallisce ed il file log Xfree86 contiene: (II) LoadModule (caricare modulo): "nvidia" (II) Loading /usr/X11R6/lib/modules/drivers/nvidia_drv.o No symbols found in this module (nessun simbolo trovato in questo modulo) (EE) Failed to load (non carica) /usr/X11R6/lib/modules/drivers/nvidia_drv.o (II) UnloadModule (modulo unload): "nvidia" (EE) Failed to load module (non carica modulo) "nvidia" (loader failed, 256 )caricamento fallito, 256)) ... (EE) No drivers available (nessun driver disponibile). R: Il dtiver X nvidia_drv.o non contiene più i simboli necessari; alcune versioni di rpm (erroneamente), eliminano i file oggetto, durante l'installazione. Probabilmente dovrà essere aggiornata la versione di rpm. O può essere installato il pacchetto NVIDIA_GLX dal file tar. D: Il sistema funziona, ma sembra instabile. Che cosa non va? R: E'possibile che venga usato il modulo AGP sbagliato. Consultare l'appendice E, per avere dettagli sulla configurazione AGP. D: Il modulo kernel non viene caricato dinamicamente all'avvio di X; occorre sempre eseguire prima 'modprobe NVdriver'. Che cosa non va? 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 diffusione, per avere dettagli. D: Non è possibile costruire il modulo kernel Nvdriver, o è possibile costruirlo, ma modprobe/ismod non carica il modulo nel nucleo. Che cosa non va? R: Questo problema, generalmente, è causato utilizzando nella costruzione, i file header kernel sbagliati (p.e. per una diversa versione del kernel, di quella che sta funzionando. Convenzionalmente i file header kernel vengono memorizzati in "/usr/include/linux/", ma ciò è stato abbandonato a favore di "/lib/modules/`uname -r`/build/include". Il Makefile NVIDIA_kernel è in grado di determinare la posizione nel sistema utilizzato; comunque se si riscontrano problemi, è possibile forzare la costruzione ad utilizzare alcuni file header, utilizzando: 'make install SYSINCLUDE=/path/to/kernel/headers' (installa SYSINCLUDE=/percorso/a/kernel/iniziali). ovviamente, per ognuna di queste azioni, è necessario disporre del file header kernel appropriato per il sistema. Consultare la documentazione inviata insieme alla diffusione; alcune diffusioni non installano i file header kernel di default, od installano headers che non sono adeguatamente compatibili con il kernel utilizzato. D: Perché le applicazioni OpenGL sono così lente? R: Probabilmente l'applicazione sta utilizzando una biblioteca diversa, del sistema, invece della biblioteca fornita da NVIDIA con OpenGL. Consultare l'APPENDICE C, per i dettagli. D: Il funzionamento di Quake2 crea problemi R: Quake2 richiede un'impostazione minore per il funzionamento. Nella cartella Quake2 l'installazione crea un symlink, chiamato libGL.so, che indica libMesaGL.so. Questo symlink può essere rimosso o rinominato. Poi, per far funzionare Quake2 in modo OpenGL, immettere: 'quake2 +set vid_ref glx +set gl_driver libGL.so'. Sembra che Quake2 non supporti nessun tipo di modo a schermo intero, ma l'X server può funzionare con qualsiasi risoluzione con cui funziona Quake2, per emulare il modo a schermo intero. D: Il funzionamento di Heretic II crea problemi. R: Heretic II, di default, installa un symlink chiamato libGL.so, nella cartella applicazioni. Questo symlink può essere rimosso o rinominato, in quanto il sistema troverà libGL.so di default (che i nostri driver installano in /usr/lib). Da Heretic II è poi possibile impostare il modo di resa in OpenGL, nel menù video. E'disponibile anche un percorso verso Heretic II da logikgame attraverso: http://www.lokigames.com/products (prodotti)/heretic2/updates (aggiornamenti).php3 D: Dove posso ottenere gl.h or glx.h per compilare programmi OpenGL? R: Nella maggior parte dei sistemi queste headers sono preinstallate. Comunque NVIDIA fornisce il proprio file gl.h e glx.h, nel caso in cui il sistema non dovesse contenerlo, o per il caso in cui si desiderasse sviluppare gli apss OpenGL che utilizzano le nuove estensioni OpenGL NVIDIA. Questi file sono stati installati in /usr/share/doc/NVIDIA_GLX-1.0/usr/include(comprendi)/GL, per evitare conflitto fra le versioni installate nel sistema. Per utilizzare queste headers, copiarle in /usr/include/GL. D: E'possibile ricevere via e-mail comunicati su NVIDIA Accelerated Linux Driver Set? R: Si. 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 causa rallentamenti. In genere, l'uso di due software driver indipendenti per lo stesso hardware, non è una buona scelta. D: Compilando il modulo kernel Nvdriver, appare il seguente errore: Si sta tentando di compilare il modulo kernel Nvdriver con un compilatore diverso da quello utilizzato per compilare il kernel funzionante. Ciò può essere giusto, ma in alcuni casi può causare un funzionamento inaspettato ed il blocco del sistema. Se si è sicuri di quello che si sta facendo e si vuole saltare questo controllo, ciò può essere effettuato impostando IGNORE_CC_MISMATCH. In ogni altro caso, impostare la variabile ambiente CC sul nome del compilatore utilizzato per compilare il 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 gcc 3.x viene utilizzato quando i file aperti in Nvdriver sono costruiti (o viceversa), la dimensione di rwlock_t varierà e cose del tipo di ioremap falliranno. 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: X fallisce con errore "mancata allocazione di LUT context DMA" R: Questa è una delle possibili conseguenze della compilazione di Nvdriver con una versione diversa di quella utilizzata per compilare il kernel Linux. (vedi sopra). D: Non sono disponibili RMP NVIDIA_kernel per versione N di (inserire qui la distr. favorita). Tento di installare RPM per versione N-1, ma non funziona. Cosa è possibile fare? R: Come spiegato in (sez-01) SCELTA DEI PACCHETTI NVIDIA ADATTI AL SISTEMA "se un rpm NVIDIA-kernel specifico non è disponibile per la vostra distribuzione occorre utilizzare srpm NVIDIA_kernel od il file tar D: Durante l'installazione del pacchetto NVIDIA_GLX compare: --- The above file(s) possibly belong to a conflicting MESA rpm (Il (i) file soprastanti, probabilmente appartengono ad un rpm MESA). --- They have been renamed to xxx..RPMSAVE to (sono stati rinominati in....) --- avoid conflicting with the files contained within this --- package (evitare conflitto con i file contenuti in questo pacchetto). --- please consult 8consultare) /usr/share/doc/NVIDIA_GLX-1.0/README --- "(sec-05) FREQUENTLY ASKED QUESTIONS" for more details (sez-05) DOMANDE FREQUENTI per maggiori dettagli). Che cosa non va? R: In base a questo messaggio, i file in conflitto sono stati eliminati, per garantire che le applicazioni possano trovare le nuove biblioteche OpenGL installate. Non c'è pericolo, il messaggio viene dato solo per informazione. Se si disinstalla il pacchetto NVIDIA_GLX, i file originali saranno reintegrati automaticamente. __________________________________________________________________________ (sez-06) CONTATTARCI __________________________________________________________________________ Esiste un nuovo web forum per i problemi relativi a NVIDIA Linux driver! L'URL è: http://www.nvnews.net/cgi-bin/ultimatebb.cgi?ubb=forum&f=29 Questo è lo strumento preferenziale per richiedere aiuto; gli utenti possono fare domande, rispondere alle domande di altri utenti e consultare gli archivi di emissioni 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 ricerca ed eliminazione di guasti di questo file LEGGIMI e dopo aver chiesto aiuto al nv.new web forum. __________________________________________________________________________ (sez-07) ULTERIORI RISORSE __________________________________________________________________________ Linux OpenGL ABI http://oss.sgi.com/projects/ogl-sample/ABI/ NVIDIA Linux HowTo http://www.linuxdoc.org/HOWTO/mini/Nvidia-OpenGL-Configuration/index.html OpenGL www.opengl.org Il progetto XFree www.xfree86.org #nvidia (irc.openprojects.net) __________________________________________________________________________ (app-a) APPENDICE A: CHIP GRAFICI NVIDIA SUPPORTATI __________________________________________________________________________ NOME CHIP NVIDIA ID PERIFERICA PC o RIVA TNT 0x0020 o RIVA TNT2 0x0028 o RIVA TNT2 (Ultra) 0x0029 o RIVA TNT2 (Vanta) 0x002C o RIVA TNT2 (M64) 0x002D o RIVA TNT2 (Integrato) 0x00A0 o GeForce 256 0x0100 o GeForce DDR 0x0101 o Quadro 0x0103 o GeForce2 MX 0x0110 o GeForce2 MX 400 0x0110 o GeForce2 MX 200 0x0111 o GeForce2 MX 100 0x0111 o GeForce2 Go 0x0112 o GeForce2 MXR 0x0113 o Quadro2 Go 0x0113 o GeForce2 Pro 0x0150 o GeForce2 GTS 0x0150 o GeForce2 GTS 0x0151 o GeForce2 Ti 0x0151 o GeForce2 Ultra 0x0152 o Quadro2 Pro 0x0153 o Quadro2 Ex 0x0153 o GeForce3 0x0200 o GeForce3 Ti 200 0x0201 o GeForce3 Ti 500 0x0202 o Quadro DDC 0x0203 Si noti che i chip RIVA 128/128ZX sono supportati dall'open source 'nv' driver di Xfree86, ma non da NVIDIA Accelerated Linux Driver Set. Per verificare gli ID delle periferiche PC, per confrontarli con la tabella soprastante, è possibile utilizzare `cat /proc/pci` o `lspci -n`; nei casi seguenti, cercare la periferica con id "10de", p.e.: 02:00.0 Classe 0300:10de:0100 (vers 10) __________________________________________________________________________ (app-b) APPENDICE B: REQUISITI SOFTWARE MINIMI __________________________________________________________________________ cat /proc/version o XFree86 4.0.1 # XFree86 -version o Kernel modutils 2.1.121 # insmod -V Per costruire il modulo kernel NVdriver: o binutils 2.9.5 # size --version o GNU make 3.77 # make --version o gcc 2.7.2.3 # 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, né nuclei della serie sviluppo, come 2.3.x o 2.5.x. Il kernel Linux può essere rilevato da www.kernel.org o da uno dei suoi specchi. Binutils e gcc sono necessari solo se si installa il pacchetto NVIDIA_kernel attraverso srpm od il file tar e possono essere trovati attraverso www.gnu.org o attraverso uno dei suoi specchi. Nota: binutils e gcc non sono necessari per l'installazione di RPM binari. 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 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 biblioteca OpenGL(/usr/lib/libGL.so.x.y.z); questa biblioteca offre i punti di inserimento API per tutti i richiami delle funzioni OpenGL e GLX. E'collegata con il tempo di esecuzione attraverso applicazioni OpenGL. o Una biblioteca OpenGL centrale(/usr/lib/libGLcore.so.x.y.z); questa biblioteca è 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 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. L'NV driver è costituito da due parti: quella centrale, solo binaria un 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 consistente, 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 diffusioni linux. o File header OpenGL e GLX (/usr/share(condiviso)/doc/NVIDIA_GLX-1.0/usr/include(compreso)/GL/gl.h, /usr/share/doc/NVIDIA_GLX-1.0/usr/include/GL/glx.h). Nella maggior parte dei casi, gli header forniti dal sistema in /usr/include/GL sono sufficienti per lo sviluppo OpenGL. Ma NVIDIA ha fornito questi header perché contengono la maggior parte delle attuali versioni delle versioni OpenGL di NVIDIA. Se si desidera utilizzare questi header, è raccomandabile copiarle in /usr/include/GL/. I primi quattro componenti elencati sopra (XFree86 driver, GLX module, libGL, e libGLcore) sono compresi nel pacchetto NVIDIA_GLX. Il modulo kernel Nvdriver è compreso nel pacchetto NVIDIA_kernel. Anche la documentazione ed i file header OpenGL e GLX fanno parte del pacchetto NVIDIA_GLX e devono essere installati in /usr/share/doc/NVIDIA_GLX-1.0. Potrebbero manifestarsi problemi, se le applicazioni dovessero utilizzare la versione sbagliata di una biblioteca. Ciò può avvenire, nel caso in cui biblioteche libGL vecchie o symlink superati, rimanessero in giro. Se pensate che nell'installazione ci sia qualcosa di sbagliato, occorre verificare che i seguenti file siano a posto (questi sono tutti i file di NVIDIA Accelerated Linux Driver Set, più i loro symlink): /usr/X11R6/lib/modules/drivers/nvidia_drv.o /usr/X11/lib/modules/extensions/libglx.so.x.y.z /usr/X11/lib/modules/extensions/libglx.so -> libglx.so.x.y.z /usr/lib/libGL.so.x.y.z /usr/lib/libGL.so.x -> libGL.so.x.y.z /usr/lib/libGL.so -> libGL.so.x /usr/lib/libGLcore.so.x.y.z /usr/lib/libGLcore.so.x -> libGLcore.so.x.y.z /lib/modules/`uname -r`/video/NVdriver, or /lib/modules/`uname -r`/kernel/drivers/video/NVdriver L'installazione del pacchetto NVIDIA_kernel, creerà 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 biblioteche, il cui "nome so" è in conflitto con quello delle biblioteche NVIDIA, ldconfig potrebbe creare i symlinks sbagliati. Si raccomanda di rimuovere manualmente o di rinominare (accertarsi di non rinominare biblioteche in conflitto con qualcosa che ldconfig possa confondere-- abbiamo stabilito che anteporre "XXX" al nome di una biblioteca, generalmente funziona) le biblioteche in conflitto, rieseguire 'ldconfig' e controllare che vengano effettuati i symlink corretti. Alcune biblioteche che spesso creano conflitti sono "/usr/X11R6/lib/libGL.so*" e "/usr/X11R6/lib/libGLcore.so*". Dopo aver controllato le biblioteche, verificare che l'applicazione stia utilizzando le biblioteche corrette. Per esempio, per controllare se l'applicazione /usr/X11R6/bin/gears sta utilizzando le biblioteche 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 biblioteche NVIDIA, occorre rimuovere i queste biblioteche o sistemare il percorso ricerca ld. Se qualcosa di ciò non vi è famigliare, occorre leggere le pagine principali relative a "ldconfig" e "ldd" per gli indicatori. __________________________________________________________________________ (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 8tentare con AGPGART, poi con AGP NVIDIA) Si noti che il supporto AGP interno non può funzionare, se AGPGART è compilato staticamente nel kernel, o se è costruito come modulo, ma caricato nel kernel (alcune distribuzioni caricano AGPGART nel kernel all'avvio). Default: 3 (default era 1 fino successivamente a 1.0-1251). Opzione "NoLogo" "boolean" Disabilitare il disegno della schermata a macchia del logo NVIDIA all'avvio di X. Default: il logo viene disegnato. Opzione "NoRenderAccel" "boolean" Abilitare o disabilitare l'accelerazione hardware dell'estensione RENDER (Resa) Default: Accelerazione di RENDER, se possibile. Opzione "UBB" "boolean" Abilita o disabilita Unified Back Buffer sui chipset di Quadro; consultare l' appendice M per avere una descrizione di UBB. Questa opzione non interessa i chipset diversi di quelli di Quadro. Default: BB abilitato per i chipset di Quadro. Opzione "WindowFlip" "boolean" Abilita o disabilita window flipping con UBB abilitato; consultare l' appendice M per avere una descrizione. Quando UBB è disabilitato, ciò non ha effetto. Può aumentare la performance in relazione alle applicazioni 3D. Default: Window flipping abilitato, con UBB abilitato. Opzione"PageFlip" "boolean" Abilita o disabilita page flipping; consultare l' appendice M per avere una descrizione dettagliata. Default: Page flipping abilitato. Opzione "SWCursor" "boolean" Abilita o disabilita la resa software del cursore X. Default: disabilitato. Opzione "HWCursor" "boolean" Abilita o disabilita la resa hardware del cursore X. Default: 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 (p.e.chipset GeForce2 MX (200/400), GeForce2 Pro, GeForce 2 Ultra, GeForce2 Go, GeForce3, Quadro, Quadro DDC, Quadro2 (MXR/EX), Quadro2 Pro e Quadro2 Go). Default: 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] 55 è completamente opaco. Default: 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]: default: 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]. Default: 2. Opzione "ConnectedMonitor" "string" Consente di saltare ciò che il modulo kernel NVIDIA rileva, se collegato alla scheda video. Ciò può essere utile, p.e. 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. Se si utilizza uno schermo piatto digitale invece di un CRT, questa opzione viene utilizzata per comunicare espressamente al driver NVIDIA, ciò che è collegato. 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; p.e.: "CRT, CRT" o "CRT, DFP". Default: 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 un EDID, 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 i modi richieste contro i valori rilevati dagli EDID monitor (se disponibili), durante la validazione del modo. Alcuni monitor sono noti perché mentono sulle proprie capacità. Ignorare i valori che il monitor offre, può essere utile per validare un determinato modo. D'altra parte, ciò può essere pericoloso se non si sa esattamente quello che si sta facendo. Default: utilizzo di EDID. Opzione "NoDDC" "boolean" Sinonimo di "IgnoreEDID" Opzione "FlatPanelScalingMode" "string (stringa)" Richiede un modo di scalatura specifico per schermo piatto; "string" può essere "centrato" o "scalato". Se è "centrato", ogni schermo piatto collegato sarà configurato per centrare il contenuto dello schermo (p.e.: l'impostazione di modo 800x600 su di uno schermo piatto, con risoluzione nativa di 1400x1050, avrà come risultato pixel centrati 800x600 sullo schermo piatto usato, con un bordo nero di contorno). Se l'impostazione è "Scalato", il contenuto dello schermo sarà scalato per utilizzare tutto lo schermo dello schermo piatto. 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 . NVdriver. Default: disabilitato (POSTing viene effettuato attraverso il modulo kernel Nvdriver). Opzione "TwinView" "boolean" Abilita o disabilita TwinView. Consultare l'appendice I per i dettagli. Default: TwinView disabilitato. Opzione "TwinViewOrientation" "string" Controlla la relazione fra le due periferiche di visualizzazione quando si utilizza TwinView. Ha uno dei seguenti valori: "RightOf"(destraOf) "LeftOf"(sinistraOf) "Above(sopra)" "Below"(sotto) "Clone"(clona). Consultare l'APPENDICE I, per i dettagli. Default: stinga VUOTA. Opzione "SecondMonitorHorizSync" "range(s)"(ambito-I) 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. Default: 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. Default: nulla. Opzione "MetaModes" "string" Questa opzione descrive la combinazione del modo da utilizzare per ogni monitor, quando si utilizza TwinView. Consultare l'appendice I per i dettagli. Default: stinga VUOTA. __________________________________________________________________________ (app-e) APPENDICE E: IMPOSTAZIONI VARIABILI AMBIENTE OPENGL __________________________________________________________________________ ANTI-ALIASING A TUTTA SCENA 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 compare. Anti-aliasing a tutta scena è supportato dalle seguenti GPU: chip set GeForce2 MX, GeForce 256, GeForce2 Pro, GeForce2 GTS, GeForce 2 Ultra, GeForce3, Quadro, Quadro2 MXR, Quadro2 Pro e Quadro2 Go. 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. Descrizione__GL_FSAA_MODE GeForce/GeForce2/Quadro Description GeForce3 Description ----------------------------------------------------------------------- 0 FSAA disabilitato FSAA disabilitato 1 FSAA disabilitato 2 x 2 sovracampionamento con texture LOD bias 2 FSAA disabilitato 2 x 2 Quiconx 3 1.5 x 1.5 sovracampionamento FSAA disabilitato 4 2 x 2 sovracampionamento con 4 x 4 bilineare no texture LOD bias 5 FSAA disabilitato 4 x 4 Guassian VBLANK SYNCING L'impostazione della variabile ambiente__GL_SYNC_TO_VBLANK su di un valore diverso da zero forzerà glXSwapBuffers a sincronizzarsi con la refresh rate verticale del monitor (effettuare uno swap solo durante il periodo di azzeramento verticale) di GeForce e non con il hardware (p.e.: qualsiasi cosa, ma prodotti TNT/TNT2). __________________________________________________________________________ (app-f) APPENDICE F: CONFIGURAZINE 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 Default è 3 ( default era 1 fino a successivamente a 1.0-1251). E'possibile utilizzare il modulo AGP, che funziona meglio con il chipset AGP disponibile. Se si riscontrano problemi con la stabilità, occorre eseguire l'avvio, disabilitando AGP, controllando se così si risolve il problema. E'poi possibile sperimentare uno o l'altro dei moduli AGP. Lo stato di AGP, può essere verificato attraverso: `cat /proc/nv/card0`. 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. E'consigliabile compilare AGPGART come modulo ed accertare che non sia caricato quando si tenta di utilizzare AGP NVIDIA. Occorre anche tener presente che la sostituzione di driver AGP, in genere richiede una reinizializzazione, prima che le modifiche siano effettivamente efficaci. 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 840 ("Carmel") o Intel 845 ("Brookdale") o Intel 850 ("Tehama") o Intel 860 ("Colusa") o AMD 751 ("Irongate") o AMD 761 ("IGD4") o AMD 762 ("IGD4 MP") o VIA 8371 o VIA 82C694X o VIA KT133 o RCC 6585HE o Micron SAMDDR ("Samurai") o Micron SCIDDR ("Scimitar") o nForce AGP Su schede madre Athlon con chipset VIA KX133 o 694X, come la scheda madre ASUS K7V, utilizza di default NVIDIA driver per il modo AGP 2x, per lavorare intorno a punti di forza insufficienti dell'unità, di uno dei due segnali. E'possibile forzare AGP 4x, abilitando NVreg_EnableVia4x in os-registry.c e ricostruendo il modulo kernel NVIDIA. Si noti, che questo potrebbe rendere instabile il driver. 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. Ciò può forzare AGP ad abilitarsi per questi chipset, abilitando NVreg_EnableALiAGP in os-registry.c e ricostruendo il modulo kernel NVIDIA. Si noti, che ciò potrebbe rendere instabile il driver. __________________________________________________________________________ (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 di default, 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 __________________________________________________________________________ (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 Procurarsi il più recente file tar NVIDIA_kernel 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). o 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"(fare)) __________________________________________________________________________ (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 e Quadro2 Go. Verificare con il venditore della scheda video, che TwinView sia supportato dalla scheda. TwinView è un modo operativo, in cui due periferiche di visualizzazione (schermi piatti digitali, CRT e TV) possono visualizzare il contenuto di un'unica schermata X 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 (p.e. OpenGL accelerate), sono disponibili per TwinView. o Non sono necessarie informazioni addizionali per emulare un desktop singolo. OPZIONI XF86CONFIG TWINVIEW per abilitare TwinView, occorre specificare le seguenti opzioni nella sezione schermo del file XF86Config: Opzione "TwinView" Opzione "SecondMonitorHorizSync" "range(s)"(ambito-i) Opzione "SecondMonitorVertRefresh" "" Opzione "MetaModes" " (elenco metamodes)" E'inoltre possibile utilizzare una delle seguenti opzioni,sebbene non siano necessarie: Opzione "TwinViewOrientation" "(relazione da titolo 1 a titolo 0 " Opzione "MetaModes" " (elenco metamodes)" 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 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 MetaModes Un MetaMode singolo descrive quale modo utilizzare per una periferica di visualizzazione in un determinato momento. MetaModes multiplo elenca le combinazioni del modo e la sequenza in cui devono essere utilizzati. Quando il driver NVIDIA comunica a X, quali modi sono disponibili, nel file XF86Config, viene data una dimensione schermo, virtuale. Quando per un MetaMode non viene dato nessun offset, questo sarà calcolato, seguendo il valore dell'opzione TwinViewOrientation (vedi sotto). Si noti, che quando gli offsets sono dati per uno dei modi in MetaMode singolo, gli offeset saranno richiesti da tutti i modi compresi nel Metamode singolo; si presume offset +0+0, se non sono dati. Se non esplicitamente data, la misura dello schermo virtuale, sarà calcolata come il bounding box di tutti i bounding box MetaMode. MetaMode con bounding box superiori ad una dimensione di schermo virtuale, esplicitamente data, saranno eliminati . Una stringa MetaMode può essere ulteriormente modificata attraverso una specificazione "Panning Domain", p.e.: "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 bounding box del MetaMode. Quando il mouse lascia il bounding box del MetaMode, il MetaMode completo (p.e. tutte le periferiche di visualizzazione), sarà mosso per seguire il mouse sullo schermo virtuale. Si noti che i panning domains delle periferiche di visualizzazione individuali, di default, sono chiusi nella posizione delle viewport delle periferiche di visualizzazione, così il comportamento di default è soltanto quello mantenere "bloccate" le vieport 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 offeset possono essere utilizzati insieme al panning domain per posizionare i panning domain negli spazi dello schermo virtuale (nota che l'offset descrive il panning domain ed interessa la viewport unicamente per ciò che concerne la viewport compresa entro il panning domain). Per esempio, di seguito vengono descritti due modi, 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à i modi elencati nella sottosezione "display", tentando di piazzare li modi corrispondenti su ogni periferica di visualizzazione. o Orientamento TwinView Questa opzione controlla il posizionamento della seconda periferica di y visualizzazione, relativamente alla prima, all'interno dello schermo X virtuale, quando gli offset non sono esplicitamente dati in un MetaMode. i valori possibili sono: "RightOf" (default) "LeftOf" "Sopra" "Sotto" "Clona" quando è specificato "clona", ad entrambe le periferiche di visualizzazione sarà assegnato un offset 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; p.e.: "CRT, CRT" o "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. E'necessario informare espressamente il driver Xfree86 NVIDIA su ciò che è connesso, utilizzando l'opzione "ConnectedMonitor"(MonitorCollegati); p.e.: L'opzione "ConnectedMonitor" "CRT, CRT" D: La gestione finestre è in grado di disporre appropriatamente le finestre (p.e. evitando di sistemare le finestre attraverso entrambe le periferiche di visualizzazione o in zone inaccessibili del desktop virtuale)? R: Si. L'X driver NVIDIA fornisce un'estensione Xinerama, che consente agli X clients (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 di quando è necessaria 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. Un'altra soluzione è quella di utilizzare i panning domain, per eliminare zone inaccessibili dello schermo virtuale (vedi descrizione MetaMode qui sopra). D: Perché non è possibile ottenere una risoluzione di 1600x1200 sulla seconda periferica di visualizzazione? 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 i modi programmabili, consultare Video Timings HOWTO). 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 i modi richiesti sono stati validati e l'offset per ogni viewport MetaMode è stato calcolato, il driver NVIDIA calcolerà il bounding box del panning domain, per ogni MetaMode. Verranno poi determinate la larghezza e l'altezza massima del bounding box. 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 1600x1536. D: E'possibile giocare a schermo intero attraverso entrambe le periferiche di visualizzazione? R: Si. Mentre i dettagli di configurazione possono variare da gioco a gioco, l'idea di base è che un MetaMode presenti X con un modo la cui risoluzione sia il bounding box dei viewport di quel MetaMode. Per esempio: Opzione "MetaModes" "1024x768,1024x768; 800x600,800x600" Opzione "TwinViewOrientation" "RightOf" producono due modi: uno con risoluzione 2048x768 e l'altro con risoluzione 1600x600. Giochi come Quake 3 Arena, utilizzano l'estensione VidMode per scoprire le risoluzioni dei modi attualmente disponibili. Per configurare Quake 3 Arena per l'utilizzo della stringa MetaMode suddetta, aggiungere quanto segue al file q3config.cfg: 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 modo 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 (p.e. 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 modo della sezione schermo; gli unici modi validi per il televisore sono 640x480 and 800x600, è possibile 1024x768 se il codificatore TV della scheda video è un BrookTree 871 --- il file log Xfree86 segnalerà il codificatore disponibile (cercare la riga: "(--) NVIDIA(0): TV Encoder detected as")(codificatore TV rilevato come). 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 di default "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" (monitor collegato) "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" o Opzione "TVOutFormat" "COMPOSITE" __________________________________________________________________________ (app-k) APPENDICE K: CONFIGURAZIONE DI UN PORTATILE __________________________________________________________________________ INSTALLAZIONE E CONFIGURAZIONE L'installazione e la configurazione sono uguali a quelle di ogni ambiente desktop. Nella versione 1.0-1251 driver, agli utenti viene richiesto di inviare al modulo kernel Nvdriver, l'opzione "Nvreg_Mobile"; ciò può essere effettuato utilizzando il comando modprob: modprobe NVdriver NVreg_Mobile=X o aggiungendo quanto segue al file di configurazione del modulo kernel (generalmente /etc/conf.modules o /etc/modules.conf): opzioni NVdriver NVreg_Mobile=X Anche se l'opzione è stata specificata, deve essere assegnato il valore: "1" if utilizzando GeForce2 Go o Quadro2 Go in un portatile Dell "2" utilizzando GeForce2 Go o Quadro2 Go in un portatile Toshiba serie Satellite 2800. "4" utilizzando GeForce2 Go o Quadro2 Go in un portatile Toshiba serie Satellite 3000 "5" utilizzando GeForce2 Go o Quadro2 Go in un portatile Gateway Versioni successive a 1.0-1251 non necessitano più dell'opzione Nvreg_Mobile, anche se può essere utilizzata per saltare ciò che è stato rilevato. FUNZIONI AGGIUNTIVE TWINVIEW Sia GeForce2 Go che Quadro2 Go 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). E'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 portatili che utilizzano GeForce2 Go 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 sarà usata per ogni avvenimento hotkey. Quando si verifica un avvenimento hotkey, viene scelto lo stato hotkey successivo della sequenza. Ogni modo richiesto dal file XF86Config, viene validato nei confronti di ogni vincolo della periferica di visualizzazione ed il modo risultante è reso disponibile per quella periferica di visualizzazione. Se periferiche di visualizzazione multiple devono essere attive contemporaneamente, i modi di ognuna di queste vengono accoppiati insieme; se non è possibile trovare una corresponsione esatta (stessa risoluzione), viene trovata la corrispondenza più vicina ed avviene 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 sarà sempre ripristinata alla periferica di visualizzazione su cui si trovava, all'avvio di X. Similmente, quando si riesegue la commutazione vt verso X, verrà utilizzata la stessa configurazione della periferica di visualizzazione, di quando è stata effettuata la commutazione vt da X, senza considerare quale attività LCD/CRT hotkey era in corso durante la commutazione vt da X. MODI NON STANDARD SU DISPLAY LCD Alcuni utenti hanno riscontrato difficoltà nel programmare un modo 1400x1050 (la risoluzione nativa di alcuni LCD di portatili). Alla versione 4.0.3 di Xfree86 sono stati aggiunti diversi modi 1400x1050 al database di modi default, ma se si sta utilizzando una versione precedente di Xfree86, può essere utilizzata la seguente riga: # -- 1400x1050 -- # 1400x1050 @ 60Hz, 65.8 kHz hsync Modeline "1400x1050" 129 1400 1464 1656 1960 1050 1051 1054 1100 +HSync +VSync PROBLEMI NOTI RELATIVI A PORTATILI o Attualmente non è supportata la gestione potenze. o La commutazione LCD/CRT hotkey sui portatili Toshiba della serie Satellite 2800, attualmente non funziona. o Attualmente TwinView non funziona sui portatili Toshiba della serie Satellite 2800. Le sovrapposizioni video hardware lavorano solo sulla prima periferica di visualizzazione su cui è stato avviato X. P.e.,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. E'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: MODALITA' DI PROGRAMMAZIONE __________________________________________________________________________ NVIDIA Accelerated Linux Driver Set supporta tutti i modi standard VGA e VESA e la maggior parte delle righe preparate dall'utente; double-scan è supportato da ogni hardware e le modalità interfacciate sono supportate da: GeForce 256, GeForce DDR, Quadro, GeForce2 GTS/GeForce2 Pro, GeForce2 Ti, GeForce2 Ultra, Quadro2 Pro, e da tutti i prodotti TNT. In genere la periferica di visualizzazione (monitor/schermo piatto/televisione) sarà più vincolata al modo 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 "Modo", come: Modo "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 modo, 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 modo per Xfree86. Serve piuttosto per documentare XFree86 Video Timings HOWTO (che può essere trovato su www.linuxdoc.org). PROFONDITA', BITS PER PIXEL E PITCH Non interessando direttamente la programmazione di modi, i bit utilizzati per i pixel, sono un problema, se si considera la massima risoluzione programmabile; per questo motivo, è utile risolvere la confusione che esiste intorno ai termini "profondità" e "bits per pixel". Profondità è la quantità di bit per dati memorizzata per pixel. Profondità supportate sono 8, 15, 16 e 24. La maggior parte dei video hardware, memorizzano 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 una tabella dei valori bpp utilizzati per ogni possibile profondità: profondità bpp ===== ===== 8 8 15 16 16 16 24 32 "Pitch" è la quantità di byte nel frame buffer lineare, che si trova fra un dato pixel ed il dato pixel immediatamente sottostante. Si può pensare a ciò, come ad una risoluzione orizzontale moltiplicata per i byte per pixel (bit per pixel diviso 8). Praticamente, i pitch possono essere di più di quelli prodotti, in quanto l'hardware video spesso richiede che pitch sia un multiplo di alcuni valori. 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 dal modo programmato 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 importante relazione è quella fra la risoluzione, il ciclo pixel (aka 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 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 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`. XFree86.0.log può contenere diverse righe come: (--) NVIDIA(0): Periferica di visualizzazione 0: massimo ciclo pixel a 8 bpp: 350 MHz (--) NVIDIA(0): Periferica di visualizzazione 0: massimo ciclo pixel a 16 bpp: 350 MHz (--) NVIDIA(0): Periferica di visualizzazione 0: massimo ciclo pixel a 32 bpp: 300 MHz che indica il massimo ciclo pixel di ogni bit per dimensione pixel. VALIDAZIONE DEI MODI Durante la fase PreInit del server X server, il driver X NVIDIA convalida tutti i modi necessari, 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 i modi con i nomi specificati dall'utente nel file XF86Config, eliminando i modi 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 i modi restituiti da xf86ValidateModes() vengono poi esaminati per garantire che le risoluzioni non siano superiori a quella del modo massimo riportato dall'EDID monitor (ciò può essere disabilitato attraverso l'opzione"IgnoreEDID"). Se il display è un televisore, ogni modo viene controllato per garantire che abbia una risoluzione supportata dal codificatore TV (generalmente solo 800x600 e 640x480 sono supportate dal codificatore). o Tutti i restanti modi vengono controllati per garantire che superino i vincoli descritti qui sotto in VINCOLI MODO AGGIUNTIVI Gli ultimi due passi vengono effettuati anche quando viene programmato ogni modo, per rilevare modi potenzialmente non validi attraverso XF86VidModeExtension (eg xvidtune(1)). Per TwinView, la validazione soprastante viene effettuata per i modi richiesti per ogni periferica di visualizzazione. VINCOLI AGGIUNTIVI MODI Qui sotto si trova un elenco dei vincoli aggiuntivi relativi ai parametri di un modo che devono corrispondere. o La risoluzione orizzontale (HR) deve essere un multiplo di 4 ed inferiore od uguale a 2048. 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 4 ed inferiore o uguale a 1024. o Sync start orizzontale (HSS) deve essere un multiplo di 4 od inferiore od uguale a 4088. o L'ampiezza sync orizzontale (sync end orizzontale meno sync start orizzontale (HSE - HSS)) un multiplo di 4 od inferiore o uguale a 256. o La lunghezza frame orizzontale (HFL) deve essere un multiplo di 4 e ed inferiore o uguale a 40. o La risoluzione verticale (VR) deve essere inferiore o uguale a 2048. 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 inferiore o uguale a 128. Sync start verticale (VSS) deve essere inferiore o uguale a 2047. o L'ampiezza sync verticale (sync end verticale meno sync start verticale (Vse - VSS)) deve essere inferiore o uguale a 16. o La lunghezza frame verticale (VFL) deve essere inferiore o uguale a 2049 e superiore o uguale a 2. Qui un esempio di riga modo, che dimostra l'uso di ogni abbreviazione utilizzata sopra: # Riga modo utente per schermo piatto SGI 1600SW # nome PCLK HR HSS HSE HFL VR VSS VSE VFL Modeline "sgi1600x1024" 106.9 1600 1632 1656 1672 1024 1027 1030 1067 VEDI ANCHE: Un generatore modeline Xfree86, conformemente allo standard GTF è stato inviato alla mailing list Xfree86 Xpert: http://www.xfree86.org/pipermail/xpert/2001-October/012070.html Per ottenere ulteriori generatori modeline, si può tentare la ricerca per "medeline" su freshmeat.net. __________________________________________________________________________ (app-m) APPENDICE M: PAGE FLIPPING, WINDOW FLIPPING, ED UBB __________________________________________________________________________ Iniziando dalla versione driver 1.0-2313 Accelerated Linux Driver Set supporta Unified Back Buffer (UBB), Page Flipping, e Window Flipping. Queste caratteristiche sono in grado di offrire un aumento delle prestazioni in alcune situazioni. Qui una descrizione di ognuna: o Page Flipping: Questa caratteristica è disponibile per GeForce e per i hardware più recenti. /p.e.: non prodotti TNT/TNT2), ed è abilitata in caso di una applicazione OpenGL a schermo singolo, non oscurato, quando si sincronizza su blank. La sostituzione buffer avviene, sostituendo il buffer di cui DAC esegue la scansione, piuttosto che copiando i contenuti del back buffer al front buffer; ciò generalmente è un meccanismo di performance molto più elevato e consente la sostituzione senza discontinuità durante il ripercorso(quando __GL_SYNC_TO_VBLANK è impostato). Questa caratteristica può essere disabilitata attraverso l'opzione PageFlip XF86Config. o Back Buffer Unificato (UBB): UBB è disponibile solo su parti Quadro ed è abilitato di default, quando è disponibile sufficiente memoria video Può essere disabilitato attraverso l'opzione UBB XF86Config descritta in Appendice D. Quando UBB è abilitato, tutte le finestre condividono lo stesso back buffer, stencil buffer e depth buffer. Quando ci sono molte finestre, l'uso di back, stencil e depth non eccederà mai la dimensione di quella utilizzata per una finestra a pieno schermo. Comunque, per una finestra singola, piccola, l'uso di back, stencil e depth è quello di una finestra a pieno schermo, pertanto la ram video può essere utilizzata meno efficacemente che nel caso di UBB. o Window Flipping: Questa caratteristica richiede UBB, che è disponibile sulle parti Quadro. Quando c'è un'unica finestra OpenGL, questi window buffer possono essere sostituiti, cambiando il buffer di cui DAC esegue la scansione, piuttosto che copiando i contenuti del front buffer. Ciò è simile a Page Flipping, ma rimuove la restrizione della finestra oscurata ed a schermo pieno. Funziona solo nel caso di un'unica finestra OpenGL. Window Flipping è disabilitato di default e può essere abilitato attraverso l'opzione "WindowFlip" XF86Conf, descritta in APPENDICE D. __________________________________________________________________________ (app-n) APPENDICE N: PROBLEMI NOTI __________________________________________________________________________ I seguenti problemi esistono ancora in questa versione e sono in via di risoluzione. o OpenGL + Xinerama Attualmente, OpenGL non funziona con Xinerama. o OpenGL e dlopen() Esistono alcuni problemi con versioni più vecchie con il caricatore di glibc dynamic (p.e. la versione inviata con RedHat 7.2) e con applicazioni come Quake3 e Radiant, che utilizzano dlopen (). Consultare la sezione "Ricerca ed eliminazione di guasti" per ulteriori dettagli. o DPMS e TwinView I modi DPMS "suspend" and "standby" non funzionano correttamente su un secondo CRT, quando si utilizza TwinView. Lo schermo è vuoto ed il monitor non viene impostato nello stato DPMS richiesto. o DPMS e schermo piatto I modi DPMS "suspend" e "standby" non funzionano correttamente su di un display con schermo piatto. Lo schermo è vuoto e lo schermo piatto non viene impostato nello stato DPMS richiesto. o Multicard, Multimonitor In alcuni casi, la scheda secondaria non viene inizializzata correttamente dal modulo kernel di Nvdriver. Ciò può essere corretto, abilitando il modulo Xfree86 Int10 per inizializzare tutte le schede. Vedi "APPENDICE D": XF86CONFIG OPTIONS" per maggiori dettagli. o Portatile Se si utilizza un portatile, consultare "Problemi noti relativi ai portatili" APPENDICE D. PROBLEMI HARDWARE Questa sezione descrive i problemi che non possono essere risolti. Generalmente, la fonte del problema si trova al di fuori del controllo di NVIDIA. Qui di seguito l'elenco dei problemi: o Scheda madre Gigabyte GA-6BX Questa scheda madre utilizza un regolatore LinFinity per il rail 3.3-V che è unicamente di 5 A - meno della specifica AGP, che necessita 6 A. Quando la diagnostica o le applicazioni stanno funzionando, la temperatura del regolatore aumenta, causando la caduta del voltaggio del chip NVIDIA a meno di 2.2 V. In questo caso, il regolatore non è in grado di fornire la corrente sul rail 3.3-V, come richiede il chip NVIDIA. Questo problema non esiste quando la scheda grafica ha un regolatore commutatore o quando un alimentatore esterno è collegato al rail 3.3 V. o VIA KX133 e 694X Chipset con AGP 2x o VIA KX133 e 694X Chipset con AGP 2x la scheda madre ASUS K7V, default NVIDIA driver per modo AGP 2x per operare intorno a punti di forza dell'unità insufficienti di uno dei due segnali. o Irongate Chip impostato con AGP 1x AGP 1x transfers sono utilizzati su schede madre Athlon con chip Irongate, impostati per operare intorno ad un problema relativo all'integrità del segnale del chipset. o ALi chipsets, ALi1541 and 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. Vedi "APPENDICE G: "PROBLEMI SPECIFICI ALI" per ulteriori informazioni sui chipset ALI.