LEGGIMI e guida all'installazione di NVIDIA Accelerated Linux Driver Set NVIDIA Corporation Ultimo aggiornamento: $Date: 28/04/2005 $ Driver più recente: 1.0-7664 __________________________________________________________________________ Prefazione __________________________________________________________________________ NVIDIA Accelerated Linux Driver Set permette di sfruttare le GPU NVIDIA con Linux x86 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 e X e supportano tutti i più recenti 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. Il file contiene anche le risposte alle domande più frequenti e soluzioni ai problemi più comuni. Questo file LEGGIMI si trova sul sito Web di NVIDIA (http://www.nvidia.com) e viene installato nel percorso '/usr/share/doc/NVIDIA_GLX-1.0/'. __________________________________________________________________________ Introduzione __________________________________________________________________________ Questo documento fornisce istruzioni per l'installazione e l'uso di NVIDIA Accelerated Linux Driver Set. I capitoli 1, 2 e 3 aiutano l'utente nell'espletamento delle procedure di download, installazione e configurazione dei driver. Il capitolo 4 risponde alle domande più frequenti sul processo di installazione, mentre il capitolo 5 offre soluzioni efficaci ai problemi più comuni. Qualora occorressero altre informazioni, il capitolo 6 offre informazioni di contatto per le risorse dei driver di NVIDIA Linux, mentre il capitolo 7 presenta un breve elenco di risorse esterne. Si presume che l'utente abbia una certa familiarità con la terminologia e le tecniche fondamentali di Linux. Tuttavia, il capitolo 8 offre dettagli su parti del processo di installazione che i principianti possono trovare utili. Le varie appendici presenta informazioni ulteriori. Queste appendici includono l'hardware supportato e i requisiti di sistema, elenchi completi delle opzioni per le varie utility associate con il driver, dettagli di configurazioni specifiche e tematiche o funzionalità avanzate. CONTENUTO: Prefazione Introduzione I. Istruzioni di installazione 1. Selezione e download di pacchetti NVIDIA per il proprio sistema 2. Installazione del driver NVIDIA 3. Configurazione di X per il driver NVIDIA II. Informazioni aggiuntive 4. Domande frequenti (FAQ) 5. Problemi comuni 6. Informazioni per contattare NVIDIA 7. Ulteriori risorse 8. Suggerimenti per i nuovi utenti di Linux 9. Riconoscimenti III. Appendici A. Chip grafici NVIDIA supportati B. Requisiti software minimi C. Componenti installati D. Opzioni X Config E. Impostazioni variabili ambiente OpenGL F. Configurazione AGP G. Configurazione di Twinview H. Configurazione di TV-Out I. Configurazione di un portatile J. Modalità di programmazione K. Flipping e UBB L. Problemi noti M. Interfaccia Proc N. Supporto di XVMC O. Supporto di GLX P. Configurazione di più schermi X su una sola scheda Q. Supporto della gestione dell'alimentazione R. Nomi delle periferiche di visualizzazione S. L'estensione X Composite T. L'utility nvidia-settings U. L'estensione XRandR V. Supporto per GLX in Xinerama __________________________________________________________________________ Capitolo 1. Selezione e download di pacchetti NVIDIA per il proprio sistema __________________________________________________________________________ I driver NVIDIA possono essere scaricati dal sito Web di NVIDIA (http://www.nvidia.com). I driver NVIDIA seguono lo Unified Architecture Model, secondo il quale un singolo gruppo di driver viene utilizzato per tutti i chip grafici supportati da NVIDIA (consultare l'Appendice A per un elenco dei chip supportati). L'utente viene sgravato dal peso della selezione del driver corretto e la serie di driver viene scaricata come un singolo file denominato: 'NVIDIA-Linux-x86-1.0-7664-pkg1.run' Il suffisso del pacchetto ('-pkg#') viene utilizzato per distinguere tra i vari pacchetti che contengono lo stesso driver, ma con differenti interfacce del kernel precompilate. Il file con il numero di pacchetto più elevato è adeguato per la maggior parte delle installazioni. Il supporto di GPU "legacy" è stato rimosso dal driver unificato. Le GPU legacy possono continuare a essere utilizzate in condizioni di massima sicurezza e assistenza grazie a speciali release di driver per GPU legacy. Vedere l'Appendice A per un elenco delle GPU legacy. Il file scaricato è un programma di installazione autoestraente che può essere collocato in qualsiasi punto del sistema. __________________________________________________________________________ Capitolo 2. Installazione del driver NVIDIA __________________________________________________________________________ Questo capitolo offre istruzioni per l'installazione del driver NVIDIA. Si noti che dopo l'installazione, ma prima dell'uso del driver, occorre completare i passaggi descritti nel Capitolo 3. Ulteriori dettagli che possono essere utili per il nuovo utente Linux sono forniti nel Capitolo 8. PRIMA DI INIZIARE Prima di iniziare l'installazione del driver, uscire dal server X e chiudere tutte le applicazioni OpenGL in esecuzione (si noti che è possibile che alcune applicazioni OpenGL persistano anche dopo l'interruzione dell'esecuzione del server X). Si dovrebbe impostare anche il livello di esecuzione predefinito del sistema in modo tale che si avvii su una console VGA e non direttamente su X. Ciò rende più semplice il ripristino, qualora durante l'installazione dovessero verificarsi problemi. Consultare il Capitolo 8 per ulteriori dettagli. AVVIO DEL PROGRAMMA DI INSTALLAZIONE Dopo il download del file 'NVIDIA-Linux-x86-1.0-7664-pkg#.run', passare alla directory che contiene il file scaricato e come utente 'root' cliccare sull'eseguibile: # cd yourdirectory # sh NVIDIA-Linux-x86-1.0-7664-pkg#.run Il file '.run' file è un archivio autoestraente. Una volta eseguito, estrae i il contenuto dell'archivio ed esegue l'utility `nvidia-installer` in esso contenuta, che offre un'interfaccia interattiva all'intera procedura di installazione dei driver di NVIDIA. L'installazione installa anche l'utility 'nvidia-installer' che può essere utilizzata successivamente per disinstallare i driver, effettuare il download automatico di driver aggiornati, ecc. L'uso di questa utility è illustrato in una parte successiva di questo stesso capitolo. Il file '.run' accetta numerose opzioni della riga di comando. Segue un elenco delle opzioni più comuni. Opzioni comuni di '.run' --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-x86-1.0-7664-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. INSTALLAZIONE DELL'INTERFACCIA DEL KERNEL Il modulo kernel di NVIDIA dispone di un livello di interfaccia del kernel che deve essere appositamente compilato per ciascun kernel. 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. L'applicazione individua un'interfaccia kernel precompilata che corrisponde al kernel effettivamente utilizzato. In caso contrario, tenta di scaricarne una dal sito ftp di NVIDIA e di collegarla alla porzione binaria del modulo kernel. Se non è possibile scaricarne una a causa di problemi di connettività di rete o per la sua effettiva assenza, il programma di installazione verifica il sistema per individuare i sorgenti del kernel necessari e procedere alla compilazione dell'interfaccia. Se il programma di installazione deve compilare l'interfaccia kernel, allora occorre installare il pacchetto dei sorgenti del kernel corrispondente al kernel in uso. Se il programma 'nvidia-installer' deve compilare un interfaccia per il proprio kernel, occorre che i file di supporto necessari siano installati nel sistema. Nella maggior parte dei sistemi questo significa che occorre individuare e installare il pacchetto kernel-source o kernel-headers corretto; in alcune delle distribuzioni più recenti, non occorrono altri pacchetti (per esempio, Fedora Core 3, Red Hat Enterprise Linux Si noti che il collegamento dell'interfaccia kernel (qualora l'interfaccia venga scaricata o compilata in fase di installazione) richiede che l'utente disponga di un linker installato nel sistema. Il linker, solitamente '/usr/bin/ld', fa parte del pacchetto binutils. Se non si trova un'interfaccia kernel precompilata, occorre installare un linker prima di installare il driver NVIDIA. CARATTERISTICHE DEL PROGRAMMA DI INSTALLAZIONE NVIDIA Senza opzioni specificate, il file '.run' esegue il programma di installazione dopo averlo scompattato. Il programma di installazione può essere eseguito come una fase separata del processo, oppure può essere eseguito in un momento successivo per ottenere aggiornamenti, ecc. Alcune delle più importanti opzioni della riga di comando di 'nvidia-installer' sono: Opzioni di 'nvidia-installer' --uninstall Durante l'installazione, il programma di installazione esegue backup di tutti i file in conflitto e registra l'installazione dei nuovi file. L'opzione di disinstallazione annulla l'installazione, ripristinando il sistema al suo stato precedente all'operazione di installazione. --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. --update L'utility si collega al sito FTP di NVIDIA, ed effettua il download del file driver più recente, quindi lo installa. --ui=none 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. Questa opzione disabilita l'uso della libreria ncurses. Si noti che, come suggerito dalle opzioni, il programma di installazione ha la capacità di scaricare interfacce del kernel precompilate e aggiornate dal sito NVIDIA FTP (per kernel che sono stati rilasciati dopo la release del driver NVIDIA). __________________________________________________________________________ Capitolo 3. Configurazione di X per il driver NVIDIA __________________________________________________________________________ Il file di configurazione X fornisce un mezzo per configurare il server X. Questa sezione descrive le impostazioni necessarie per abilitare il driver NVIDIA. Un elenco completo dei parametri è fornito nell'Appendice D. Nell'aprile del 2004, X.org Foundation ha rilasciato un X server basato sul server XFree86 X. Numerose distribuzioni Linux sostituiranno il server XFree86 con il nuovo X.org X nel prossimo futuro. Le differenze tra i due X server non dovrebbero avere alcuna conseguenza per gli utenti di NVIDIA Linux salvo le seguenti due eccezioni: Il file di configurazione di X.org è '/etc/X11/xorg.conf' mentre il file di configurazione di XFree86 è '/etc/X11/XF86Config'. I file utilizzano la medesima sintassi. Questo documento fa riferimento a entrambi i file denominandoli "il file di configurazione di X". Il file log di X.org è '/var/log/Xorg.#.log' mentre il file log di XFree86 è '/var/log/XFree86.#.log' (dove '#' è il numero del server -- solitamente 0). Il formato dei file log è quasi identico. Questo documento fa riferimento a entrambi i file come "il file log di X". Perché le modifiche siano leggibili dal server X, occorre modificare il file utilizzato dal server. Sebbene non sia irragionevole ricorrere a una semplice modifica di entrambi i file, è facile determinare il file corretto cercando la riga (==) Using config file: nel file X log. Questa riga indica il nome del file X Config in uso. Se non è disponibile un file funzionante X Config, 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/'). Gli strumenti per la generazione di un file di configurazione (quali ad esempio 'xf86config') sono inclusi in numerose distribuzioni. Ulteriori informazioni sulla sintassi di X Config sono reperibili nella pagina del manuale di XF86Config (`manXF86Config` o `man xorg.conf`). Se è già disponibile un file X Config che utilizza un driver diverso (come il driver "nv" o "vesa"), basta trovare la sezione pertinente del dispositivo. Quindi, sostituire la riga: Driver "nv" (o Driver "vesa") (o Driver "fbdev") con la riga: Driver "nvidia" Rimuovere le righe seguenti: Load "dri" Load "GLCore" Nella sezione "Modulo" del file, aggiungere la riga (se non è già presente): Load "glx" Ci sono numerose opzioni che possono essere aggiunte al file X Config per ottimizzare il driver NVIDIA X. Consultare l'Appendice D, per avere un elenco completo di queste opzioni. Una volta completate queste modifiche al file X Config, è 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 il Capitolo 5 che contiene procedure di soluzione per i problemi più comuni. __________________________________________________________________________ Capitolo 4. Domande frequenti (FAQ) __________________________________________________________________________ Questa sezione fornisce risposte alle domande più frequenti poste dagli utenti su NVIDIA Linux x86 Driver e la sua installazione. Alcune soluzioni di problemi comuni sono presentate nel Capitolo 5, mentre il Capitolo 8 offre diversi suggerimenti per i principianti. Inoltre, le varie Appendici offrono istruzioni dettagliate per configurazioni specifiche. PROGRAMMA DI INSTALLAZIONE NVIDIA D. Come posso estrarre il contenuto del file '.run' senza ricorrere alla effettiva installazione del driver? R. Eseguire il programma di installazione come segue: # sh NVIDIA-Linux-x86-1.0-7664-pkg1.run --extract-only Questa opzione crea la directory NVIDIA-Linux-x86-1.0-7664-pkg1, 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-x86-1.0-7664-pkg1.run --extract-only # cd NVIDIA-Linux-x86-1.0-7664-pkg1/usr/src/nv/ D. Come e quando vengono creati i file dispositivo di NVIDIA? R. A seconda della configurazione del sistema di destinazione, i file dispositivo di NVIDIA venivano creati in uno di questi tre modi differenti: al momento dell'installazione, utilizzando mknod al caricamento del modulo, via devfs (file system del dispositivo di Linux) al caricamento del modulo, via hotplug/udev Nelle attuali release del driver di NVIDIA, i file dispositivo sono creati o modificati mediante il driver X quando si avvia il server X. Per opzione predefinita, il driver NVIDIA tenta di creare file dispositivo con i seguenti attributi: UID: 0 - 'root' GID: 0 - 'root' Mode: 0666 - 'rw-rw-rw-' I file dispositivo esistenti sono modificati se i loro attributi non coincidono con questi parametri predefiniti. Se si vuole che il driver NVIDIA creai i file dispositivo con attributi differenti, è possibile specificarli con i parametri "NVreg_DeviceFileUID" (utente), "NVreg_DeviceFileGID" (gruppo) e "NVreg_DeviceFileMode" del modulo kernel di NVIDIA Linux. Per esempio, il driver NVIDIA può essere istruito a creare file dispositivo con UID=0 (radice), GID=44 (video) e Mode=0660 passando i seguenti parametri del modulo al modulo del kernel di NVIDIA Linux: NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 NVreg_DeviceFileMode=0660 Il parametro del kernel di NVIDIA "NVreg_ModifyDeviceFiles" disattiva la gestione del file dispositivo dinamico, se impostato su 0. 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-x86-1.0-7664-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-x86-1.0-7664-pkg1.run --extract-only # cd NVIDIA-Linux-x86-1.0-7664-pkg1 # 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 pkg 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-x86-1.0-7664-pkg1.run, ma vedo che NVIDIA-Linux-x86-1.0-7664-pkg2.run è stato appena inserito nella pagina di download dei driver Linux di NVIDIA. Devo scaricare e installare il file NVIDIA-Linux-x86-1.0-7664-pkg2.run? R: Questa operazione non è affatto necessaria. Il driver contenuto in tutti i file .run della serie 1.0-7664 '.run' è 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 'nvidia-installer'? R: L'utility 'nvidia-installer' è rilasciata in base alla GPL. Il più recente codice sorgente è disponibile all'indirizzo: ftp://download.nvidia.com/XFree86/nvidia-installer NVIDIA DRIVER 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 X log file in '/var/log'. 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'. Cercare: (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 X? R: Per opzione predefinita, il driver NVIDIA X produce relativamente pochi messaggi per stderr e per il file log X. 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 X è 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: 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 per opzione predefinita come parte dell'installazione del driver. Se si preferisce non installare i file header OpenGL distribuiti da NVIDIA, è possibile inviare l'opzione --no-opengl-headers al file 'NVIDIA-Linux-x86-1.0-7664-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: 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 realizzare patch per questi file sorgente, a supporto dei kernel di sviluppo. È molto probabile che una semplice ricerca su google porti a individuare diverse patch supportate dalla comunità. 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: 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: 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. Cosa posso fare? R: Si può impostare la variabile di ambiente 'LD_ASSUME_KERNEL' a un valore precedente a "2.3.99" (per esempio, 2.3.98). Consultare il Capitolo 8 della nuova guida dell'utente per ulteriori suggerimenti sull'impostazione delle variabili d'ambiente. 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. D. Il file log del server X contiene il messaggio: (WW) NVIDIA(0): Sembra che sia in uso l'estensione XFree86-DGA. Tenere (WW) NVIDIA(0): presente che il supporto di questa estensione sarà (WW) NVIDIA(0): rimosso dal driver NVIDIA in una futura release. (WW) NVIDIA(0): Consultare il file LEGGIMI NVIDIA per ulteriori dettagli. D Quali sono i programmi di NVIDIA per quanto riguarda il supporto dell'estensione XFree86-DGA? R. Il supporto dell'estensione XFree86-DGA verrà rimosso dal driver NVIDIA in una prossima release. Questo significa che sebbene l'estensione continuerà a essere rilevata e XDGASelectInput() continuerà a funzionare correttamente in modo che i client DGA possano acquisire il movimento del puntatore, i punti di ingresso DGA quali XDGASetMode() e XDGAOpenFramebuffer() non funzioneranno. Se preferite non rimuovere il supporto DGA dal driver X di NVIDIA, vi preghiamo di farcelo sapere comunicandolo sul forum Linux all'indirizzo nvnews.net. D. Il mio file log del kernel contiene messaggi con il prefisso "Xid"; cosa sono questi messaggi? R. I messaggi "Xid" indicano che si è verificato un errore generale della GPU, nella maggior parte dei casi dovuto a un errore di programmazione della GPU da parte del driver o al danneggiamento dei comandi inviati alla GPU. Questi messaggi offrono informazioni diagnostiche che possono essere utilizzate da NVIDIA per contribuire al debugging dei problemi riferiti. __________________________________________________________________________ Capitolo 5. Problemi comuni __________________________________________________________________________ Questa sezione offre soluzioni a problemi comuni associati con il driver NVIDIA Linux x86. D: Il server X non si avvia e il file log X contiene l'errore: (EE) NVIDIA(0): Failed to load the NVIDIA kernel module! R: Il driver X terminerà l'esecuzione visualizzando questo messaggio di errore nel caso in cui il caricamento del modulo kernel NVIDIA non riesca. Se si riceve questo messaggio di errore, si deve verificare l'output di `dmesg` alla ricerca di messaggi di errore del kernel e/o di tentativi di caricare il modulo del kernel esplicitamente con `modprobe nvidia`. Se si riscontrano simboli irrisolti, allora il modulo kernel è stato con ogni probabilità creato utilizzando un albero sorgente del kernel Linux (o header del kernel) di una revisione o di una configurazione del kernel che non corrisponde al kernel in esecuzione. È possibile specificare la posizione dell'albero sorgente del kernel (o dei suoi header) quando si installa il driver NVIDIA utilizzando l'opzione della riga di comando --kernel-source-path (consultare `sh NVIDIA-Linux-x86-1.0-7664-pkg1.run -opzioni avanzate` per ulteriori dettagli). Vecchie versioni dei module-init-tools includono binari `modprobe` che riferiscono un errore quando sono istruiti a caricare un modulo già presente nel kernel. Aggiornare i module-init-tools se si riceve un messaggio di errore di questo tipo. Il server X legge '/proc/sys/kernel/modprobe' per determinare il percorso verso l'utility `modprobe` e torna a '/sbin/modprobe' se il file non esiste. Accertarsi che questo percorso sia valido e si riferisca a un binario `modprobe` compatibile con il kernel Linux in esecuzione nel sistema. L'opzione del driver X "LoadKernelModule" può essere utilizzata per modificare il comportamento predefinito e disabilitare l'auto-caricamento del modulo del kernel. D: Il server X non si avvia e il file log X contiene l'errore: (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module! R: Se il modulo kernel NVIDIA non funziona adeguatamente, non funzionerà nulla. Se nel file X log si riscontrano errori quali (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module! probabilmente esiste un problema relativo al modulo kernel NVIDIA. Il modulo kernel di NVIDIA potrebbe anche visualizzare messaggi di errore che indicano la presenza di un problema -- per esaminare questi messaggi, verificare l'output di `dmesg`, /var/log/messaggi, o qualsiasi posizione nella quale syslog colloca i messaggi relativi al kernel. Questi messaggi hanno la preposizione "NVRM". D: Il server X non si avvia e il file log X contiene l'errore: "(EE) NVIDIA(0): Il modulo del kernel NVIDIA non sembra ricevere gli (EE) NVIDIA(0): interrupt generati dal dispositivo grafico NVIDIA. (EE) NVIDIA(0): Consultare la sezione DOMANDE FREQUENTI del (EE) NVIDIA(0): file LEGGIMI per ulteriori informazioni." R: Questo può essere provocato da una varietà di problemi, quali errori del routing IRQ PCI, problemi o conflitti APIC I/O con altri dispositivi che condividono l'IRQ (o con i loro driver). Se possibile, configurare il proprio sistema in modo tale che le scheda grafica non condivida il suo IRQ con altri dispositivi (tentare di spostare la scheda grafica in un altro slot (se applicabile), scaricare/disabilitare i driver del dispositivo che condividono l'IRQ della scheda, oppure rimuovere/disabilitare i dispositivi)). A seconda della natura del problema, si può fare ricorso a uno di questi parametri del kernel (o a una loro combinazione): Parametro Comportamento ------------------------------- ------------------------------- pci=noacpi non usare ACPI per il routing IRQ PCI pci=biosirq usare le chiamate del BIOS PCI per recuperare la tabella di routing IRQ noapic non usare le APIC I/O presenti nel sistema acpi=off disabilita ACPI 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 eseguire 'ldconfig'. Occorre anche verificare, che sia disponibile l'estensione corretta; % xdpyinfo dovrà comprendere le estensioni "GLX" e "NV-GLX". Se non vi sono queste due estensioni, probabilmente esiste un problema relativo al modulo glx caricato, oppure il sistema non è in grado di caricare completamente Glcore. Verificare il file X Config ed accertarsi di caricare glx (vedere il Capitolo 3). Se il file X Config è quello giusto, controllare il file log X 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: #error Modules should never use kernel-headers system headers #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 si bloccano e producono il seguente messaggio di errore: 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.txt. 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' sul valore "1" 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. Quake3 si blocca durante il cambio di modalità video. R. Probabilmente si tratta del problema descritto qui sopra. Controllare il testo del messaggio di errore descritto nella risposta precedente. Impostare '__GL_SINGLE_THREADED' su "1" dovrebbe risolvere il problema. D: Non è possibile creare il modulo kernel NVIDIA, o è possibile crearlo, ma modprobe/ismod non carica il modulo nel kernel. 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/RELEASE/build/include' (nella quale RELEASE è il risultato di 'uname-r'. Il programma 'nvidia-installer' è 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: 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: Il sistema rallenta selezionando vt e con rivafb abilitato. R: Utilizzando sia rivafb che il modulo kernel NVIDIA contemporaneamente, generalmente si riscontrano evidenti rallentamenti. In genere non è consigliabile usare due diversi driver software per uno stesso hardware. D: Compilando il modulo kernel NVIDIA 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 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 gcc 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: 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ù. R: È possibile che siano state installate librerie in conflitto dall'utility di aggiornamento della distribuzione; consultare l'Appendice C per ulteriori dettagli sulle modalità di diagnosi di questo problema. D. Il comando '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: 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/ # make mrproper # cp configs/kernel-2.4.18-i686-bigmem.config .config # make 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. Le applicazioni OpenGL assorbono una quantità significativa della memoria del sistema! R. Se il kernel utilizza l'opzione -rmap VM, il sistema potrebbe far registrare l'assorbimento di memoria a causa di un'ottimizzazione di gestione della memoria introdotta con -rmap14a. L'opzione -rmap VM è stata adottata da diverse distribuzioni fra le più diffuse, e il problema di assorbimento di memoria è noto in alcuni dei kernel di queste distribuzioni; è stato risolto con -rmap15e. Se si sospetta che il proprio sistema possa essere affetto da questo problema, tentare l'aggiornamento del proprio kernel oppure contattare il fornitore della distribuzione per ulteriore assistenza. 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: X non ripristina la console vga quando viene eseguito su un apparecchio televisivo. Nel mio file log X compare il seguente messaggio di errore: Unable to initialize the X int10 module; the console may not be restored correctly on your TV. R: Il driver NVIDIA X si avvale del modulo X 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 X personalmente, accertarsi di aver creato il modulo Int10. Se si sta utilizzando una build di X 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 Wolfenstein 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 log X 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. Riesco a eseguire il sistema, ma mi sembra piuttosto instabile. Cosa succede? R. I problemi di stabilità potrebbero essere connessi all'AGP. Consultare l'appendice F per i dettagli. D. Le applicazioni OpenGL sono piuttosto lente R. L'applicazione sta probabilmente utilizzando una libreria differente ancora presente nel sistema, al posto della libreria OpenGL NVIDIA in dotazione. Consultare l'Appendice C per ulteriori 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. Sto utilizzando soluzioni grafiche interne nForce o nForce2 e nel file log di X compaiono avvertimenti come questo: Not using mode "1600x1200" (exceeds valid memory bandwidth usage) R. La soluzione grafica integrata ha limitazioni della banda passante più severe che riducono la risoluzione e il tasso di aggiornamento delle modalità richieste dall'utente. Per aggirare queste limitazioni, è possibile ridurre il tasso massimo di aggiornamento diminuendo il valore superiore della gamma VertRefresh nella sezione 'Monitor' del file X Config. Sebbene sia un'opzione sconsigliata, è possibile disabilitare il test di banda passante della memoria con l'opzione NoBandWidthTest del file X Config. D: X impiega molto tempo per avviarsi (a volte, anche diversi 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 X Config "IgnoreDisplayDevices" (consultarne la descrizione nell'Appendice D). 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 grossolanamente errate, allora è possibile correggerle aggiungendo il campo DisplaySize alla sezione monitor del file X Config (vedere le pagine X Config o xorg.conf 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 log X 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. __________________________________________________________________________ Capitolo 6. Informazioni per 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 esplorato i Capitoli 4 e 5 di questo file LEGGIMI e dopo aver chiesto aiuto al nv.new Web forum. Quando si inviano messaggi di e-mail a linux-bugs@nvidia.com, includere anche il file 'nvidia-bug-report.log' generati dallo script 'nvidia-bug-report.sh' (che viene installato come parte dell'installazione del driver). __________________________________________________________________________ Capitolo 7. Ulteriori risorse __________________________________________________________________________ Risorse Linux OpenGL ABI http://oss.sgi.com/projects/ogl-sample/ABI/ The XFree86 Project http://www.xfree86.org/ XFree86 Video Timings HOWTO http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html The X.org Foundation http://www.x.org/ OpenGL http://www.opengl.org/ __________________________________________________________________________ Capitolo 8. Suggerimenti per i nuovi utenti di Linux __________________________________________________________________________ Questa guida di installazione presume che l'utente una certa familiarità con le tecniche e la terminologia di Linux. Nella presente sezione si forniscono suggerimenti utili per i principianti. Sebbene questi suggerimenti siano intesi a chiarire e a offrire assistenza agli utenti nelle procedure di installazione e configurazione del driver Linux di NVIDIA, non li si può considerare alla stregua di un esercitazione sull'uso o l'amministrazione del sistema operativo Linux. A differenza di molti altri sistemi operativi, è relativamente facile provocare danni irreparabili al proprio sistema Linux. Se non avete familiarità con l'uso di Linux, vi consigliamo vivamente di rivolgervi al vostro distributore per farvi aiutare a trovare un'esercitazione valida prima di procedere. IL PROMPT DEI COMANDI Sebbene le release più recenti di Linux offrano nuove interfacce desktop all'utente, molto del lavoro di Linux si svolge dalla riga di comando. Se avete familiarità con il sistema operativo Windows, il prompt della riga di comando di Linux è analogo alla funzione analoga di Windows, sebbene la sintassi e l'uso non siano esattamente gli stessi. Tutti i comandi di questa sezione sono eseguiti dal prompt di comando. Alcuni sistemi sono configurati per il boot in modalità console, nel qual caso all'utente viene presentato un prompt al login. Altri sistemi sono configurati per avviare finestre X, nel qual caso l'utente deve aprire un terminale o una finestra della console per ottenere un prompt di comando. Questo solitamente può essere effettuato cercando nei menu del desktop un terminale o un programma console. Sebbene sia personalizzabile, il prompt di base solitamente consiste di una breve stringa di informazioni, uno dei caratteri '#', '$', o '%' e di un cursore (possibilmente lampeggiante) che indica dove viene visualizzato l'input dell'utente. NAVIGAZIONE DELLA STRUTTURA DI DIRECTORY Linux ha una struttura gerarchica di directory. Da qualsiasi punto nella struttura di directory, il comando 'ls' elenca il contenuto della directory. Il comando 'file' stampa il tipo di file in una directory. Per esempio, % file filename stampa il tipo del 'filename'. La modifica delle directory viene eseguita con il comando 'cd'. % cd dirname cambia la directory corrente a 'dirname'. Da qualsiasi punto della struttura di directory, il comando 'pwd' stampa il nome della directory corrente. Ci sono due directory speciali, '.' e '..', che si riferiscono, rispettivamente, alla directory corrente e a quella posta immediatamente più in alto nella gerarchia. Per qualsiasi comando che richieda un nome di file o directory come argomento, è possibile specificare i percorsi assoluti o relativi di quegli elementi. Un percorso assoluto inizia con il carattere "/", che fa riferimento alla parte superiore o alla radice della struttura di directory. Un percorso relativo inizia con una directory nell'attuale directory di lavoro. Il percorso relativo può iniziare con '.' o '..'. Gli elementi di un percorso sono separatati dal carattere "/". Come esempio, se la directory corrente è '/home/jesse' e l'utente intende passare alla directory '/usr/local', può usare uno dei comandi seguenti: % cd /usr/local or % cd ../../usr/local PERMESSI DEI FILE E PROPRIETÀ Per tutti i file e le directory vengono definiti permessi e proprietà. Questo è utile per impedire agli utenti non amministrativi di danneggiare il sistema in modo accidentale (o malintenzionato). Permessi e proprietà per un file o una directory possono essere determinati passando l'opzione -l al comando 'ls'. Per esempio: % ls -l drwxr-xr-x 2 jesse users 4096 Feb 8 09:32 bin drwxrwxrwx 10 jesse users 4096 Feb 10 12:04 pub -rw-r--r-- 1 jesse users 45 Feb 4 03:55 testfile -rwx------ 1 jesse users 93 Feb 5 06:20 myprogram -rw-rw-rw- 1 jesse users 112 Feb 5 06:20 README % La prima colonna di caratteri nel primo campo di output indica il tipo di file, dove 'd' è una directory e '-' è un file regolare. Le nove colonne successive specificano i permessi (vedere sotto) dell'elemento. Il secondo campo indica il numero di file associati con l'elemento, il terzo campo indica il proprietario, il quarto campo indica il gruppo cui il file è associato, il quinto campo indica le dimensioni dell'elemento in byte, il sesto, settimo e ottavo campo indicano il momento dell'ultima modifica del file e il nono campo è il nome dell'elemento stesso. Come indicato, le ultime nove colonne del primo campo indicano i permessi dell'elemento. Queste colonne sono raggruppate in gruppi di tre. Il primo raggruppamento indica i permessi per il proprietario dell'elemento ('jesse' in questo caso), il secondo indica i permessi del gruppo associato con l'elemento, mentre il terzo indica i permessi per il resto del mondo. I valori 'r', 'w' e 'x' indicano rispettivamente i permessi di lettura, scrittura ed esecuzione, per ciascuna di queste associazioni. Per esempio, l'utente 'jesse' ha permessi di lettura e scrittura per 'testfile', mentre gli utenti del gruppo 'users' hanno solo il permesso di lettura, come il resto del mondo. Invece, per il file 'myprogram', l'utente 'jesse' ha i permessi di lettura, scrittura ed esecuzione (fatto che suggerisce che 'myprogram' sia un programma che può essere eseguito), mentre gli utenti del gruppo 'users' e il resto del mondo non hanno alcun permesso (fatto che suggerisce che il proprietario desidera nessun altro possa eseguire il programma). I permessi, la proprietà e i gruppi associati con un elemento possono essere modificati con i comandi 'chmod', 'chown' e 'chgrp', rispettivamente. Se un utente con i permessi appropriati desidera modificare la proprietà user/group di 'LEGGIMI' da jesse/users a joe/admin, deve fare quanto segue: # chown joe README # chgrp admin README La sintassi per chmod è leggermente più complicata e ha diverse variazioni. Il modo più conciso per impostare i permessi per un singolo elemento si avvale di un terzetto di numeri, uno ciascuno per utente, gruppo e mondo. Il valore di ciascun numero del terzetto corrisponde a una combinazione di permessi di lettura, scrittura ed esecuzione. La sola esecuzione è rappresentata da 1, la sola scrittura da 2 mentre la sola lettura è rappresentata da 4. Le combinazioni di questi permessi sono rappresentate da somme dei permessi individuali. Lettura ed esecuzione sono rappresentate da 5, mentre lettura, scrittura ed esecuzione sono rappresentate da 7. Nessun permesso è rappresentato da 0. Quindi, per offrire al proprietario i permessi di lettura, scrittura ed esecuzione, al gruppo quelli di lettura ed esecuzione e al mondo nessun permesso, un utente scriverebbe quanto segue: % chmod 750 myprogram LA SHELL La shell offre un'interfaccia tra l'utente e il sistema operativo. È compito della shell interpretare l'input fornito dall'utente al prompt dei comandi e richiedere al sistema di agire di conseguenza. Ci sono diverse shell differenti disponibili, ciascuna con una sintassi e capacità lievemente differenti. Le due versioni più diffuse della shell per le distribuzioni di Linux sono la shell Borne ('sh') e la C-shell ('csh'). I vari utenti hanno preferenze e orientamenti nei confronti di una shell o dell'altra, e alcune certamente semplificano (o almeno rendono più intuitivo) l'esecuzione di certe operazioni. È possibile determinare la propria shell corrente stampando il valore della 'SHELL' dal prompt dei comandi con % echo $SHELL È possibile avviare una nuova shell semplicemente digitando il nome della shell dal prompt dei comandi: % csh oppure % sh ed è possibile eseguire un programma dall'interno di una shell specifica facendo precedere il nome dall'eseguibile con il nome della shell nel quale deve essere eseguito: % sh myprogram La shell dell'utente predefinito al login viene determinata da chiunque ne abbia configurato l'account. Sebbene ci siano numerose differenze sintattiche tra le shell, forse quella che viene riscontrata più di frequente è il modo in cui vengono impostate le variabili ambientali. IMPOSTAZIONE DELLE VARIABILI AMBIENTALI Ogni sessione ha associate ad essa delle variabili ambientali, che consistono di coppie nome/valore e controllano il modo in cui la shell esegue i programmi e il loro comportamento. Un esempio di una variabile ambientale è la variabile 'PATH', che dice alla shell quali directory cercare quando tenta di individuare un file eseguibile che l'utente ha digitato alla riga di comando. Se si è certi che un simile comando esista, ma la shell dichiara di non essere in grado di trovarlo, può sussistere un problema con la variabile 'PATH'. Le variabili ambientali dipendono a vario titolo dalla shell utilizzata. Per la shell Borne ('sh'), la procedura è: % export MYVARIABLE="avalue" per la C-shell, invece: % setenv MYVARIABLE "avalue" In entrambi i casi, le virgolette sono necessarie soltanto se il valore contiene degli spazi. Il comando 'echo' può essere utilizzato per esaminare il valore di una variabile ambientale: % echo $MYVARIABLE I comandi per impostare le variabili ambientali possono includere riferimenti alle altre variabili ambientali (precedute dal carattere "$"). Per aggiungere il percorso '/usr/local/bin' all'inizio del percorso di ricerca e la directory corrente '.' alla fine del percorso di ricerca, un utente deve digitare: % export PATH=/usr/local/bin:$PATH:. nella shell Borne e % setenv PATH /usr/local/bin:${PATH}:. nella C-shell. Si noti che le parentesi graffe sono necessarie per proteggere il nome della variabile in C-shell. MODIFICA DEI FILE DI TESTO Ci sono diversi editor di testo disponibili per il sistema operativo Linux. Alcuni di questi editor richiedono il sistema X Windows, mentre altri sono progettati per operare in una console o in un terminale. In generale è buona norma avere una certa competenza con un editor basato su terminale, dato che ci sono occasioni nelle quali i file necessari per l'esecuzione di X sono proprio quelli da modificare. Tre editor particolarmente diffusi sono 'vi', 'pico' ed 'emacs', ciascuno dei quali può essere avviato dalla riga di comando. In modo facoltativo si può anche fornire il nome di un file da modificare. 'vi' è probabilmente il più universalmente diffuso ma è anche il meno intuitivo dei tre. 'pico' è abbastanza diretto per un principiante, sebbene sia relativamente poco diffuso. 'emacs' è altamente estensibile e abbastanza diffuso, ma può risultare piuttosto difficile in ambiente non X. Le versioni più nuove sono tutte dotate di guida online, mentre offline è possibile consultare il manuale e le pagine informative (consultare la sezione sul manuale e le pagine informative di Linux). Molti programmi si avvalgono della variabile di ambiente 'EDITOR' per determinare quale editor di testo avviare quando viene richiesta una modifica. UTENTE ROOT All'installazione, quasi tutte le distribuzioni configurano l'utente amministrativo predefinito con uno username 'root'. Ci sono numerose operazioni che solo l'utente 'root' (o un altro utente con gli stessi privilegi) possono effettuare, una delle quali è proprio l'installazione del driver Linux di NVIDIA. Ci sono tre modi per diventare 'root'. Si può effettuare il login con l'identità root così come lo si farebbe con qualsiasi altra identità. È possibile usare il comando utente sostitutivo ('su') al prompt di comando. Altri sistemi sono dotati invece dell'utility 'sudo', che permette agli utenti di eseguire programmi come 'root' pur conservando un log delle loro azioni. Quest'ultimo metodo è utile qualora un utente provochi inavvertitamente danni al sistema e non riesca a ricordare cosa abbia fatto (o preferisca non ammettere di averlo fatto). Generalmente è buona norma conservare i privilegi di 'root' solo per il tempo strettamente necessario a portare a termine l'operazione che richiede questi privilegi (un'altra preziosa funzionalità dell'utility 'sudo'). AVVIO A UN RUNLEVEL DIFFERENTE I Run-level di Linux dettano quali servizi vengano avviati e arrestati in modo automatico quando il sistema si avvia o si spegne. I run-level di solito variano da 0 a 6; generalmente, il run-level 5 avvia X Windows quale parte dei servizi (il run-level 0 è a tutti gli effetti un interruzione di sistema, mentre il 6 è un riavvio di sistema). È una buona norma installare il driver Linux di NVIDIA mentre X non è in esecuzione, ed è una buona idea impedire che X Windows si avvia al reboot qualora ci siano problemi con l'installazione (altrimenti ci si potrebbe ritrovare con un sistema danneggiato che tenta automaticamente di avviare X, ma poi si blocca durante l'avvio, impedendo l'esecuzione di qualsiasi riparazione necessaria per risolvere i problemi di X). A seconda della configurazione di rete, i run-level 1, 2 o 3 dovrebbero dimostrarsi sufficienti a installare il Driver. Solitamente, il run-level 3 include i servizi di networking, quindi se le utility utilizzate dal sistema durante l'installazione dipendono da un filesystem remoto, i run-level 1 e 2 risulteranno insufficienti. Se il sistema di solito viene riavviato da una console con un prompt di comando, non si dovrebbe modificare nulla. Se invece il sistema si avvia da X Windows con un login e un desktop grafico, si deve uscire da X Windows e modificare il run-level predefinito. Nella maggior parte delle distribuzioni, il run-level predefinito viene archiviato nel file '/etc/inittab', sebbene sia possibile consultare la guida per la propria distribuzione. La riga che indica il run-level predefinito compare come id:n:initdefault: o analoga, dove "n" indica il numero del run-level. '/etc/inittab' deve essere modificata come radice. Si prega di leggere le sezioni sulla modifica di file e utente radice se non si ha familiarità con questo concetto. Inoltre, si raccomanda di creare una copia del file prima di modificarlo, in particolare se si è nuovi agli editor di testo di Linux, nel caso si danneggi accidentalmente il file: # cp /etc/inittab /etc/inittab.original La riga va modificata in modo tale che il valore di run-level predefinito sia appropriato (per la maggior parte dei sistemi si tratta del valore 1, 2 o 3): id:3:initdefault: Dopo il salvataggio delle modifiche, uscire da X. Dopo aver completato l'installazione del driver, si può ripristinare il valore di run-level predefinito, sia modificando nuovamente '/etc/inittab', sia conferendo nuovamente il nome originario alla copia di backup. Distribuzioni differenti offrono metodi diversi per uscire da X Windows. In numerosi sistemi, l'utility 'init' passa al run-level corrente. Questo può essere utilizzato per passare a un run-level nel quale X non sia in esecuzione. # init 3 Ci sono altri metodi con i quali uscire da X. Consultare la propria distribuzione. MANUALE E PAGINE INFORMATIVE DI LINUX La maggior parte delle distribuzioni installano il manuale di sistema o le pagine informative per opzione predefinita. Queste pagine sono di solito aggiornate e in generale contengono un elenco completo delle possibilità d'uso dei programmi e delle utility del sistema. Inoltre, numerose implementazioni di programmi tradizionalmente includono l'opzione --help, che solitamente stampa un elenco delle opzioni più comuni di quel programma. Per visualizzare la pagina del manuale per un comando, digitare: % man commandname al prompt del comando. In questa istruzione commandname si riferisce al comando che interessa all'utente. Analogamente, digitare: % info commandname visualizza la pagina informativa del comando. Alcune distribuzioni possono dichiarare che l'una o l'altra fonte di informazione è più aggiornata. L'interfaccia del sistema informativo è interattiva e navigabile. Se non siete in grado di individuare la pagina del manuale per il comando che vi interessa, potreste aggiungere elementi aggiuntivi alla variabile ambientale 'MANPATH'. Consultare la sezione sulle variabili ambientali. __________________________________________________________________________ Capitolo 9. Riconoscimenti __________________________________________________________________________ L'applicazione 'nvidia-installer' si ispira allo strumento 'loki_update': http://www.lokigames.com/development/loki_update.php3/ L'assistenza ftp e http per l'applicazione 'nvidia-installer' si basa si 'snarf 7.0' : http://www.xach.com/snarf/ L'archivio autoestraente (anche definito come file '.run') viene generato usando 'makeself.sh': http://www.megastep.org/makeself/ __________________________________________________________________________ Appendice A. Chip grafici NVIDIA supportati __________________________________________________________________________ NOME CHIP NVIDIA ID PERIFERICA PCI ------------------------------- ------------------------------- GeForce 6800 Ultra 0x0040 GeForce 6800 0x0041 GeForce 6800 GT 0x0045 GeForce 6800 GT 0x0046 Quadro FX 4000 0x004E GeForce 6800 0x00C1 GeForce 6800 LE 0x00C2 GeForce Go 6800 0x00C8 GeForce Go 6800 Ultra 0x00C9 Quadro FX Go1400 0x00CC Quadro FX 3450/4000 SDI 0x00CD Quadro FX 1400 0x00CE GeForce 6800/GeForce 6800 Ultra 0x00F0 GeForce 6600/GeForce 6600 GT 0x00F1 GeForce 6600 0x00F2 GeForce 6200 0x00F3 Quadro FX 3400 0x00F8 GeForce 6800 Ultra 0x00F9 GeForce PCX 5750 0x00FA GeForce PCX 5900 0x00FB Quadro FX 330/GeForce PCX 5300 0x00FC Quadro NVS 280 PCI-E 0x00FD Quadro FX 330 0x00FD Quadro FX 1300 0x00FE GeForce PCX 4300 0x00FF GeForce2 MX/MX 400 0x0110 GeForce2 MX 100/200 0x0111 GeForce2 Go 0x0112 Quadro2 MXR/EX/Go 0x0113 GeForce 6600 GT 0x0140 GeForce 6600 0x0141 GeForce 6600 LE 0x0142 GeForce Go 6600 0x0144 GeForce 6610 XL 0x0145 GeForce Go 6600 TE/6200 TE 0x0146 GeForce Go 6600 0x0148 GeForce Go 6600 GT 0x0149 Quadro FX 540 0x014E GeForce 6200 0x014F GeForce 6200 TurboCache(TM) 0x0161 GeForce Go 6200 0x0164 GeForce Go 6400 0x0166 GeForce Go 6200 0x0167 GeForce Go 6400 0x0168 GeForce4 MX 460 0x0170 GeForce4 MX 440 0x0171 GeForce4 MX 420 0x0172 GeForce4 MX 440-SE 0x0173 GeForce4 440 Go 0x0174 GeForce4 420 Go 0x0175 GeForce4 420 Go 32M 0x0176 GeForce4 460 Go 0x0177 Quadro4 550 XGL 0x0178 GeForce4 440 Go 64M 0x0179 Quadro NVS 0x017A Quadro4 500 GoGL 0x017C GeForce4 410 Go 16M 0x017D GeForce4 MX 440 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 Quadro NVS 50 PCI 0x018C GeForce2 Integrated GPU 0x01A0 GeForce4 MX Integrated GPU 0x01F0 GeForce3 0x0200 GeForce3 Ti 200 0x0201 GeForce3 Ti 500 0x0202 Quadro DCC 0x0203 GeForce 6800 0x0211 GeForce 6800 LE 0x0212 GeForce 6800 GT 0x0215 GeForce4 Ti 4600 0x0250 GeForce4 Ti 4400 0x0251 GeForce4 Ti 4200 0x0253 Quadro4 900 XGL 0x0258 Quadro4 750 XGL 0x0259 Quadro4 700 XGL 0x025B GeForce4 Ti 4800 0x0280 GeForce4 Ti 4200 with AGP8X 0x0281 GeForce4 Ti 4800 SE 0x0282 GeForce4 4200 Go 0x0286 Quadro4 980 XGL 0x0288 Quadro4 780 XGL 0x0289 Quadro4 700 GoGL 0x028C GeForce FX 5800 Ultra 0x0301 GeForce FX 5800 0x0302 Quadro FX 2000 0x0308 Quadro FX 1000 0x0309 GeForce FX 5600 Ultra 0x0311 GeForce FX 5600 0x0312 GeForce FX 5600XT 0x0314 GeForce FX Go5600 0x031A GeForce FX Go5650 0x031B Quadro FX Go700 0x031C GeForce FX 5200 0x0320 GeForce FX 5200 Ultra 0x0321 GeForce FX 5200 0x0322 GeForce FX 5200LE 0x0323 GeForce FX Go5200 0x0324 GeForce FX Go5250 0x0325 GeForce FX 5500 0x0326 GeForce FX 5100 0x0327 GeForce FX Go5200 32M/64M 0x0328 Quadro NVS 280 PCI 0x032A Quadro FX 500/600 PCI 0x032B GeForce FX Go53xx 0x032C GeForce FX Go5100 0x032D GeForce FX 5900 Ultra 0x0330 GeForce FX 5900 0x0331 GeForce FX 5900XT 0x0332 GeForce FX 5950 Ultra 0x0333 GeForce FX 5900ZT 0x0334 Quadro FX 3000 0x0338 Quadro FX 700 0x033F GeForce FX 5700 Ultra 0x0341 GeForce FX 5700 0x0342 GeForce FX 5700LE 0x0343 GeForce FX 5700VE 0x0344 GeForce FX Go5700 0x0347 GeForce FX Go5700 0x0348 Quadro FX Go1000 0x034C Quadro FX 1100 0x034E Segue l'elenco delle GPU legacy che non vengono più supportate dal driver unificato. Queste GPU continueranno a essere supportate tramite le speciali release legacy dei driver per GPU NVIDIA. NOME CHIP NVIDIA ID PERIFERICA PCI ------------------------------- ------------------------------- RIVA TNT 0x0020 RIVA TNT2/TNT2 Pro 0x0028 RIVA TNT2 Ultra 0x0029 Vanta/Vanta LT 0x002C RIVA TNT2 Model 64/Model 64 Pro 0x002D Aladdin TNT2 0x00A0 GeForce 256 0x0100 GeForce DDR 0x0101 Quadro 0x0103 GeForce2 GTS/GeForce2 Pro 0x0150 GeForce2 Ti 0x0151 GeForce2 Ultra 0x0152 Quadro2 Pro 0x0153 __________________________________________________________________________ Appendice B. Requisiti software minimi __________________________________________________________________________ Elemento software Requisito minimi Verifica con... ------------------ ------------------ ------------------ Linux kernel 2.4.0 `cat /proc/version` XFree86/Xorg 4.0.1/6.7 `XFree86 -version/Xorg -version` Kernel modutils 2.1.121 `insmod -v` Per costruire il modulo kernel NVIDIA: Elemento software Requisito minimi Verifica con... ------------------ ------------------ ------------------ binutils 2.9.5 `size --version` GNU make 3.77 `make --version` gcc 2.91.66 `gcc --version` glibc 2.0 `ls /lib/libc.so.* > 6` Se si costruisce da sorgente rpm: Requisito software Verifica con... ------------------------------- ------------------------------- spec-helper rpm `rpm -qi spec-helper` Tutte le versioni ufficiali stabili di 2.4.0 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 http://www.kernel.org o da uno dei suoi mirror. Binutils e gcc possono essere recuperati da http://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 4.x 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 si può poi 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 http://www.xfree86.org). Questi pacchetti software, sono disponibili anche attraverso il vostro distributore Linux. __________________________________________________________________________ Appendice C: Componenti installati __________________________________________________________________________ NVIDIA Accelerated Linux Driver Set è costituito dai seguenti componenti (i nomi dei file fra parentesi sono i nomi completi dei componenti dopo l'installazione; "x.y.z" indica la versione attuale. In questi casi, durante l'installazione vengono creati i symlink appropriati): o Un driver X (/usr/X11R6/lib/modules/drivers/nvidia_drv.o); questo driver è necessario al server X per utilizzare l'hardware NVIDIA. Il driver nvidia_drv.o è binariamente compatibile con XFree86 4.0.1 e superiore, oltre al server Xorg X. o Un modulo di estensione GLX per X (/usr/X11R6/lib/modules(moduli)/extensions(estensioni)/libglx.so.x.y.z; questo modulo è utilizzato dal server X 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 X Config - 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 l'Appendice N per ulteriori dettagli. o Un modulo kernel(/lib/modules/`uname -r`/video/nvidia.o oppure /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o); 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 X 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 il server X, 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/include/GL/gl.h, /usr/include/GL/glext.h, /usr/include/GL/glx.h, e /usr/include/GL/glext.h); questi file possono anche essere installati in /usr/share/doc/NVIDIA_GLX-1.0/include/GL/. È possibile richiedere che questi file non siano inclusi in /usr/include/GL/ passando l'opzione "--no-opengl-headers" al file .run durante l'installazione. o Le librerie nvidia-tls (/usr/lib/libnvidia-tls.so.x.y.z e /usr/lib/tls/libnvidia-tls.so.x.y.z); questi file offrono supporto alla memorizzazione locale dei thread delle librerie NVIDIA OpenGL (libGL, libGLcore, e libglx). Ciascuna libreria nvidia-tls offre supporto a un modello particolare di archiviazione locale dei thread (quale ad esempio ELF TLS), e quello ideale per il proprio sistema viene caricato al runtime. o Il programma di installazione NVIDIA (/usr/bin/nvidia-installer) è lo strumento di NVIDIA per l'installazione e l'aggiornamento dei driver NVIDIA. Consultare il Capitolo 2 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, oltre ai 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 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*". Se le librerie risultano corrette, 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, eseguire: % 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) Verificare i file utilizzati per libGL e libGLcore -- se sono diversi dalle librerie NVIDIA, occorre rimuovere queste librerie o sistemare il percorso di ricerca ld usando la variabile di ambiente 'LD_LIBRARY_PATH'. Se questa procedura non vi è famigliare, consultare le pagine principali relative a "ldconfig" e "ldd". __________________________________________________________________________ Appendice D. Opzioni di X Config __________________________________________________________________________ Le seguenti opzioni driver sono supportate dal driver NVIDIA X: Queste possono essere specificate nelle sezioni Screen o Device del file config di X. Opzioni di X Config Opzione "NvAGP" "integer" Configurazione supporto AGP. L'argomento completo può essere uno dei seguenti: Valore Comportamento ----------------------------- ----------------------------- 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, il server X 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 K 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, oppure il server Xorg X. 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. Gli overlay della workstation RGB non sono supportati quando si abilita l'estensione Composite. 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. Gli overlay della workstation CI non sono supportati quando si abilita l'estensione Composite. 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 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 "RandRRotation" "boolean" Abilita il supporto della rotazione per l'estensione XRandR. Questa opzione permette di usare l'estensione del server X XRandR per la configurazione dell'orientamento dello schermo mediante la sua rotazione. La funzionalità è supportata su hardware GeForce2 o superiore usando la profondità 24. Questo richiede un server X XOrg 6.8.1 o più nuovo. Questa funzionalità non funziona con gli overlay hardware, al loro posto vengono invece utilizzati overlay emulati con una forte riduzione delle prestazioni. Consultare l'Appendice U per ulteriori dettagli. Preimpostazione: disattivata. Opzione "AllowDDCCI" "boolean" Abilita il supporto DDC/CI nell'estensione NV-CONTROL X. L'opzione DDC/CI è un meccanismo per la comunicazione tra il computer e il dispositivo di visualizzazione. Questo può essere utilizzato per impostare i valori normalmente controllati tramite l'On Screen Display del dispositivo di visualizzazione. Esaminare gli attributi DDC/CI NV-CONTROL di 'NVCtrl.h' e le funzioni di 'NVCtrlLib.h' nel codice sorgente 'nvidia-settings'. Preimpostazione: DDC/CI è 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 X 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 G 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 G 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 G 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 G 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 G 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 l'Appendice H per dettagli sulla configurazione di TV-out. Opzione "TVOutFormat" "string" Consultare l'Appendice H per dettagli sulla 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 l'Appendice H per dettagli sulla 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: Valore Attrezzatura ----------------------------- ----------------------------- 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 l'Appendice J 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. Quando si abilita lo stereo, si deve abilitare UBB (comportamento preimpostato). 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. Opzione "XvmcUsesTextures" "boolean" Forza XvMC a utilizzare il motore 3D per le richieste XvMCPutSurface invece dell'overlay video. Preimpostazione: l'overlay video viene utilizzato se disponibile. Opzione "AllowGLXWithComposite" "boolean" Abilita GLX anche quando è caricata l'estensione X Composite. ABILITARE QUESTA OPZIONE A PROPRIO RISCHIO E PERICOLO. In numerose circostanze, con questa impostazione abilitata, le applicazioni OpenGL non vengono visualizzate correttamente. Preimpostazione: quando Composite è caricato, GLX è disabilitato. Opzione "Coolbits" "integer" Abilita il supporto nell'estensione NV-CONTROL X per la manipolazione delle impostazioni dell'orologio della GPU. Se questa opzione viene impostata su "1" l'utility 'nvidia-settings' contiene una pagina intitolata "Clock Frequencies" che permette la manipolazione delle impostazioni dell'orologio. ATTENZIONE: questo può provocare danni al sistema e rendere nulle le garanzie. Questa utility può provocare l'esecuzione del sistema computerizzato al di fuori delle specifiche tecniche previste dal produttore, ad inclusione, ma senza limitarsi ad esse, di: tensioni di sistema superiori, temperature superiori alla norma, frequenze eccessive e variazioni al BIOS che possono danneggiarlo. Il sistema operativo del computer può bloccarsi e produrre perdite di dati o immagini danneggiate. A seconda del produttore del sistema computerizzato, questo può invalidare le garanzie sul sistema, sull'hardware e sul software e può annullare la possibilità di ricevere ulteriore assistenza dal produttore. NVIDIA non fornisce assistenza o servizio clienti per la sua opzione Coolbits. È per queste ragioni che non si offre alcuna garanzia di nessun tipo, sia esplicita che implicita. Prima di attivare e utilizzare questa funzione si dovrebbe determinare l'idoneità dell'utility al proprio scopo. L'uso della funzione comporta la piena assunzione di responsabilità in merito alle sue conseguenze. Opzione "LoadKernelModule" "boolean" Per opzione predefinita, il modulo del driver NVIDIA Linux X tenta di caricare il modulo del kernel Linux NVIDIA. Se si imposta su "off" questa opzione si disabilita automaticamente il caricamento del modulo del kernel di NVIDIA da parte del driver NVIDIA X. __________________________________________________________________________ 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 supercampionamento 4 2 x 2 supercampionamento 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 supercampionamento 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 supercampionamento 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 supercampionamento 7 2x Multicampionamento bilineare per 4x supercampionamento 8 4x Multicampionamento bilineare per 2x supercampionamento (disponibile nelle GPU GeForce FX e successive; non disponibile nelle GPU Quadro) FILTRAGGIO ANISOTROPO DELLA TEXTURE Il filtraggio anisotropo automatico della texture può essere abilitato impostando la variabile dell'ambiente __GL_LOG_MAX_ANISO. I valori possibili sono: GL_LOG_MAX_ANISO Tipo di filtraggio ------------------------------- ------------------------------- 0 Nessuno filtraggio anisotropo 1 2x filtraggio anisotropo 2 4x filtraggio anisotropo 3 8x filtraggio anisotropo 4 16x filtraggio anisotropo Le impostazioni 4X e superiori sono disponibili soltanto per le GPU GeForce3 o più recenti; l'impostazione 16x è disponibile soltanto per le GPU GeForce 6800 o più recenti. 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. Quando si usa __GL_SYNC_TO_VBLANK con TwinView, OpenGL può effettuare la sincronizzazione con una sola delle periferiche 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 della periferica di visualizzazione scelto: per esempio "CRT-1". Verificare l'istruzione "Connected display device(s):" nel file log X per un elenco delle periferiche 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. __________________________________________________________________________ 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 X Config: 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 l'Appendice M. 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. Chipset AGP supportati ------------------------------------------------- Intel 440LX Intel 440BX Intel 440GX Intel 815 ("Solano") Intel 820 ("Camino") Intel 830 Intel 840 ("Carmel") Intel 845 ("Brookdale") Intel 845G Intel 850 ("Tehama") Intel 855 ("Odem") Intel 860 ("Colusa") Intel 865G ("Springdale") Intel 875P ("Canterwood") Intel E7205 ("Granite Bay") Intel E7505 ("Placer") AMD 751 ("Irongate") AMD 761 ("IGD4") AMD 762 ("IGD4 MP") AMD 8151 ("Lokar") VIA 8371 VIA 82C694X VIA KT133 VIA KT266 VIA KT400 VIA P4M266 VIA P4M266A VIA P4X400 VIA K8T800 RCC CNB20LE RCC 6585HE Micron SAMDDR ("Samurai") Micron SCIDDR ("Scimitar") NVIDIA nForce NVIDIA nForce2 NVIDIA nForce3 ALi 1621 ALi 1631 ALi 1647 ALi 1651 ALi 1671 SiS 630 SiS 633 SiS 635 SiS 645 SiS 646 SiS 648 SiS 648FX SiS 650 SiS 655FX SiS 730 SiS 733 SiS 735 SiS 745 SiS 755 ATI RS200M Se si riscontrano problemi di stabilità di AGP, si dovrebbe tenere presente quanto segue: Informazioni supplementari sull'AGP 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" 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-x86-1.0-7664-pkg1.run --extract-only # cd NVIDIA-Linux-x86-1.0-7664-pkg1/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 abilitare il parametro "ReqAGPRate": - { NULL, "ReqAGPRate", &NVreg_ReqAGPRate, 0 }, + { NULL, "ReqAGPRate", &NVreg_ReqAGPRate, 1 }, Infine, occorre ricompilare e caricare il nuovo modulo kernel. 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. 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. Alcune delle prime revisioni di SBIOS della scheda madre ASUS A7V8X-X KT400 commettono un errore di configurazione del chipset quando si installa una scheda grafica AGP 2.x; se X si blocca su un sistema ASUS KT400 con Linux AGPGART o NvAGP abilitati e la scheda grafica installata non è di tipo AGP 8x, accertarsi di aver installato il SBIOS più recente. __________________________________________________________________________ Appendice G. 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, Quadro4, GeForce FX, o Quadro FX. 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 ciascuna periferica di visualizzazione come schermo X separato, consultare l'Appendice P. OPZIONI X CONFIG TWINVIEW per abilitare TwinView, occorre specificare le seguenti opzioni nella sezione Dispositivo del file X Config: Opzione "TwinView" Opzione "MetaModes" "" Occorre inoltre specificare una delle seguenti: Opzione "SecondMonitorHorizSync" "" Opzione "SecondMonitorVertRefresh" "" oppure Opzione "HorizSync" "" Opzione "VertRefresh" "" È inoltre possibile utilizzare una delle seguenti opzioni, sebbene non siano necessarie: Opzione "TwinViewOrientation""" Opzione "ConnectedMonitor" "" Consultare la descrizione dettagliata di ogni opzione, qui sotto: Descrizione dettagliata delle opzioni TwinView Questa opzione è necessaria per abilitare TwinView; senza di essa tutte le altre opzioni TwinView correlate vengono ignorate. 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"). HorizSync, VertRefresh Quale periferica di visualizzazione sia la "prima" e quale la "seconda" è spesso poco chiaro. Per questa ragione, è possibile usare queste opzioni al posto delle versioni SecondMonitor. Con queste opzioni, è possibile specificare una lista separata da punti e virgola delle gamme di frequenza, ciascuna corredata (facoltativamente) di un nome di periferica di visualizzazione. Per esempio: Opzione "HorizSync" "CRT-0: 50-110; DFP-0: 40-70" Opzione "VertRefresh" "CRT-0: 60-120; DFP-0: 60" Vedere l'appendice R sui nomi delle periferiche di visualizzazione per ulteriori informazioni. 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 nella periferica di visualizzazione 0 in modo concomitante con utilizzato sulla periferica di visualizzazione 1. Uno switch di modalità provoca quindi l'utilizzo di sulla periferica di visualizzazione 0 e sulla periferica di visualizzazione 1. Ecco una voce MetaMode effettiva da un file di configurazione X Config di esempio: Opzione "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768" Se si desidera che una periferica di visualizzazione non sia attiva 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 delle periferiche 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 X Config 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" Dato che spesso non è chiaro quale modalità di un MetaMode venga utilizzata su ciascuna periferica di visualizzazione, le descrizioni delle modalità all'interno di un MetaMode possono indicare un nome di periferica di visualizzazione. Per esempio: "CRT-0: 1600x1200, DFP-0: 1024x768" 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. 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. Dato che spesso è poco chiaro quale periferica di visualizzazione sia la "prima" e quale la "seconda", l'uso di TwinViewOrientation può risultare difficoltoso. È possibile chiarire ulteriormente TwinViewOrientation indicando i nomi delle periferiche di visualizzazione per specificare le reciproche posizioni relative di questi dispositivi. Per esempio: "CRT-0 LeftOf DFP-0" 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). I valori validi sono un elenco, separato da virgole, di periferiche di visualizzazione; per esempio: "CRT-0, CRT-1" "CRT" "CRT-1, DFP-0" AVVERTENZA: questa opzione ignora le periferiche di visualizzazione rilevate dal modulo kernel NVIDIA ed è necessaria molto raramente. Si tratta di un'opzione necessaria soltanto se non si riesce a rilevare una periferica di visualizzazione, sia perché non sono disponibili le sue informazioni DDC, o perché è sul lato opposto di un interruttore KVM (Tastiera-Video-Mouse). Nella maggior parte degli altri casi, è meglio non specificare questa opzione. Come per tutte le immissioni X Config, 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. È necessario comunicare esplicitamente al driver NVIDIA X che si è realizzata una connessione usando l'opzione "ConnectedMonitor"; 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 X Config "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 del server X di Xinerama. La specificazione esplicita di Xinerama nel file X Config o nella riga di comando del server X impedisce l'installazione dell'estensione Xinerama di NVIDIA, quindi è necessario verificare che il file log del server X 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 l'Appendice P. 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. __________________________________________________________________________ APPENDICE H. 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 X Config: 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 log X (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 log X. In genere, sono supportate almeno le modalità 800x600 e 640x480. o L'opzione "TVStandard" può essere aggiunta alla sezione schermo; valori validi sono: __GL_FSAA_MODE GeForce FX, Quadro FX ----------------------------- ----------------------------- "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 "HD480i" 480 righe interlacciato "HD480p" 480 righe progressivo "HD720p" 720 righe progressivo "HD1080i" 1080 righe interlacciato "HD1080p" 1080 righe progressivo "HD576i" 576 righe interlacciato "HD576p" 576 righe progressivo La riga del file X Config 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 X 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. __________________________________________________________________________ Appendice I. 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: Valore Significato -------------------------------------------------------------- 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 In questa sezione vengono trattate le funzionalità addizionali presenti nelle configurazioni dei PC portatili. TWINVIEW Tutti i processori mobili NVIDIA supportano TwinView. TwinView, su un portatile, può essere configurato nello stesso modo che su un PC desktop (consultare l'Appendice G 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 X Config) 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 X Config (ciò deve essere effettuato solo se si può fare affidamento sugli EDID riportati della periferica di visualizzazione-consultare la descrizione dell'opzione UseEdidFreqs nell'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 X Config, e la funzione hotkey sono reciprocamente esclusive - se si abilita TwinView nel file X Config 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 X Config 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 Ci sono alcuni problemi noti associati ai laptop. 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. __________________________________________________________________________ Appendice J: 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. Le modalità interlacciate sono supportate da tutte le GPU GeForce FX/Quadro FX o più recenti, oltre che da alcune delle meno recenti; se le modalità interlacciate sono supportate, il file X log contiene il messaggio "Interlaced video modes are supported on this GPU". 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 X Config (consultare la pagina principale XF86Config(5x) o xorg.conf(5x) 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 X. 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 log X 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 X Config 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 X Config, 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 X Config). Vengono applicati diversi altri vincoli; vedi 'xc/programs/Xserver/hw/xfree86/common/xf86Mode.c':xf86ValidateModes(). o Tutte 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 X Config. o Tutte 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 dei processori. La risoluzione orizzontale (HR) deve essere un multiplo di 8 e uguale o inferiore al valore della tabella sottostante. 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. La sync start orizzontale (HSS) deve essere un multiplo di 8 e uguale o inferiore al valore della tabella sottostante. 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. La lunghezza frame orizzontale (HFL) deve essere un multiplo di 8 e uguale o inferiore al valore della tabella sottostante. La lunghezza frame orizzontale (HFL) deve essere un multiplo di 8 e uguale o inferiore al valore della tabella sottostante. La risoluzione verticale (VR) deve essere uguale o inferiore al valore della tabella sottostante. 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. Sync start verticale (VSS) deve essere uguale o inferiore al valore della tabella sottostante. L'ampiezza sync verticale (sync end verticale meno sync start verticale (Vse - VSS)) deve essere uguale o inferiore al valore della tabella sottostante. La lunghezza frame verticale (VFL) deve essere maggiore o uguale a 2 e uguale o inferiore al valore della tabella sottostante. 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 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 entrambe le periferiche di visualizzazione stiano impiegando la stessa modalità, occorre solo accertarsi che entrambe 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 X Config, definire una MetaMode simile alla seguente: Option "MetaModes" "1024x768_120, 1024x768_120" INFORMAZIONI AGGIUNTIVE 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. __________________________________________________________________________ Appendice K. 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. 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 X Config 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. 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. __________________________________________________________________________ Appendice L. Problemi noti __________________________________________________________________________ I seguenti problemi non sono stati risolti con la corrente release e sono tuttora in corso di soluzione. Problemi noti 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 il Capitolo 4 per ulteriori dettagli. 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 l'Appendice D per ulteriori dettagli. 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 l'Appendice C 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. La piattaforma Intel EM64T e SWIOTLB Al momento Linux non fornisce un meccanismo per l'assegnazione della memoria con indirizzi che rientrino nei primi 4 Giga di memoria della piattaforma Intel EM64T. Gli indirizzi all'interno di questa gamma sono necessari all'hardware PCI a 32 bit per fornire capacità DMA. Al contrario, il kernel di Linux fornisce un TLB di I/O software in grado di aggirare questo problema. Sfortunatamente, questo tipo di soluzione crea altri problemi. Le prime implementazioni di SWIOTLB mettono da parte una piccolissima quantità di memoria che va a comporre un pool specifico (4 Megabyte). Inoltre, quando la memoria di questo pool viene esaurita, il kernel entra forzatamente in stato di panic. Lo stato di panic del kernel e i problemi di stabilità correlati possono essere evitati aumentando le dimensioni di questo pool di memoria. Questo può essere effettuato grazie alla riga di comando del kernel, con l'opzione "swiotlb=". Si suggerisce di aumentare le dimensioni del pool a 32 Megabyte quando si usa il driver NVIDIA. Per ottenere questo incremento, inviare al kernel il valore "swiotlb=16384". A partire dal kernel 2.6.9 di kernel.org, le dimensioni predefinite di SWIOTLB sono state incrementate a 64 Megabyte e si è migliorata la gestione degli overflow. Queste due soluzioni hanno nettamente migliorato la stabilità, quindi sono caldamente raccomandate. Si tenga inoltre conto dei problemi di stabilità noti per questa piattaforma. o Piattaforma X86-64 (AMD64/EM64T) e kernel 2.6 Molti kernel 2.4 e 2.6 x86_64 hanno un problema di conteggio nella loro implementazione dell'interfaccia del kernel change_page_attr. I primi kernel 2.6 includono un controllo che attiva un BUG() quando si incontra questa situazione (l'attivazione di un BUG() produce l'interruzione dell'applicazione corrente nel kernel; potrebbe trattarsi dell'applicazione opengl aperta o persino del server X). Il problema di conteggio è stato risolto nel kernel 2.6.11. Abbiamo aggiunto verifiche che consentono di riconoscere il modulo del kernel NVIDIA che viene compilato per la piattaforma x86-64 su un kernel compreso tra 2.6.0 e 2.6.11. In tal caso, disabilitiamo l'utilizzo dell'interfaccia del kernel change_page_attr. Questo permette di evitare il problema di conteggio ma fa correre al sistema il rischio di incorrere in problemi di cache-aliasing (vedere la voce sul Cache aliasing per ulteriori informazioni in merito). Il cache-aliasing può portare a danni ai dati e blocchi casuali del sistema. I problemi causati sono difficili da riprodurre. Si noti che il problema di conteggio di change_page_attr e BUG() possono essere scatenati da altri sottosistemi del kernel che si affidano a questa interfaccia. Se si utilizza un kernel 2.6 x86_64, si raccomanda l'aggiornamento a un kernel 2.6.11 o successivo. Aliasing della cache L'aliasing della cache si verifica quando molteplici mappature di una pagina fisica di memoria hanno stati della cache in conflitto fra loro, quali in cache e non in cache. A causa di questi stati in conflitto, i dati in quella pagina fisica possono risultare danneggiati quando la cache del processore viene svuotata. Se quella pagina viene utilizzata per il dma da un driver quale ad esempio il driver grafico NVIDIA, questo può portare a problemi di stabilità hardware e blocchi del sistema. NVIDIA ha riscontrato la presenza di bug che possono portare all'aliasing della cache in alcune versioni di kernel Linux. Sebbene alcuni sistemi non abbiano il benché minimo problema quando si verifica l'aliasing della cache, altri invece subiscono seri problemi di stabilità e persino blocchi casuali. Gli utenti che riscontrano problemi di stabilità dovuti all'aliasing della cache possono risolverli passando a un kernel che non crea questa condizione. NVIDIA ha aggiunto al driver una logica che rileva l'aliasing della cache e stampa un avvertenza con un messaggio simile a quanto segue: NVRM: bad caching on address 0x1cdf000: actual 0x46 != expected 0x73 Se nei vostri file log compare questo messaggio e state subendo problemi di stabilità, dovreste aggiornare il kernel alla versione più recente. Se il messaggio persiste anche dopo l'aggiornamento del kernel, inviare un bug report a NVIDIA, 64-Bit BAR (Base Address Registers) A partire dalle GPU con PCI Express nativo, le GPU NVIDIA offrono una capacità BAR a 64 bit (un Base Address Register archivia la locazione di una regione di I/O PCI, come i registri o un framebuffer). Questo significa che le regioni di I/O PCI di una GPU (registri e framebuffer) possono essere posizionate sopra lo spazio di indirizzamento a 32 bit (i primi 4 Gigabyte di memoria). La decisione di dove collocare la BAR è presa dal BIOS di sistema al momento del boot. Se il BIOS supporta BAR a 64 bit, allora le regioni I/O PCI NVIDIA possono essere collocate sopra lo spazio di indirizzamento a 32 bit. Se il BIOS non supporta questa funzionalità, allora le regioni I/O PCI vengono collocate all'interno dello spazio di indirizzamento a 32 bit come in precedenza. Sfortunatamente, gli attuali kernel di Linux (alla versione 2.6.11.x) non comprendono o supportano le BAR a 64 bit. Se il BIOS colloca qualsiasi I/O PCI NVIDIA sopra lo spazio di indirizzamento a 32 bit, il kernel respinge la BAR e il driver NVIDIA non funziona. Al momento, non ci sono soluzioni note, neppure estemporanee. Portatili Se si sta usando un portatile, si consiglia di consultare la sezione "Problemi noti dei portatili" nell'Appendice I. 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. libGL DSO finalizer e pthread Quando esiste un'applicazione OpenGL in multithreading, è possibile che venga invocato libGL DSO finalizer (noto anche come il distruttore, o "_fini") mentre gli altri thread stanno eseguendo il codice OpenGL. Il finalizer necessita che libGL gli assegni risorse libere. Questo può causare problemi ai thread che stanno ancora utilizzando queste risorse. L'impostazione della variabile ambientale "__GL_NO_DSO_FINALIZER" su "1" funziona da soluzione empirica al problema costringendo libGL finalizer a lasciare in posizione le sue risorse. Queste risorse verranno comunque recuperate dal sistema operativo alla fine dell'esecuzione del processo. Si noti che il finalizer viene eseguito anche come parte di dlclose(3), quindi se si dispone di un'applicazione che opera dlopens(3) e dlcloses(3) di libGL reiteratamente, "__GL_NO_DSO_FINALIZER" fa sì che libGL perda risorse sino alla fine dell'esecuzione del processo. L'uso di questa opzione può migliorare la stabilità di alcune applicazioni in multithreading, incluse le applicazioni Java3D.. XVideo e l'estensione X Composite XVideo non funziona correttamente quando Composite è abilitato. Consultare l'Appendice S. 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: Problemi che non sono stati risolti 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. 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. 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. 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 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. __________________________________________________________________________ Appendice M. 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. /proc/driver/nvidia/version Elenca la revisione del driver installato e la versione del compilatore GNU C utilizzato per creare il modulo kernel Linux. /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. /proc/driver/nvidia/agp/card Le informazioni sulle capacità AGP della scheda installata. /proc/driver/nvidia/agp/host-bridge Le informazioni sul bridge host (modello e capacità AGP). /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. __________________________________________________________________________ Appendice N. Supporto XVMC __________________________________________________________________________ La presente release include il supporto di X-Video Motion Compensation (XvMC) versione 1.0 API per GeForce4 e GeForce FX e prodotti più nuovi. Esiste una libreria statica "libXvMCNVIDIA.a" e una dinamica "libXvMCNVIDIA_dynamic.so" che è adatta alle operazioni di dlopening. I prodotti GeForce4 MX, GeForce FX e prodotti più nuovi 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. __________________________________________________________________________ Appendice O. 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à. __________________________________________________________________________ Appendice P. Configurazione di più schermi X su una sola scheda __________________________________________________________________________ I processori grafici che supportano TwinView (vedere l'Appendice G) 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(5x) oppure xorg.conf(5x). __________________________________________________________________________ Appendice Q. 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, mentre non supporterà la funzione di standby. Il BIOS di sistema del laptop deve supportare APM, invece di ACPI. Molti, ma non tutti, dei laptop basati su GeForce2 e GeForce4 includono il supporto di APM. È possibile verificare il supporto APM per mezzo dell'interfaccia procfs (verificare l'esistenza di /proc/apm) o mediante l'output di boot del kernel: % dmesg | grep -i apm un messaggio simile a questo indica il supporto di apm: apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16) in alternativa, un messaggio di questo tipo indica l'assenza di supporto apm: No APM support in Kernel Sebbene il supporto ACPI sia sempre più frequentemente presente nei kernel di sviluppo ed esistano alcune patch retroportate per i kernel 2.4, il driver grafico NVIDIA non fornisce ancora il supporto per ACPI. Il reparto tecnico NVIDIA spera di portare a termine lo sviluppo di questo supporto nel prossimo futuro. Si noti che lo standby non è supportato, ma che il kernel tenterà di accedere allo standby se viene istruito in tal senso. Quando si modificano i livelli di alimentazione, numerosi servizi del sistema vengono avvisati del cambiamento per consentire loro di gestirlo correttamente. Per esempio, il networking viene disabilitato prima della sospensione, quindi riabilitato alla ripresa dell'attività. Quando il kernel tenta di accedere allo standby, il BIOS fallisce il tentativo. Il kernel stampa il messaggio di errore "standby: Parameter out of range", ma non riesce a notificare ai servizi del sistema il guasto. 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 nell'accedere alla sospensione e quindi riprendere. Il supporto della gestione dell'alimentazione è ancora in corso di sviluppo e si tratta di una funzionalità beta. Di conseguenza, alcune funzionalità sono tuttora assenti o inaffidabili. I problemi noti includono: Talora i chipset perdono la propria configurazione AGP durante la sospensione, e possono provocare danni al bus al momento della ripresa. Il driver AGP è necessario per salvare e ripristinare lo stato pertinente del registro di questi sistemi; NvAGP di NVIDIA viene avvertito degli eventi di gestione dell'alimentazione e garantisce che la configurazione venga mantenuta intatta sui cicli di sospensione/ripresa. Linux 2.4 AGPGART non supporta la gestione dell'alimentazione, mentre Linux 2.6 AGPGART sì, anche se soltanto per alcuni chipset selezionati. Se si usa uno dei due driver AGP e si scopre che il sistema non riesce a operare operazioni di ripresa affidabili, si può avere maggiore successo con il driver NVIDIA NvAGP. La disabilitazione del supporto AGP (consultare l'Appendice F per ulteriori dettagli sulla disabilitazione dell'AGP) consente di prevenire questo problema. Per ACPI, al momento è supportato solo S3 "Suspend to Ram". Questo significa che S4 "Suspend to Disk", altrimenti noto come "Software Suspend" o "swsusp" al momento non è del tutto affidabile. __________________________________________________________________________ Appendice R. Nomi delle periferiche di visualizzazione __________________________________________________________________________ "Periferica di visualizzazione" si riferisce ad alcuni dispositivi hardware in grado di consentire la visualizzazione di immagini. Le periferiche di visualizzazione si dividono in tre categorie principali: CRT analogici, schermi piatti (DFP) e Televisori. Si noti che gli schermi piatti analogici sono considerati identici ai CRT analogici per quanto riguarda il driver. "Nome della periferica di visualizzazione" è una stringa descrittiva che identifica in modo univoco una periferica di visualizzazione; questa segue il formato "-", per esempio: "CRT-0", "CRT-1", "DFP-0", o "TV-0". Si noti che il numero indica semplicemente l'ordine di collegamento del dispositivo alla scheda grafica, e non ha niente a che vedere con il numero di dispositivi effettivamente presenti. Questo significa, per esempio, che si può avere un "CRT-1" anche se non è presente alcun "CRT-0". Per determinare quali periferiche di visualizzazione siano attualmente collegate, è possibile verificare il proprio file log X per un'istruzione come questa: (II) NVIDIA(0): Periferiche di visualizzazione connesse: CRT-0, DFP-0 I nomi delle periferiche di visualizzazione connesse possono essere utilizzati con le opzioni di configurazione MetaMode, HorizSync e VertRefresh X per indicare a quali periferiche di visualizzazione si debba applicare un'impostazione. Per esempio: Opzione "MetaModes" "CRT-0: 1600x1200, DFP-0: 1024x768" Opzione "HorizSync" "CRT-0: 50-110; DFP-0: 40-70" Opzione "VertRefresh" "CRT-0: 60-120; DFP-0: 60" La specifica del nome della periferica di visualizzazione in queste opzioni non è necessaria; se si procede a questa specifica, allora il driver tenta di interpretare a quale dispositivo si debba applicare ogni specifica impostazione. Nel caso dei MetaModes, per esempio, la prima modalità elencata si applica alla "prima" periferica di visualizzazione, mentre la seconda modalità elencata si applica alla "seconda" periferica di visualizzazione. Sfortunatamente, è spesso poco chiaro quale periferica di visualizzazione sia la "prima" o la "seconda". Ecco perché è preferibile specificare il nome della periferica di visualizzazione. Quando si specificano i nomi delle periferiche di visualizzazione, è inoltre possibile omettere il numero di parte del nome, sebbene questo sia utile soltanto se dispone di un solo elemento di quella particolare periferica di visualizzazione. Per esempio, se si dispone di un CRT e di un DFP connessi, si può fare riferimento ad essi nella stringa MetaMode nel modo seguente: Opzione "MetaModes" "CRT: 1600x1200, DFP: 1024x768" __________________________________________________________________________ Appendice S. L'estensione X composite __________________________________________________________________________ X.org versione X11R6.8.0 contiene il supporto sperimentale per una nuova estensione del protocollo X chiamata Composite. Questa estensione consente di disegnare le finestre in pixmap invece che direttamente a schermo. Unitamente alle estensioni DAMAGE e RENDER, questo consente a un programma denominato Composite Manager di fondere le finestre nell'aggiornamento della schermata. Si possono migliorare le prestazioni abilitando l'opzione "RenderAccel" di xorg.conf. Consultare l'Appendice D per ulteriori dettagli. Il pieno supporto di Composite richiede il supporto di altri driver. Al momento, i client di rendering diretto quali GLX non hanno modo di interpretare correttamente l'istruzione di rendering su una pixmap, quindi disegnano direttamente a schermo. I tecnici NVIDIA stanno cercando di scoprire cosa occorra a questi client per interoperare in senza problemi con Composite. Nel frattempo, quando si rileva l'estensione Composite, GLX viene disabilitato per opzione predefinita. Si è comunque fornita l'opzione di riattivarlo. Consultare l'Opzione "AllowGLXWithComposite" nell'Appendice D. Questo problema è stato discusso nella mailing list xorg: http://freedesktop.org/pipermail/xorg/2004-May/000607.html Composite provoca inoltre problemi con altri componenti driver: Xv non può tracciare pixmap che sono state reindirizzate fuori schermo e, al contrario, le disegna direttamente a schermo. In alcuni programmi è possibile risolvere in modo empirico questo problema utilizzando un driver video alternativo. Per esempio, "mplayer -vo x11" funziona correttamente, così come "xine -V xshm". Se si intende utilizzare Xv, è possibile semplicemente disabilitare il manager di composizione e riabilitarlo al termine dell'operazione. Gli overlay della workstation sono incompatibili con Composite. Altre informazioni su Composite sono reperibili all'indirizzo: http://freedesktop.org/Software/CompositeExt __________________________________________________________________________ Appendice T. L'utility nvidia-settings __________________________________________________________________________ Un'utility di configurazione grafica, 'nvidia-settings', è inclusa nel driver grafico per Linux di NVIDIA. Dopo l'installazione del driver e l'avvio di X, è possibile eseguire questa utility di configurazione eseguendo: nvidia-settings in una finestra terminale. Informazioni dettagliate sulle opzioni di configurazione disponibili sono documentate nella finestra di aiuto dell'utility. Per ulteriori informazioni, vedere la guida dell'utente: ftp://download.nvidia.com/XFree86/Linux-x86/nvidia-settings-user-guide.txt Il codice sorgente di nvidia-settings è stato reso disponibile come GPL: ftp://download.nvidia.com/XFree86/nvidia-settings/ __________________________________________________________________________ Appendice U. L'estensione X XRandR __________________________________________________________________________ X.org versione X11R6.8.1 contiene il supporto per il componente di rotazione dell'estensione XRandR. Questo componente consente la rotazione degli schermi per incrementi di 90 gradi. Il driver inizia a supportare la rotazione non appena si abilita una l'opzione "RandRRotation" nel file di configurazione di X. Quando l'opzione RandRRotation è abilitata, gli overlay visuali RGB o CI della workstation offrono prestazioni ridotte. L'overlay video non è disponibile con l'opzione RandRRotation abilitata. L'interfaccia della riga di comando dell'estensione RandR consente di effettuare una query delle rotazioni disponibili usando: xrandr -q Questo consente di impostare l'orientamento della rotazione dello schermo con le opzioni: xrandr -o left xrandr -o right xrandr -o inverted xrandr -o normal È inoltre possibile impostare la rotazione mediante l'utility di configurazione nvidia-settings, dal pannello "Rotation Settings". Si noti che al momento la rotazione non è supportata con TwinView attivo. __________________________________________________________________________ Appendice V. Supporto per il GLX in Xinerama __________________________________________________________________________ Questo driver supporta il GLX quando è abilitato si GPU analoghe. L'estensione Xinerama prende più schermi X fisici (anche estesi su più GPU) e li lega in un unico schermo X logico. Questo permette di trascinare finestre tra le GPU e di estenderle su più GPU. Il driver NVIDIA supporta il rendering OpenGL ad accelerazione hardware su tutte le GPU NVIDIA quando si abilita Xinerama. Per configurare Xinerama: configurare più schermi X (fare riferimento alle pagine su XF86Config(5x) o xorg.conf(5x) per ulteriori dettagli). L'estensione Xinerama può essere abilitata aggiungendo la riga Option "Xinerama" "True" alla sezione "ServerFlags" del file X Config. Requisiti: Si consiglia di usare GPU identiche. Sono supportate anche alcune combinazioni di GPU non identiche ma simili. Se una GPU è incompatibile con il resto di un desktop Xinerama allora non compare alcun rendering OpenGL sugli schermi gestiti da quella GPU. Il rendering comunque appare normalmente sugli schermi collegati alle altre GPU supportate. In questa situazione il file X log include un messaggio nella forma: (WW) NVIDIA(2): La GPU che gestisce lo schermo 2 è incompatibile con il resto (WW) NVIDIA(2): delle GPU che compongono il desktop. Il rendering OpenGL è (WW) NVIDIA(2): disabilitato sullo schermo 2. Il driver NVIDIA X deve essere utilizzato su tutti gli schermi di X del server. Solo l'intersezione delle capacità di tutte le GPU viene utilizzata. Le opzioni di configurazione di X che hanno effetto sul funzionamento di GLX (per esempio: stereo, overlay) vanno impostate in modo congruente su tutti gli schermi X del server X. Problemi noti: Le dimensioni massime renderizzabili della finestra sono pari a 4096 pixel. Le versioni di XFree86 precedenti alla 4.5 e le versioni di X.org precedenti alla 6.8.0 mancano delle interfacce necessarie per implementare correttamente gli overlay con l'estensione Xinerama. Nelle versioni precedenti dei server il mixaggio di overlay e Xinerama dava luogo a problemi di rendering. Se si utilizza l'estensione Xinerama con gli overlay, si consiglia di passare a XFree86 4.5, X.org 6.8.0, o a versioni successive