Estratto
Questo documento intende aiutare gli utenti di Gentoo Linux ad installare ed usare i driver binari forniti da ATI.
Ultimo aggiornamento: 29/07/06
Al momento, i driver binari ATI sono i soli che supportano l'accelerazione 3D su schede basate si chipset R3xx e R4xx. Queste includono le schede più recenti come le serie 9500, 9600, 9700 e 9800 più i chipset mobility (per i portatili) e le schede serie X.
Su r300.sourceforge.net stanno lavorando per sviluppare un driver open source per i chipset Radeon. Si può provare questo driver con la consapevolezza che è ancora in fase di sviluppo e che si possono incontrare seri problemi.
Tutte le versioni più recenti dei driver si possono trovare nell'albero del portage, sotto la categoria x11-drivers/ati-drivers. Si noti che le versioni più recento possono essere marcate come non stabili (~x86). Per emergere queste versioni, assumendo che non si stia già lavorando su un sistema ~x86, si dovrebbe fare ciò che segue:
# mkdir -p /etc/portage # echo "x11-drivers/ati-drivers ~x86" >> /etc/portage/package.keywords
In questo modo si dovrebbe essere in grado di emergere tutte le versioni dei driver, a meno che non siano hardmasked per qualche ragione.
Si possono scaricare i driver anche dal sito della ATI allo stesso modo dei driver per Windows. Si vada su http://www.ati.com/support/driver.html e si selezioni Linux dalla prima colonna. Scegliere quindi Graphic Driver dalla seconda colonna. Selezionare il tipo di scheda corretto dall'ultima colonna e cliccare sul pulsante Go per ottenere la pagina di download.
La lista che segue delle schede supportate è presa direttamente dalle note sulla release della versione 8.27.10 del driver (http://www2.ati.com/drivers/linux/linux_8.27.10.html). Il supporto per PCIe è disponibile in tutti i driver a partire dalla versione 3.14.1.
Nota
Vecchie schede ATI dovrebbero essere supportate dai driver opensource "radeon" e "ati" che vengono forniti come parte di XFree e Xorg. Da notare inoltre che se si usa una vecchia versione del driver, questo potrebbe non supportare tutte le schede elencate sopra. Se si possiede una nuova scheda che non è elencata qui, potrebbe essere possibile utilizzare lo stesso i driver con le techiche descritte nella sezione La scheda video non viene riconosciuta dal driver.
Le schede PCIe sono supportate in tutte le versioni più recenti del driver come menzionato nel paragrafo Quali schede sono supportate dal driver. Schede PCI sono apparentemente supportate (p.e. R9200 PCI) anche se alcuni utenti hanno avuto grosse difficoltà tentando di far funzionare i driver con tali schede. Un'alternativa possibile se si è in questa situazione è di usare i driver opensource radeon.
Di solito è meglio usare la versione del driver più recente (correntemente la 8.27.10). Vecchie versioni sono disponibili in portage se si hanno problemi con le nuove release. Per emergere una vecchia versione, usare il seguente comando emerge: emerge =ati-drivers-3.2.8-r1. Questo comando istruisce portage di installare la specifica versione del pacchetto invece dell'ultima versione disponibile.
Qualche volta, l'ultima versione del driver non è disponibile se si sta usando un sistema "stabile" (con ACCEPT_KEYWORDS="x86" invece di ~x86 , amd64 invece di ~amd64). Se questa è la propria situazione e si vuole installare l'ultima versione del driver (questo può essere necessario se si possiede una nuova scheda non supportata dai vecchi driver), si dovrebbe usare il file /etc/portage/package.keywords per rendere unmask in modo selettivo pacchetti rilevanti (eselect, eselect-opengl, ati-drivers, ati-driver-extra). Per esempio, per installare i pacchetti ati-drivers e ati-driver-extra su un sistema x86, si dovrebbero aggiungere le seguenti due righe a /etc/portage/package.keywords (creare la directory ed il file se non esistono ancora):
x11-drivers/ati-drivers ~x86 x11-drivers/ati-drivers-extra ~x86
Il driver radeon supporta tutte le schede Radeon recenti, ma non supporta l'accelerazione 3D per le nuove schede (generalmente quelle basate su chipset R300/R350 e superiori come la 9600 e la 9800). Per altre schede, come la R8500, R9000 o R9200, l'accelerazione 3D dovrebbe essere supportata, così che si può usare in alternativa al driver binario ATI. Come menzionato nel paragrafo Quali schede sono supportate dal driver, vengono supportate vecchie schede che i driver ATI non supportano. Per maggiori informazioni, si vedano le pagine di manuale per il driver (man radeon).
L'output del comando dmesg.
Provare anche ad eseguire glxinfo dopo aver esportato la variabile LIBGL_DEBUG=verbose. Questo produrrà maggiore output che può essere utile per la diagnosi del problema. La configurazione di LIBGL_DEBUG causerà anche la visualizzazione di maggiore output da parte di giochi ed applicazioni (come Celestia), così che potrebbe essere utile se si hanno problemi con un particolare gioco.
Il logfile di XFree: /var/log/Xorg.0.log (o /var/log/XFree86.0.log se si sta ancora usando XFree)
La soluzione migliore è, probabilmente, eseguire alcuni timedemo di un gioco come Unreal Tournament 2004 o Quake 3 (entrambi hanno demo free che possono essere usate). Da non usare la ben conosciuta applicazione glxgears per misurazioni accurate delle performance. Non è stata progettata per essere un benchmark.
Sì. HasW un utente Gentoo ha scritto un tool per overclokkare una Radeon. Si veda il thread su questo forum.
Sì, basta seguire le istruzioni che seguono e rinominare il file di configurazione prodotto da fglrxconfig in /etc/X11/xorg.conf.
Dato che i driver ATI non forniscono molta documentazione, è partito un progetto per produrre una raccolta completa delle pagine di manuale per i driver e le applicazioni associate (p.e. aticonfig, fgl_glxgears). Il progetto è mantenuto su http://cvs.wgdd.de/cgi-bin/cvsweb/fglrx_man/. Anche se è destinato ad utenti Debian, le informazioni si possono applicare anche ad altre distro come Gentoo. Attualmente stanno cercando contributi specialmente per la pagina di manuale di "fglrx".
Le seguenti opzioni del kernel devono essere impostate correttamente:
Loadable module support -> Enable loadable module support: ABILITATO
Loadable module support -> Module unloading: ABILITATO
Loadable module support -> Automatic kernel module loading: ABILITATO
Le tre opzioni summenzionate sono generalmente abilitate in molti kernel, ma dato che non sarebbe possibile caricare nessun modulo senza di loro, esse sono richieste per usare i driver ATI.
Bus options (PCI, PCMCIA, EISA, MCA, ISA) -> PCI Express support: ABILITATO (solo se si ha una scheda PCIe)
File systems -> Pseudo filesystems -> Virtual memory file system support: ABILITATO
Processor type and features -> MTRR (Memory Type Range Register) support: ABILITATO
Il supporto MTRR dovrebbe essere sempre abilitato, altrimenti il driver, se funziona, potrebbe avere prestazioni pessime.
Nota
Su alcuni chipset AMD64, si dovrebbe disabilitare MTRR per poter abilitare il supporto AGP senza il quale il driver non completerà la compilazione. Chipset conosciuti per questo problema sono: NVIDIA nForce3 Go150.
Device drivers -> Character Devices -> /dev/agpgart (AGP Support): ABILITATO o MODULO (se non lo si compila come modulo, si dovrà impostare "UseInternalAGPGART" a "no" nel file XF86Config)
Questa opzione abilita il supporto AGP nel kernel che di solito è corretto avere :)
Device drivers -> Character Devices -> (selezionare il chipset AGP corretto dalla lista a seconda della propria scheda madre): ABILITATO o MODULO.
Esempi:
Motherboard: nVidia nForce2 based ---- NVIDIA nForce/nForce2 chipset support
Motherboard: VIA KT266/333/400 based ---- VIA chipset support
Importante
L'opzione ATI AGP non è normalmente richiesta in sistemi con una scheda AGP standard. Vedere E' necessario selezionare l'opzione del kernel "ATI chipset support" avendo una scheda ATI?.
Importante
La compilazione di questa opzione come modulo è possibile solo con kernel della serie 2.6.
Questa opzione non è richiesta e preverrà la non operabilità del driver se abilitata.
Nota
In kernel della serie 2.4, la categoria Device drivers dove si trovano di solito i tre parametri precedenti, non esiste. Si trovano invece nella sezione Character devices.
Nota
Se si ha una scheda PCIe, i parametri AGP sono irrilevanti. Se si incontrano problemi, ci si assicuri di usare kernel recenti ed almeno l'ultima versione dei driver. Alcuni utenti hanno riportato di aver dovuto abilitare AGP per far funzionare al meglio le proprie schede PCIe.
Gli utenti di architettura AMD64 che stanno usando un kernel a 32 dovrebbero seguire l'avviso summenzionato. Se si sta usando una scheda AGP, si dovrebbe inoltre selezionare il supporto Device drivers -> Character Devices -> AMD Opteron/Athlon64 on-CPU GART. Se lo si compila come modulo questo sarà chiamato amd64-agp e dovrebbe essere caricato prima del modulo fglrx (vedere Installazione dei driver). Se si sta usando una scheda PCIe, come summenzionato, non dovrebbe essere necessario abilitare l'AGP, ma potrebbe essere necessario provarlo se si hanno problemi.
Se si sta usando un kernel a 64 bit, dovrebbero essere abilitati automaticamente il supporto /dev/agpgart e AMD Opteron/Athlon64 on-CPU GART (da non modificare).
Tutte le versioni dei driver nell'albero del portage dovrebbero essere compatibili con i kernel 2.4.x. Le versioni dalla 2.9.13-r1 a seguire dovrebbero funzionare anche con i kernel 2.6. Non ci sono invece garanzie che la compilazine del driver avvenga senza problemi con kernel molto patchati. E' impossibile per ATI testare i driver con ognuna della svariate versioni di kernel disponibile. Se si vuole eseguire l'ultimo nitro/mm/love/ck/cko-sources o qualsiasi altro kernel personalizzato, l'avvertimento è che ci si potrebbe trovare il driver non funzionante in qualche sua parte. Questo potrà risultare in una compilazione fallita o nell'impossibilità di caricare il modulo fglrx nel kernel. In molti casi si può trovare la patch per risolvere tali problemi sui forum di Gentoo o Rage3D, ma non si si faccia troppo affidamento su questo. Se non si riesce a risolvere il problema e non si trova una patch, si dovrebbe passare ad una versione di kernel precedente.
No, di solito non è necessario abilitare questa opzione. Se si legge l'help dell'opzione, si vedrà: "This option gives you AGP support for the GLX component of XFree86 4.x on the ATI Radeon IGP family of chipsets". ("Questa opzione fornisce il supporto AGP per il componente GLX di XFree84 4.x sui chipset della famiglia ATI Radeon IGP"). In altre parole, non è necessario abilitare questa opzione a meno che non si possieda in chipset grafico integrato IGP. Con una normale scheda AGP si ignori questa opzione.
Nota
Le seguenti istruzioni si basano sulla guida postata originariamente nel seguente thread del forum di Gentoo: http://forums.gentoo.org/viewtopic.php?t=73260.
Il primo passo per installare i driver è configurare il kernel in modo appropriato come visto in precedenza.
Controllare quindi che il link simbolico /usr/src/linux punti alla directory contenente i sorgenti del kernel corrente. Se non si è sicuri della versione del kernel in uso, eseguire uname -r che mostrerà la versione. Per esempio, se si sta utilizzando il kernel 2.6.1, ls -l /usr/src/linux dovrebbe mostrare:
lrwxrwxrwx 1 root root 26 Feb 6 14:19 /usr/src/linux -> /usr/src/linux-2.6.1
Se il link è corretto proseguire col prossimo passo, altrimenti, eseguire:
# rm -f /usr/src/linux # ln -s /usr/src/linux-`uname -r` /usr/src/linux
che ricreerà il link per puntare alla directory dei sorgenti corretti del kernel.
Se si sono modificate delle opzioni del kernel al passo 1, si dovrà ricompilare il kernel e riavviare la macchina. Per ricompilare il kernel eseguire i seguenti comandi nella directory /usr/src/linux:
Per kernel 2.4: make dep && make clean bzImage modules modules_install Per kernel 2.6: make && make modules_install
Se la directory /boot non è montata, montarla e copiarvi il nuovo bzImage:
# cp /usr/src/linux/arch/i386/boot/bzImage /boot/<nome del kernel>
Ricordare di aggiornare la configurazione del bootloader se necessario e riavviare.
Si dovrebbe ora essere pronti per installare i driver che può essere fatto eseguendo:
# emerge ati-drivers
Fare attenzione all'output mostrato dall'ebuild dato che non si fermerà se il modulo fglrx fallirà la compilazione ed è facile non accorgersene. Se quando si prova a caricare il modulo si riceve l'errore "Module fglrx not found" il motivo è, molto spesso, questo.
Quando l'emerge è terminato si dovrebbe configurare il file /etc/X11/xorg.conf. Se si sta aggiornando il driver ad una versione successiva si può continuare ad utilizzare il file di configurazione esistente. Comunque, può capitare che il nuovo driver introduce nuovi parametri che devono essere configurati nel file /etc/X11/xorg.conf.
La configurazione di /etc/X11/xorg.conf veniva fatta originariamente dall'applicazione fglrxconfig (vedere E' ancora possibile utilizzare fglrxconfig per configurare il driver?), ma la ATI raccomanda ora di usare aticonfig che è stata introdotta nelle versioni più recenti del driver. aticonfig è stata progettata per aggiornare un file di configurazione esistente piuttosto che sostituirlo con uno nuovo. Una configurazione di base può essere prodotta semplicemente eseguendo il comando:
aticonfig --initial --input=/etc/X11/xorg.conf
Eseguire l'applicazione senza argomenti per avere un elenco dei vari parametri ed alcuni esempi. Si può eseguire aticonfig per abilitare/disabilitare qualsiasi parametro che il driver supporta.
Se si ottiene il messaggio di errore "command not found" tentando di eseguire aticonfig, potrebbe essere necessario eseguire env-update && source /etc/profile. Il motivo di ciò risiede nel fatto che il programma viene installato in /opt/ati/bin e questa locazione non fa parte normalmente della variabile ambiente $PATH ($PATH contiene le directory dove la shell cerca gli eseguibili).
Eseguire # opengl-update ati per attivare le librerie OpenGL ATI. opengl-update sta diventando deprecato in favore di eselect. Si dovrebbe riuscire ad usare il comando analogo # eselect opengl set ati se il sistema è aggiornato.
Se si sta usando il supporto AGP del kernel e lo si è compilato come modulo, è il momento di caricarlo. Per kernel 2.4, è invece necessario caricare il modulo agpgart. Per kernel 2.6, sarà necessatio caricare agpgart ed un secondo modulo, il nome del quale è dipendente dalla propria scheda madre. Utenti nForce dovrebbero caricare nvidia_agp, utenti VIA via_agp, utenti Intel intel_agp, e così via. Si dovrebbero aggiungere questi moduli al file /etc/modules.autoload.d/kernel-2.4 o /etc/modules.autoload.d/kernel-2.6 per essere sicuri che vengano caricati ad ogni avvio. Si dovrebbe anche aggiungere il modulo fglrx alla lista dopo i moduli AGP del kernel.
Prima di far partire X, assicurarsi di avere tutti i moduli necessari caricati e che il file xorg.conf sia configurato come si desidera.
Una volta che X è partito, si può controllare se il Direct Rendering (p.e. accelerazione 3D) funziona eseguendo:
$ glxinfo | grep direct
Questo dovrebbe mostrare direct rendering: Yes se tutto funziona.
Ricordare infine che occorrerà emergere nuovamente gli ati-drivers ogni volta che si cambia la versione di kernel. Ricordare anche di aggiornare il link come descritto in precedenza prima di emergere.
aticonfig è il nome di una nuova applicazione inclusa nelle versioni recenti dei driver ATI Linux. A differenza di fglrxconfig che genera un intero file xorg.conf nuovo, aticonfig può essere usato per apportare delle modifiche ad un xorg.conf esistente. Per esempio, si può usare il comando:
aticonfig --initial
per inserire una sezione "Device" per la propria scheda Ati in xorg.conf. Eseguire l'applicazione senza argomenti per una lista completa delle opzioni e per alcuni esempi d'uso.
Per il momento è ancora possibile, ma potrebbe venire rimosso in futuro (benché rimanga comunque incluso in vecchie versioni del driver). Per installare il driver utilizzando fglrxconfig, seguire la procedura su Come installare i driver al punto 5. Invece di eseguire aticonfig, eseguire flgrxconfig e rispondere alle richieste fatte dal programma. Da ricordare che, al contrario di aticonfig, fglrxconfig sostituisce di default il file di configurazione esistente e potrebbe non configurare appropriatamente il mouse o la tastiera. Per questo, se si ha un file di configurazione funzionante, farne una copia di backup per farvi riferimento in caso si incontrino problemi. Se si ottiene il messaggio di errore "command not found" tentando di eseguire fglrxconfig, potrebbe essere necessario eseguire env-update && source /etc/profile. Il motivo di ciò risiede nel fatto che il programma viene installato in /opt/ati/bin e questa locazione non fa parte normalmente della variabile ambiente $PATH ($PATH contiene le directory dove la shell cerca gli eseguibili).
Ad un certo punto, il programma chiederà "Do you want to use the external AGP GART module (y/n)? [n]". Viene richiesto se si vuole passare al supporto AGP contenuto nel driver o se si vuole usare il modulo AGP del kernel. La risposta a questa domanda varia da sistema a sistema e può portare ad un funzionamento corretto o meno. Rispondere "n" significa utilizzare il supporto AGP del driver, "y" significa usare il supporto AGP del kernel.
Questo parametro può essere modificato in seguito attraverso l'opzione "UseInternalAGPGART" nel file di configurazione di X (/etc/X11/xorg.conf o /etc/X11/XF86Config-4). Impostare "UseInternalAGPGART" a "yes" significa usare il supporto AGP del driver e impostarla a "no" significa usare il supporto AGP del kernel (questo richiede l'abilitazione del supporto AGP del kernel. Vedere La configurazione del kernel).
C'è il potenziale per far confusione per il modo in cui fglrxconfig pone le domande, per questo proverò a specificare le cose esplicitamente. Quando si risponde "yes" alla domanda ("Sì, voglio usare il supporto AGP del kernel"), il programma porrà "UseInternalAGPGART" uguale a "no". Se si risponde "no" ("No, voglio usare il supporto AGP del driver"), verrà posta "UseInternalAGPGART" uguale a "yes". Ci si assicuri di non fare confusione tra la domanda e la risposta ed il valore posto in "UseInternalAGPGART".
Nota
Le versioni di fglrxconfig negli ultimi driver (>= 8.10.19) producono un xorg.conf di default mentre versioni precedenti possono produrre invece un XF86Config-4 nel qual caso utenti Xorg dovrebbero rinominarlo in /etc/X11/xorg.conf prima di continuare. Ancora più importante, utenti Xorg 6.8 dovrebbero editare il nuovo file di configurazione e modificare il nome del driver della tastiera da "keyboard" a "kbd". Se non si apporta questa modifica, X non partirà. La ragione per questo è che il nome del driver è cambiato tra Xorg 6.7 e Xorg 6.8 e vecchie versioni di fglrxconfig possono continuare ad usare la vecchia nomenclatura.
Provare a aggiornare i driver all'ultima versione disponibile. Per giochi basati sull'engine di Quake 3 (Q3A, RTCW, ET, ecc.), provare ad eseguirli nel seguente modo:
$ et +set r_ext_compiled_vertex_array 0
E' possibile anche disabilitare il parametro "r_ext_compiled_vertex_array" in modo permanente ponendolo a 0 attraverso la console del gioco o nel proprio file di configurazione. Comunque, la disabilitazione di questo parametro potrebbe peggiorare le performance.
Questo errore può avere diverse cause, ma le più comuni sono:
Non c'è il supporto AGP compilato nel kernel. Vedere La configurazione del kernel.
Il supporto AGP è stato compilato come modulo ma non è stato caricato. Mentre in un kernel 2.4 c'è bisogno solo di caricare il modulo "agpgart", nei kernel 2.6 i moduli da caricare sono DUE. Il primo è "agpgart" ed il secondo dipende dall'opzione che è stata selezionata durante la configurazione del kernel per il chipset dell'AGP e che dipende dalla scheda madre del computer in uso. Se si fosse selezionata l'opzione nVidia occorrerebbe caricare il modulo "nvidia_agp", per l'opzione VIA, caricare "via_agp", per l'opzione SIS. caricare "sis_agp", e così via.
Si è sbagliato il chipset per il supporto AGP nel kernel. Vedere La configurazione del kernel.
Provare a ripulire la directory sorgente del kernel. Si può fare questo in due modi principali. Primo, rimuovendo e reinstallando il kernel (assumendo che il kernel corrente sia puntato da /usr/src/linux):
# emerge -C development-sources O vanilla-sources O mm-sources etc # cp /usr/src/linux/.config ~/config (fare una copia della configurazione del kernel) # rm -fr /usr/src/linux-x.y.z (dove x.y.z è la versione del kernel che è stata rimossa) # emerge development-sources O vanilla-sources O mm-sources etc # cp ~/config /usr/src/linux/.config # cd /usr/src/linux # make oldconfig
o seguendo questo metodo:
# cd /usr/src/linux # cp .config ~/config (fare una copia della configurazione del kernel) # make mrproper # cp ~/config .config # make oldconfig
Dopo aver fatto questi passi, ricompilare il kernel, emergere nuovamente gli ati-drivers e riprovare.
Questo errore è in genere più difficile da diagnosticare e correggere rispetto all'errore "xf86_ENODEV". Seguono alcune cosa da provare:
Se si sta usando il supporto AGP del kernel (p.e. "UseInternalAGPGART" è posta uguale a "no"), assicurarsi di avere i moduli necessari (agpgart + il modulo chipset-specifico) caricati PRIMA del modulo fglrx. Per esempio, se si avesse una scheda madre VIA, caricare i moduli "agpgart" e "via-agp", e quindi fglrx (su kernel 2.4, basta caricare il modulo "agpgart"). Se si avesse una scheda nForce, si dovrebbero caricare "agpgart" e "nvdia-agp" seguito da fglrx e così via per gli altri chipset.
Incrementare la dimensione dell'apertura dell'AGP nel BIOS (in modo particolare per schede nForce2).
Con schede nForce2, provare a disabilitare l'opzione "AGP 8x Support" nel BIOS.
Controllare di non aver posto "UseInternalAGPGART" uguale a "yes" e di avere il supporto AGP compilato nel kernel
Porre "UseFastTLS" uguale a "2" nel file XF86Config/xorg.conf.
Provare ad aggiungere la linea:
Option "KernelModuleParm" "agplock=0"
nel file xorg.conf (dove sono le altre opzioni specifiche per ATI).
Controllare l'output del comando dmesg per eventuali errori.
Controllare che la configurazione del kernel sia corretta.
Provare una nuova versione del kernel.
Eseguire i prossimi passi come root:
# opengl-update xfree / opengl-update xorg-x11 # emerge ati-drivers # opengl-update ati
Provare a modificare il parametro "IgnoreEDID" in /etc/X11/XF86Config-4 ponendolo uguale a "on".
Assicurarsi di aver eseguito # opengl-update ati come root.
Ci sono molte possibili cause per questo. La prima cosa da fare è ottenere il messaggio di errore fornito al momento del caricamento del modulo. Se l'output di modprobe non è esplicativo, controllare le ultime righe di dmesg.
Controllare che il link simbolico /usr/src/linux punti ai sorgenti del kernel in uso. Se il link non è corretto il modulo verrà generato per un altro kernel e modprobe non sarà in grado di trovarlo. Aggiornare il link usando il comando:
# ln -sf /usr/src/linux-2.x.y /usr/src/linux
e controllare per eventuali errori di compilazione, specialmente se si sta usando un kernel al quale sono state applicate molte patch.
Se modprobe visualizza l'errore "Invalid module format message", e l'output di dmesg contiene linee simili a questa: "fglrx: version magic '2.6.1-gentoo-r1 SMP preempt K7 gcc-3.3' should be '2.6.1-gentoo-r1 SMP preempt K7 gcc-3.2'", significa che i driver sono stati compilati con una versione di gcc differente rispetto a quella usata per il kernel. Per correggere l'errore ricompilare i driver con la stessa versione di gcc usata per il kernel (la seconda nel messaggio), o ricompilare i driver ed il kernel con la stessa versione. Questo errore può anche essere causato da altri problemi. Per esempio, se si è compilato il kernel con il supporto 4k stacks, ma si sta ancora usando il modulo fglrx con uno stack di 8k, si otterrà un errore simile a quello summenzionato, eccetto che la differenza tra le versioni sarà che una menzionerà "4KSTACKS" e l'altra no. In questo caso, la soluzione è di emergere nuovamente i driver e caricare il nuovo modulo.
Se l'output di dmesg menziona "unresolved symbols", è possibile che alla versione del kernel in uso sia stata applicata qualche patch che non è compatibile con i driver. La cosa più semplice da fare è provare una versione di kernel differente. Se si è in grado di creare una patch per il driver che corregga il problema, sottometterla a bugs.gentoo.org in modo da farla includere in rilasci futuri dell'ebuild.
Se l'output di dmesg riporta qualcosa di simile a "the fglrx module must be loaded before any other DRM module", significa che probabilmente c'è ancora il supporto DRM nel kernel che è stato caricato prima del modulo fglrx e non gli permette di funzionare correttamente. Un'altra indicazione di questo problema è l'errore "Operation not permitted" fornito da modprobe.
Se l'errore è "No device found", significa che il driver non supporta la scheda. Se si possiede una vecchia scheda, non si sono molte alternative all'uso dei driver opensource "radeon". Se si possiede una scheda nuova, è possibile che il driver semplicemente non sia stato aggiornato con le informazioni necessarie per permettere il riconoscimento della periferica. Si può ovviare a questo problema con un piccolo sforzo extra. Si veda La scheda video non viene riconosciuta dal driver e fglrx_binary_edit.
Il modulo "fglrx" potrebbe non essere stato caricato. Il modulo è necessario per l'accelerazione 3D ma non sempre viene caricato automaticamente da X. La cosa migliore è aggiungerlo al file /etc/modules.autoload.d/kernel-2.x, dove la x è la versione corretta del kernel. Questo assicura il caricamento del modulo fglrx prima dell'avvio di X. La voce relativa a fglrx deve essere posta dopo i moduli relativi all'AGP, se si stanno usando.
Se il modulo fglrx è stato caricato (p.e. appare nell'output del comando lsmod), c'è qualcos'altro di errato. Controllare i logfile di X (/var/log/XFree86.0.log o /var/log/Xorg.0.log) per la presenza di eventuali errori. Si potrebbe trovare un messaggio di errore simile a questo:
(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work
Questo significa che la versione del modulo fglrx che si è caricato non corrisponde alla versione del driver installato. Questo può accadere se si cambia la versione del driver senza rimuovere e ricaricare il modulo fglrx ( o riavviare). Per correggere questo errore basta semplicemente riavviare o eseguire:
# rmmod fglrx && modprobe fglrx
che rimuoverà il vecchio modulo e caricherà quello nuovo.
Se si possiede una scheda nForce2, provare a porre il parametro "Primary VGA Bios" (ovviamente nel BIOS) al valore opposto di quello configurato correntemente. Questo sembra essere abbastanza raro (conosco solo un caso) ma sembra abilitare l'accelerazione 3D dove non funzionava in precedenza.
Può anche essere di aiuto in qualche situazione emergere le libstdc++-v3, che è un "compatibility package for running binaries linked against a pre gcc 3.4 libstdc++" (NdT "pacchetto di compatibilità per eseguire binari linkati a libstdc++ gcc 3.4"). Se i log di Xorg mostrano che l'avvio è avvenuto correttamente ma non si ha ancora il direct rendering abilitato, questo potrebbe essere il problema. Si veda questa topica e questa per maggiori informazioni.
Molte persone hanno avuto problemi con queste schede madri in combinazione con kernel 2.4, principalmente a causa di problemi legati all'AGP. Il supporto per l'AGP in kernel 2.4 attualmente non supporta appropriatamente il chipset KT400 e si possono avere messaggi durante l'avvio della macchina del tipo: "agpgart: unable to determine aperture size". Anche il supporto AGP dei driver ATI ha lo stesso problema con questo chipset, potrebbe funzionare o meno. Il modo migliore per arginare il problema al momento è quello di aggiornare il kernel alla versione 2.6 che ha un supporto migliore per l'AGP e dovrebbe funzionare meglio anche con chipset KT400. Se si è in questa condizione, ricordare di porre "UseInternalAGPGART" uguale a "no" in /etc/X11/XF86Config-4/ o /etc/X11/xorg.conf.
Controllare di non aver compilato il supporto AGP nel kernel. Se si vuole usare il supporto AGP del driver si deve compilare il supporto AGP del kernel come modulo.
Il supporto AGP del driver non sempre funziona. Questo dipende dal tipo di scheda madre e/o dalla scheda video in uso. E' sempre bene vedere cosa succede con "UseInternalAGPGART" posto a "no". Ricordare di caricare i moduli AGP del kernel altrimenti i driver non funzioneranno.
Probabilmente si è abilitata la sincronizzazione verticale durante l'esecuzione di fglrxconfig. Questo limita la framerate della velocità di refresh verticale del monitor e, ovviamente, questo incide su glxgears più di ogni altra cosa. Per disabilitare la v-sync, aprire /etc/X11/XF86Config-4 (o /etc/X11/xorg.conf) con un editor di testi, e cercare il parametro "Capabilities" nella sezione "Devices". Questo è un valore in esadecimale e la terza cifra a partire da destra controlla il v-sync. Per abilitare porre la terza cifra da destra uguale a "8", come: "0x00000800". Per disabilitare, porla a "0": "0x00000000".
La versione corrente del driver sembra avere problemi con la 9800 XT, probabilmente causato dalla relativamente novità della scheda. Questo problema viene indicato dal fallimento di tutti i programmi 3D col messaggio "Trace/breakpoint trap" all'avvio. Finché ATI non corregge il driver, la soluzione migliore sembra essere quella di aggiungere la seguente riga alla sezione "Device" nel file /etc/X11/XF86Config-4 o /etc/X11/xorg.conf:
ChipID 0x4e48
e riavviare X.
Questo fa sì che il meccanismo di autorilevamento dell'ID sia sovrascritto, che è il modo normale per determinare la scheda in uso. Aggiungendo questo parametro si forza la propria scheda ad essere trattata come una Radeon 9800/9800 Pro. Questo non sembra avere nessun impatto sulle prestazioni e dovrebbe permettere di utilizzare le applicazioni 3D.
Nota
Questo problema dovrebbe essere stato risolto nelle versioni più recenti dei driver.
Questo problema sembra essere il risultato della rimozione di una funzione dai sorgenti del kernel dal file drivers/char/agp/nvidia-agp.c. Non essendo un programmatore del kernel, non posso dire quale fosse questa funzione o perché è stata rimossa, ma aggiugendo la funzione omessa nel file tutto torna a funzionare senza effetti indesiderati. Una piccola patch che applica le modifiche può essere scaricata da questo sito. Per applicare la patch al kernel eseguire i seguenti comandi:
# cd /usr/src/linux # patch -p1 < /path/to/nvidia-agp.diff
Una volta applicata la patch, ricompilare il kernel, copiare il nuovo bzImage nella partizione di boot e riavviare.
Importante
Questa patch potrebbe non essere più necessaria in quanto in recenti versioni del kernel 2.6 il codice rimosso è stato riaggiunto. Si può controllare se il kernel ha il codice eseguendo grep nvidia_init_iorr /usr/src/linux/drivers/char/agp/nvidia-agp.c. Se il comando mostra alcune linee di codice, non c'è bisogno di applicare la patch.
the_best_bear86 ha inoltrato una soluzione per questo problema sul forum Rage3D.
Si può trovare questo messaggio nei log di XFree se non si sta usando il connettore del monitor secondario della scheda. X sta riportando che non si sta fornendo alcun dettaglio per la sua configurazione, ma questo non deve preoccupare dato che si sta usando un singolo monitor. Il prefisso del messaggio "(WW)", indiche solo un avvertimento, si può tranquillamente ignorarlo. Notare che il numero rappresentato dalla "x" può variare a seconda del sistema.
Prima di far partire X, eseguire opengl-update xorg-x11. Questo dovrebbe abilitare l'accelerazione 3D. Dopo che X è partito, si può eseguire opengl-update ati se si desidera utilizzare le librerie OpenGL ATI (UT2K4 richiede questo passo).
Importante
Questo non dovrebbe essere più necessario
Questo succede di solito se si sta usando il driver Radeon framebuffer, provare a rimuoverlo dal kernel ed utilizzare i driver VESA.
Se nel messaggio è menzionato "sleeping function", provare a disabilitare lo Sleep all'interno dell'opzione di controllo dello spinlock nella sezione kernel hacking del menu di configurazione del kernel. Se si continua ad avere l'errore, provare a disabilitare l'opzione Hangcheck Timer nella sezione Character Devices nel menu di configurazione del kernel (stesso posto delle opzioni per l'AGP).
No, benché questa sia una delle caratteristiche richieste (vedere questo thread). Finché ATI non ne aggiungerà il supporto, l'alternativa sono i colori a 24 bit.
Non ci sono al momento driver a 64-bit disponibili da ATI. Comunque, i driver dovrebbero funzionare se si sta usando la modalità a 32 bit. Ricordare di abilitare il supporto AMD Opteron/Athlon64 on-CPU GART nella configurazione del kernel.
Importante
Dalla release 8.8.25, i driver includono il supporto per AMD64.
Si vedano i commenti a questo bug report (in modo particolare agli ultimi). Si può risolvere il problema sia manualmente come suggerito in uno dei commenti, o aspettare la version 6.8.0 di Xorg che dovrebbe incorporare i cambiamenti necessari.
Questo indica che si sta provando a compilare il modulo per un kernel 2.6 ma il link simbolico /usr/src/linux sta puntando ad un kernel 2.4. Controllare che il link sia corretto ed emergere i driver nuovamente.
Questo errore significa che si sta provando ad usare un driver da una vecchia versione con librerie di una versione più aggiornata. Questo succede se si installa una nuova versione senza prima uscire da X e rimuovendo il vecchio modulo fglrx. Se non si fa questo, il nuovo modulo del driver non verrà caricato e rimarrà la vecchia versione. Un riavvio dovrebbe correggere il problema.
Un'alternativa può essere di uscire da X, rimuovere il vecchio modulo con # rmmod fglrx e caricare il nuovo modulo con # modprobe fglrx Si può vedere la versione del modulo appena caricato dall'output di dmesg dopo aver eseguito modprobe. Dopo aver caricaro il nuovo modulo, si dovrebbe riuscire ad avviare X e tutto dovrebbe funzionare.
Provare a commentare o rimuovere la linea Load "xtrap" nella sezione Module del proprio file di configurazione di X.
Se X mostra un errore che menziona "cannot access V_BIOS", è probabilmente causato da una piccola confusione di fglrxconfig. Aprire XF86Config o xorg.conf e trovare il parametro "BusID" (vicino alla fine della sezione "Device"). Se l'ultima cifra è un "1", cambiarla in "0" e X dovrebbe partire correttamente.
Aprire /usr/share/celestia/celestia.cfg con un editor di testi e cercare il parametro "IgnoreGLExtensions" che dovrebbe essere commentato di default. Scommentarlo (non modificare il parametro stesso), salvare il file e Celestia dovrebbe partire. Ci sono presumibilmente alcune differenze di prestazioni, ma sembrerebbe funzionare bene lo stesso.
Nota
Con la versione 8.8.25 del driver, l'errore sussiste anche con il parametro "IgnoreGLExtensions" scommentato. Comunque, c'è un problema con gli ebuild per gli ati-drivers il cui risultato è nel linkare Celestia con le librerie openGL di Xorg invece che con quelle ATI con prestazioni modeste. Questo problema sembra essere stato corretto nelle versioni più recenti dell'ebuild (8.8.25-r2), assicurarsi di aggiornarle se sti stanno ancora usando versioni precedenti.
Seguire la procedura descritta in Il calcolo di glxgears è veramente basso (<120), anche se tutto sembra funzionare bene.
Alcuni CFLAGS possono influire sul funzionamento dei driver. Una persona ha riportato che il risultato dell'uso dei seguenti flag: "-march=athlon-xp -O3 -pipe -ftracer -fomit-frame-pointer -frerun-cse-after-loop -ffast-math -funroll-loops -fgcse -mfpmath=387,sse -fforce-addr -frerun-loop-opt -fmove-all-movables -funit-at-a-time" è stato la perdita dell'accelerazione 3D (vedere sul forum). Questo non sembra comunque influire sui driver 8.8.25. Se si ritiene che i propri CFLAGS possano causare problemi, passare ad un insieme di flag più conservativo ed emergere nuovamente i driver.
Non con i driver, ma possono avere effetto su Xorg/XFree. In particolare, se si osservano errori di simboli irrisolti nei log e X non parte o non abilita l'accelerazione 3D, si dovrebbe controllare di non aver emerso X con uno di questi flag "static", "dlloader" e "hardened". Se si ha uno di questi flag abilitati, disabilitarlo e emergere nuovamente X.
Controllare che l'opzione "PseudoColorVisuals" si posta a "off" in /etc/X11/XF86Config-4 o /etc/X11/xorg.conf.
Per abilitare l'estensione RANDR. occorre disabilitare il DGA (Direct Graphics Access) aggiungendo il seguente testo alla sezione "Modules di /etc/X11/xorg.conf o /etc/X11/XF86Config-4:
SubSection "extmod" Option "omit xfree86-dga" EndSubSection
Questo testo dovrebbe già fare parte del file se lo si è configurato con fglrxconfig, ma la seconda riga potrebbe essere commentata, il che abilita il DGA. Per disabilitarlo commentare semplicemente la seconda riga.
Gli utenti XFCE possono avere problemi con il sistema di switch della risoluzione (che usa l'estensione RANDR) se il modulo "extmod" è caricato e anche se il DGA è disabilitato. Per prevenire il caricamento del modulo "extmod", commentare o rimuovere tutte e tre le linee precedenti da xorg.conf.
Controllare che la dimensione dell'apertura dell'AGP sia almeno 64MB. La dimensione dell'apertura può essere alterata di solito attraverso il menu del BIOS.
Se si hanno entrambe le versioni di gcc (hardened e non) installate, è importante aver compilato il kernel, XFree/Xorg e gli ati-drivers con la stessa versione di gcc. Comunque, Xorg richiede che il flag USE "dlloader" sia disabilitato mentre una installazione hardened ne richiede l'abilitazione. La soluzione è di compilare il kernel, Xorg e gli ati-driver usando una versione non hardened del gcc. Questo problema può comportare il non funzionamento del direct rendering e la scrittura dei seguenti messaggi nel log di X:
(II) fglrx(0): [drm] loaded kernel module for "fglrx" driver (II) fglrx(0): [drm] DRM interface version 1.0 (II) fglrx(0): [drm] drmSetBusid failed (4, PCI:1:0:0), Inappropriate ioctl for device (EE) fglrx(0): DRIScreenInit failed! (WW) fglrx(0): *********************************************** (WW) fglrx(0): * DRI initialization failed! * (WW) fglrx(0): * (maybe driver kernel module missing or bad) * (WW) fglrx(0): * 2D acceleraton available (MMIO) * (WW) fglrx(0): * no 3D acceleration available * (WW) fglrx(0): ********************************************* *
Si veda questo articolo della ATI.
Nota
La ATI ha riorganizzato il proprio sito web e questa informazione non è più accessibile nella vecchia locazione. Comunque l'articolo è riprodotto nella Release Notes per i driver correnti sotto la voce "3D Applications Produce Open of Shared Memory Object Failed Error Message".
Al momento, il driver disabiliterà automaticamente il direct rendering se si abilita l'estensione Composite. Si noterà questo comportamento dal file /var/log/Xorg.0.log che riporterà una linea come la seguente:
(II) fglrx(0): Composite extension enabled, disabling direct rendering
Per riabilitare l'accelerazione 3D, commentare o rimuovere la linea che carica l'estensione Composite da xorg.conf.
Se si ottiene l'errore "Couldn't initialize video: X11 driver not configured with OpenGL", si dovrà probabilmente emergere libsdl con il flag USE "opengl" abilitato.
Se sembra che il supporto XVideo non sia presente, aprire il file /etc/X11/xorg.conf e controllare il valore dei seguenti parametri:
Se il chipset AGP funziona con il supporto AGP del driver ATI (se tutto funziona usando il parametro "UseInternalAGPGART posto uguale a "yes"), non si dovrebbe soffrire di questo problema.
Comunque, molti chipset AGP non sono supportati o non funzionano correttamente con il supporto AGP fornito dal driver, il che significa che deve essere usato il supporto AGP fornito dal kernel ("UseInternalAGPGART" posto uguale a "no"). Se questa è la propria situazione, si dovrebbe aggiungere questa lina alla sezione Device di /etc/X11/xorg.conf:
Option "KernelModuleParm" "agplock=0"
e provare la soluzione di Septor.
(Un ringraziamento a Peter Maynard per questa informazione) I driver ATI (v8.10.19) permettono l'uso di TV-out da un portatile. Comunque, si deve disabilitare il monitor LCD prima di abilitare il TV-out.
Creare una copia del file /etc/X11/xorg.conf nella propria home directory (in questo modo si evita di sovrasctivere il file esistente) e editare le voci come segue:
Section "Device"
Identifier "ATI Graphics Adapter"
Driver "fglrx"
Option "MonitorLayout" "NONE, AUTO"
# === TV-out Management ===
Option "NoTV" "no"
Option "TVStandard" "NTSC-M"
Option "TVHSizeAdj" "0"
Option "TVVSizeAdj" "0"
Option "TVHPosAdj" "0"
Option "TVVPosAdj" "0"
Option "TVHStartAdj" "0"
Option "TVColorAdj" "0"
Option "GammaCorrectionI" "0x00000000"
Option "GammaCorrectionII" "0x00000000"
...
EndSection
Section "Screen"
Identifier "Screen0"
Device "ATI Graphics Adapter"
Monitor "Monitor0"
DefaultDepth 24
Subsection "Display"
Depth 24
Modes "1024x768" "800x600"
ViewPort 0 0 # initial origin if mode is smaller than desktop
EndSubsection
EndSection
Ponendo 'MonitorLayout' a "NONE, AUTO", il monitor LCD (che è il primario) verrà disabilitato e la TV, che è il secondario verrà automaticamente rilevato. Ci si assicuri di lavorare da console una volta avviato il computer per testare la configurazione. Collegare la TV attraverso un cavo S-video e accendere la TV. Far partire X usando il file di configurazione modificato (il modo più semplice è di porre il file nella propria home directory ed eseguire 'startx' dalla propria home directory). Il monitor LCD dovrebbe spegnersi e l'output dovrebbe apparire sulla TV, Non sarebbe male avere un paio di risoluzioni disponibili nel caso che 1024x768 non funzioni. Quando si esce dalla sessione X, il monitor LCD dovrebbe riaccendersi e la console virtuale dovrebbe tornare visibile.
Ci sono diverse possibili cause. La prima cosa da provare è modificare la configurazione di "UseInternalAGPGART" in /etc/X11/xorg.conf.
Altre possibili soluzioni:
Alcuni sistemi possono richiedere la modifica del parametro "MonitorLayout" dal default di "AUTO, AUTO" (che prova ad autorilevare la configurazione del monitor). Se si possiede un portatile con una scheda Mobility e si vede lo schermo nero, provare a modificare "AUTO, AUTO" in "LVDS, AUTO". Questo problema sembra incidere particolarmente portatili con chipset Mobility X-seriers (X300, X600, ecc).
Se il computer possiede molta RAM (più di 768MB), provare a limitare
l'ammontare usata da Linux come descritto in questo link.
Provare a porre l'opzione NoDRI in /etc/X11/xorg.conf, ad "on", far partire X, uscire, rimettere NoDRI su "off" (il default), far ripartire X. Se questo funziona, X non tornerà a funzionare finché non si riavvia. C'è un bug su questo problema.
Un utente ha riportato che può essere d'aiuto impostare BlockSignalsOnLock a "off". Comunque, secondo un file readme di una vecchia versione dei driver: l'opzione BlockSignalsOnLock dovrebbere essere impostata sempre ad "on" a meno che non si stiano testando applicazioni OpenGL multithread. Ponendo ad "off" questa opzione, si può avere una perdita di memoria. Non so se questo è ancora valido per i nuovi driver, ma è qualcosa da ricordare se si deve cambiare questo parametro per far funzionare le cose.
Ci sono un paio di cose da provare. La prima è di sovrascrivere l'autoriconoscimento del chipset che viene eseguito da X ogni volta che parte. Si può fare questo aggiungendo una linea come:
ChipID 0x4e48
nella sezione "Device" in /etc/X11/xorg.conf. Sostituire "4e48" con l'ID del PCI della scheda che si vuole che X riconosca. L'esempio usa l'ID per una R9800 Pro. Si può trovare una lista completa di ID PCI ATI qui.
La seconda cosa da provare se la scheda possiede un ID non standard, è di editare la parte binaria del driver e provare ad aggiungerlo. Per maggiori informazioni guardare il post di ohoiza, e questo post. Si può provare ad usare fgrlrx_binary_edit per eseguire l'editing.
Una parte dell'ebuild degli ati-drivers tenta di compilare il modulo fglrx per il kernel in uso. L'altra parte installa vari altri file (librerie OpenGL, ecc.). Comunque, l'ebuild non uscirà per errore se il modulo fglrx non può essere compilato, per questo, se non si guarda attentamente all'output, è facile non accorgersene. Di solito la ragione per il fallimento della compilazione del modulo è che il kernel è troppo nuovo o con troppe patch applicate. Questo succede spesso con le ultime release candidate dei kernel o con molte patch come mm-sources. Se si è in questa situazione, la soluzione puù semplice è di solito usare un kernel leggermente più vecchio o non patchato. Per esempio, un kernel vanilla-sources di solito funziona. Assicurarsi inoltre di utilizzare l'ultima versione di ati-drivers dato che versioni vecchie possono avere problemi con nuovi kernel.
In alternativa, si può provare a cercare per un set di patch per il driver che ne permetta la compilazione con mm-sources o altri tipi di kernel. Il luogo migliore dove cercare queste patch sono i forum di Gentoo, il Linux forum su rage3d.com e Google. Se si conosce un po' di programmazione, si può riuscire a confezionare una patch da soli.
Recentemente ci sono state un numero di persona che hanno riportato che con l'abilitazione del driver per il framebuffer radeonfb nel kernel si hanno questi problemi. Se si ha questo driver abilitato, provare a disabilitarlo o usare il driver VESA al suo posto.
Per maggiori dettagli sul problema quardare questa topica.
Provare ad aggiungere in xorg.conf la linea:
Option "KernelModuleParm" "agplock=0"
Eseguire il seguente comando prima di eseguire l'applicazione:
export LIBGL_DRIVERS_PATH=/usr/lib32/modules/dri
In molti casi il tentatitvo di usare le funzioni suspend/resume su un portatile con i driver ATI causa problemi col direct rendering abilitato. Comunque, sembra che adesso sia possibile aggirare il problema e permettere le funzionalità suspend/resume con il direct rendering abilitato.
La tecnica viene descritta nel post http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-June/026968.html.
Il file fglrx_suspend_resume.tar.bz2 contiene un esempio di un xorg.conf che può essere usato come esempio ed uno script che esegue le azioni appropriate (è destinato ad essere eseguito quando viene generato un evento ACPI lid open/close).
In questa situazione, dopo aver seguito le istruzioni di installazione senza successo, provare a reinstallare il pacchetto Xorg.
Non è ancora chiaro perché accade questo, ma qualunque sia la ragione, apparentemente influisce sui driver "radeon" e per questo non è un semplice problema del driver "fglrx". Non sembrano esserci modi per far funzionare il DRI su una scheda AGP senza rimuovere fisicamente la scheda PCI dal sistema.
Al momento non sembra esserci alcuna soluzione al problema. Il driver fglrx ha sempre avuto problemi a trattare con più di un server X ed il fatto che passando al driver 'vesa' di base tutto funzioni, suggerisce che il problema è effettivamente dei driver ATI. Il driver 'radeon' di Xorg è probabilmente la migliore alternativa sempre che supporti la scheda in uso.
Si può provare a descrivere il problema nel forum ATI Radeon Sticky di Gentoo. Qualcuno potrebbe riuscire a trovare una soluzione.
Se si ha la certezza che è un problema col driver, ATI ha una form sul proprio sito web: ttp://apps.ati.com/linuxDfeedback/.
D'altra parte se si ha la certezza che è un problema col sistema usato da Gentoo per la gestione del driver, sottomettere un bug a bugs.gentoo.org o descrivere il problema in un forum.
Merita anche controllare nell'ATI Linux bugzilla non ufficiale su http://ati.cchtml.com. Il gruppo degli ATI driver conosce questo sito e può essere un buon punto per seguire il progresso di un bug particolare che concerne il problema riscontrato.
Infine, c'è un nuovo wiki generico (non specifico per una distribuzione) per i driver fglrx creato su http://wiki.cchtml.com.
fglrx_binary_edit.tar.bz2: se la versione corrente del driver ATI non supporta la scheda in uso (solitamente segnalato come un messaggio "No device found" durante il tentativo di caricare il modulo fglrx), è spesso possibile editare la parte binaria del driver ed inserire l'ID PCI necessario per riconoscere la scheda. Si veda La scheda video non viene riconosciuta dal driver.
fglrx_binary_edit è un piccolo programma che dovrebbe permettere di lavorare sull'editing binario. Per le istruzioni sull'uso leggere il README incluso nel tarball.
Le seguenti persone hanno contribuito a queste FAQ (in ordine alfabetico):