Repository 32bit  Forum
Repository 64bit  Wiki

Installazione driver ATI su Slackware GNU/Linux: differenze tra le versioni

Da Slacky.eu.
(Installazione dei driver proprietari)
(spina -> targzeta)
 
(5 revisioni intermedie di un utente non mostrate)
Riga 466: Riga 466:
=Installazione dei driver open source=
=Installazione dei driver open source=
L'installazione dei driver open source è quanto mai semplice: siccome il driver è già incluso nel kernel linux, dovremo solamente apportare alcune modifiche al file /etc/X11/xorg.conf facendo usare il modulo 'radeon' al server X. Potete, quindi, proseguire saltando direttamente [http://www.slacky.eu/wikislack/index.php?title=Installazione_driver_ATI_su_Slackware_GNU/Linux#Configurazione_di_X_per_i_driver_Open_Source qui].
+
Più che di installazione è più corretto parlare di configurazione dei driver open source. Questo passo è quanto mai semplice: siccome il driver è già incluso nel kernel linux, dovremo solamente apportare alcune modifiche al file /etc/X11/xorg.conf facendo usare il modulo 'radeon' al server X. Potete, quindi, proseguire saltando direttamente [http://www.slacky.eu/wikislack/index.php?title=Installazione_driver_ATI_su_Slackware_GNU/Linux#Configurazione_di_X_per_i_driver_Open_Source qui].
=Installazione dei driver proprietari=
=Installazione dei driver proprietari=
Riga 476: Riga 476:
==Compatibilità con Kernel Linux e Server X==
==Compatibilità con Kernel Linux e Server X==
Purtroppo i driver propietari fra i tanti difetti, non possono essere compilati con ogni versione del kernel linux e del server X. E' molto probabile che con versioni del kernel troppo successive a quelle contemporanee al rilascio del driver stesso (o troppo precedente), semplicemente il driver non si compili. In fase di download del driver, quindi, verificarne la compatibilità leggendo le specifiche di rilascio del driver.
+
Purtroppo i driver propietari non possono essere compilati con ogni versione del kernel linux e del server X. E' molto probabile che con versioni del kernel troppo successive a quelle contemporanee al rilascio del driver stesso (o troppo precedente), semplicemente il driver non si compili. In fase di download del driver, quindi, verificarne la compatibilità leggendo le specifiche di rilascio del driver.
'''NB: bisogna ricordarsi che ad ogni cambiamento di versione del kernel o del server X i driver proprietari vanno reinstallati o ricompilati.'''
'''NB: bisogna ricordarsi che ad ogni cambiamento di versione del kernel o del server X i driver proprietari vanno reinstallati o ricompilati.'''
==Installazione tramite slackbuild==
==Installazione tramite slackbuild==
Questa modalità (consigliata), consiste nell'usare uno slackbuild (grazie al lavoro di spina) il quale creerà due pacchetti slackware: uno che è il driver vero e proprio e l'altro che è il modulo per il kernel in uso.
+
Questa modalità (consigliata), consiste nell'usare uno slackbuild (grazie al lavoro di targzeta) il quale creerà due pacchetti slackware: uno che è il driver vero e proprio e l'altro che è il modulo per il kernel in uso.
A tal proposito seguite la guida di installazione che ha creato lo stesso spina:
+
A tal proposito seguite la guida di installazione che ha creato lo stesso targzeta:
[http://www.slacky.eu/wikislack/index.php?title=ATI_Proprietary_drivers._Ecco_uno_slackbuild. ATI Proprietary Drivers. Ecco uno slackbuild.]
[http://www.slacky.eu/wikislack/index.php?title=ATI_Proprietary_drivers._Ecco_uno_slackbuild. ATI Proprietary Drivers. Ecco uno slackbuild.]
Riga 563: Riga 563:
==Configurazione di X per i driver Open Source==
==Configurazione di X per i driver Open Source==
In Section "Module" aggiungiamo:
+
Modificheremo il file /etc/X11/xorg.conf a mano, senza utilizzare nessuna utility offerta dal sistema. In Section "Module" aggiungiamo:
Load "dri"
Load "dri"
Riga 617: Riga 617:
==Parametri aggiuntivi del server X==
==Parametri aggiuntivi del server X==
Ssistono alcuni parametri che si possono aggiungere e che sono comuni ai due tipi di driver.
+
Esistono alcuni parametri che si possono aggiungere e che sono comuni ai due tipi di driver.
Se la scheda è dotata di memoria video dedicata, possiamo specificare a X il quantitativo di memoria che usa la scheda in questo modo:
Se la scheda è dotata di memoria video dedicata, possiamo specificare a X il quantitativo di memoria che usa la scheda in questo modo:
Riga 797: Riga 797:
In ogni caso, tenete sempre d'occhio gli eventuali errori del file log di X, con il comando:
In ogni caso, tenete sempre d'occhio gli eventuali errori del file log di X, con il comando:
cat /var/log/Xorg.0.log | grep "(EE)"
+
grep "(EE)" /var/log/Xorg.0.log
per chi usa i driver proprietari e ha optato per l'installazione senza la creazione dei pacchetti slackware, viene anche creato un log in /lib/modules/fglrx della sua compilazione; consultatelo quindi con il comando:
per chi usa i driver proprietari e ha optato per l'installazione senza la creazione dei pacchetti slackware, viene anche creato un log in /lib/modules/fglrx della sua compilazione; consultatelo quindi con il comando:
Riga 861: Riga 861:
=Ringraziamenti=
=Ringraziamenti=
spina, per aver concesso la sua guida sui driver proprietari, per i suoi preziosi consigli e per la sua disponibilità
+
targzeta, per aver concesso la sua guida sui driver proprietari, per i suoi preziosi consigli e per la sua disponibilità
submax82, per aver rilasciato il pacchetto aggiornato dei driver radeon
submax82, per aver rilasciato il pacchetto aggiornato dei driver radeon

Versione attuale delle 23:52, 2 ott 2012

Indice

[modifica] Disclaimer

L'autore di questa guida, i suoi collaboratori e slacky.eu non si riterranno responsabili di eventuali danni provocati al vostro computer.

[modifica] Informazioni

Questa guida è riferita ad un sistema con Slackware GNU/Linux 12.0. I principi in essa esposti comunque sono applicabili a qualsiasi distribuzione GNU/Linux.

Ovviamente, per poter avere successo nell'operazione, è necessario avere una buona conoscenza della distribuzione, una buona padronanza dei comandi di base e della procedura di configurazione e compilazione del kernel. Per quanto riguarda Slackware, consultare la pagina Compilazione e ricompilazione Kernel su Slackware di questa stessa Wiki.

[modifica] Introduzione

Questa guida si propone come strumento d'aiuto per l'installazione dei driver proprietari e/o dei driver open source disponibili per le schede video ATI Radeon e ATI Mobility Radeon, al fine d'ottenere l'abilitazione dell'accelerazione 3D ed il corretto funzionamento della console in modalità framebuffer.

[modifica] Driver

Esistono due tipologie di driver che è possibile usare su Linux per la famiglia radeon dell'ATI:

  • i driver open source, già presenti nel kernel Vanilla (il kernel standard di kernel.org, utilizzato in Slackware) e nella distribuzione standard di Xorg. Non è quindi necessario effettuare nessun tipo d'operazione per procurarseli.

Per dovere di cronaca citiamo anche il sito Schneider Digital, che fornisce driver con supporto a Linux per schede di alcune famiglie ATI. In questa guida comunque non saranno trattati.

In entrambi i casi, i driver sono composti da due elementi principali:

  • il modulo kernel, che previa compilazione/installazione potremo trovare nella directory /lib/modules/Versione Kernel/kernel/drm
  • il driver per Xorg, che potremo trovare nella directory /usr/lib/modules/dri oppure /usr/X11/lib/modules/dri.

Nel caso di schede video AGP, sarà anche necessario il modulo GART adatto, indipendentemente dal tipo di driver si scelga di utilizzare.

Per l'utilizzo della console in modalità framebuffer, invece, è necessario solamente compilare ed utilizzare il driver specifico disponibile all'interno del kernel stesso, senza il download di driver specifici.

[modifica] Backup della configurazione

Nel corso di questa guida, verranno modificati una serie di file configurazione spesso vitali per l'utilizzo della propria distribuzione, per questo motivo, è cosa saggia effettuare una copia di backup di ognuno di questi file.

Nello specifico, modificheremo:

  • il file /etc/fb.modes, responsabile della configurazione della console in modalità framebuffer
cp /etc/fb.modes /home/home_utente/fb.modes
  • il file /etc/X11/xorg.conf, responsabile della configurazione e del corretto funzionamento del server X
cp /etc/X11/xorg.conf /home/home_utente/xorg.conf.backup
  • il kernel
cp /usr/src/linux/.config /home/home_utente/config.backup
  • il file di configurazione di lilo
cp /etc/lilo.conf /home/home_utente/lilo.conf.backup

[modifica] Verifica dell'hardware

Bene, ora possiamo analizzare le informazioni sull'hardware della nostra scheda video e del tipo di bus utilizzato. Diamo il comando:

lspci

Relativamente alla scheda video otterremo un output del tipo:

01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]

Sappiamo quindi che il chipset della scheda è riconosciuto come RV350 e che il suo indirizzo hardware sul bus PCI è 01:00.0.

Relativamente al bus video , invece:

00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge)

Il quale ci informa che nel sistema la scheda video risiede su bus AGP e che il chipset specifico è della SiS. Ovviamente, se usate una scheda video su bus PCI Express avrete un output diverso.

Se volete maggiori informazioni sulle caratteristiche della vostra scheda video, è possibile reperirle sul sito PC Hardware Links di Chris Hare.

[modifica] Configurazione del kernel

Solitamente i moduli di cui abbiamo bisogno sono già presenti nell'installazione standard del kernel presente in Slackware, in ogni caso è meglio controllare tutte le opzioni di cui discuteremo in questa sezione, eventualmente ricompilando il kernel. E' caldamente consigliato l'utilizzo di un kernel 2.6.x, cui faremo riferimento nel resto di questa guida.

Innanzitutto, è bene verificare che le opzioni per il caricamento automatico dei moduli da parte del kernel (nonchè il supporto ad essi) siano attivate:

Loadable module support --->
        <*> Enable loadable module support
        <*> Module unloading
        <*> Automatic kernel module loading

Un altra opzione importante riguarda l'utilizzo degli MTRR. In breve, gli MTRR sono registri utilizzati per il controllo della memoria, importanti per avere delle performance accettabili.

Processor Type and features ---> 
    <*> MTRR (Memory Type Range Register) support 

Importante è anche l'attivazione del tmpfs (una volta chiamato shm), il cosiddetto "temporary filesystem". Senza di questo non sarà possibile rendere disponibile l'accellerazione sotto X per altri utenti eccetto root (uno scenario decisamente sconsigliabile).

File systems ---> Pseudo filesystems --->
    <*> Virtual memory file system support

Infine, bisogna attivare le opzioni relative al tipo di bus utilizzato dalla scheda video.

  • Per le schede PCI Express:
Bus options (PCI, PCMCIA, EISA, MCA, ISA) --->
        <*> PCI Express support
  • Per le schede AGP selezionerete innanzitutto il supporto al bus AGP, quindi l'opzione relativa al vostro chipset, in questo esempio un SiS:
Device Drivers  ---> Character devices  --->
    <M> /dev/agpgart (AGP Support) 
        < > ALI chipset support
    	< > ATI chipset support
        < > AMD Irongate, 761, and 762 chipset support
        < > AMD Opteron/Athlon64 on-CPU GART support
        < > Intel 440LX/BX/GX, I8xx a E7x05 chipset support
        < > NVIDIA nForce/nForce2 chipset support
        <M> SiS chipset support
        < > Serverworks LE/HE chipset support
        < > VIA chipset support

E' importante che il supporto AGP sia attivato come modulo. Alcune guide su internet consigliano di disattivare il supporto AGP del kernel. Questo riguardava i vecchi driver di ATI, che avevano un supporto AGP interno e che non riuscivano spesso ad interfacciarsi con i driver del kernel. Con kernel e driver recenti è indicato procedere come specificato.

NB: nel caso sia utilizzata una CPU Athlon64, indipendentemente dal chipset è bene attivare l'opzione AMD Opteron/Athlon64 on-CPU GART support

Indipendentemente dal tipo di diver utlizzato, è necessario che tutte le opzioni fin qui descritte siano attivate.

Una volta controllate queste opzioni di base, è necessario decidere quali driver si vorrà utilizzare per l'accellerazione di X. Come detto precedente è possibile sceglere fra i driver Open Source e quelli propietari. Nulla vieta comunque di avere entrambi i driver installati contemporaneamente, anzi. Considerato i pro e i contro derivanti dall'installazione di un tipo o l'altro di driver, lo scenario ideale è quello di avere entrambi i driver compilati installati e configurati, switchando fra i due a seconda della necessità (operazione resa possibile dalla struttura modulare del kernel Linux).

NB: purtroppo, i driver Open Source non supportano il Direct Rendering (l'accellerazione hardware) su ogni modello di Radeon. Prestare quindi attenzione e vedere sul sito del progetto DRI la compatibilità con la propria scheda video.

Per chi desidera usare i driver open source, bisogna assicurarsi che l'opzione relativa al Direct Rendering Manager (DRM) sia abilitata, insieme all'opzione per il chipset specifico:

Device drivers ---> Character Devices --->
    <M> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
        < > 3dfx Banshee/Voodoo3+
  	< > 3dlabs GMX 2000
  	< > ATI Rage 128
        <M> ATI Radeon
        < > Intel I810
        < > Intel 830M, 845G, 852GM, 855GM, 865G
        < > Matrox g200/g400
        < > SiS video cards

Per l'utilizzo del driver propietario, invece, non è necessario abilitare nessun'altro tipo d'opzione. Se si decide per usare unicamente il driver propietario, è buona norma NON attivare il driver Open Source, per evitare problemi di qualsiasi tipo nel caricamento dei moduli.

L'ultima operazione necessaria per configurare la scheda video, a questo punto, è l'abilitazione della console in modalità frame buffer. A questo scopo, è sufficiente attivare le seguenti opzioni:

Device Drivers ---> Graphic Support --->
 <*> Support for frame buffer devices
 [*]   Enable firmware EDID
 ---   Enable Video Mode Handling Helpers (quest'opzione viene selezionata di default attivando l'opzione radeon. Se non dovesse succedere,
       selezionarla a mano)
 <*>   ATI Radeon display support
 [*]     DDC/I2C for ATI Radeon support
 [*]     Support for backlight control (solo se si dispone del dispositivo)

In questa sezione, è importante che nessun'altra opzione relativa al frame buffer sia attivata e che tutte siano compilate in modo statico, non come moduli. Per averle come moduli è necessario modificare l'initrd image, un argomento che esula da questo articolo.

Normalmente, il kernel linux si avvia cercando di usare il driver vesa per la console frame buffer, raramente il kernel linux predilige radeon a vesa. Di default, lo stesso file /etc/fb.modes contiene le impostazioni per una console di tipo vesa, e non radeon. Lo stesso lilo tenta di utilizzare una modalità vesa. Il motivo è ovvio: non tutti i computer possiedono la stessa scheda video ma tutte le schede video sono compatibili vesa.

Disattivando il supporto a qualsiasi tipo di frame buffer con l'eccezione di radeon, si forza il kernel ad utilizzare quel driver specifico. Purtroppo però così facendo è possibile che il kernel e lilo non riescano a gestire le risoluzioni specifiche della scheda video, spesso differenti da quelle standard vesa. Potremmo addirittura sperimentare un blocco del sistema. Per ovviare a questo problema, è sufficiente passare a lilo i parametri vga=normal video=radeonfb:off per avviare l'os in modalità testuale. Maggiori spiegazioni sulla configurazione del frame buffer e sulla risoluzione di eventuali problemi sono riportati in seguito in questo stesso articolo nella sezione specifica.

Se, come vedremo in seguito, i driver radeon specifici non dovessero funzionare nonostante tutto con la nostra scheda, allora bisognerà tornare in questa schermata ed attivare le opzioni nel modo seguente

[*]   VESA VGA graphics support
< >   ATI Radeon display support

per disattivare il supporto al driver radeonfb ed attivare quello al driver vesafb.

Infine, attivare anche:

Device Drivers ---> Graphic Support ---> Console display driver support --->
 --- VGA text console
 [*]   Enable Scrollback Buffer in System RAM
 (128)   Scrollback Buffer Size (in KB)
 [*]   Video mode selection support
 <*> Framebuffer Console support
 [*] Select compiled-in fonts
 [*]   VGA 8x8 font
 [*]   VGA 8x16 font

[modifica] Configurazione di lilo

I parametri specifici per la configurazione di lilo sono descritti nel seguito di questa guida. Al fine di testare le varie modalità video della console frame buffer (o per disattivarla nel caso di malfunzionamenti) è utile attivare il menù iniziale di lilo, il quale permette d'impostare parametri aggiuntivi direttamente da command line, senza dover modificare il file lilo.conf.

A tal scopo, aggiungere le righe seguenti al file lilo.conf

prompt
timeout = 50

La prima forza lilo a visualizzare il menù d'avvio, la seconda stabilisce un countdown di 5 secondi allo scadere dei quali verrà avviata la prima voce del menù. Volendo, è possibile cambiare la voce di default con l'opzione "default=LABEL"

NB: è bene ricordarsi che è indispensabile eseguire il comando lilo -t per testare se le configurazioni sono corrette e lilo -v per rendere effettive le modifiche.

[modifica] Configurazione della console in modalità frame buffer

Esistono differenti modalità di visualizzazione della console in Linux. La modalità classica è la modalità testuale. Il vantaggio di questa modalità è che non necessita di particolari driver o configurazioni per poter funzionare. Gli svantaggi sono il numero ridotto di caratteri visualizzabili su schermo e l'impossibilità di visualizzare grafica senza avviare il server X.

Per ovviare a questi problemi, il kernel Linux supporta la possibilità di utilizzare la console in modalità grafica, tramite l'utilizzo del frame buffer. Questa modalità ci permette non solo di avere un numero decisamente più elevato di caratteri visualizzabili su schermo, ma tra le altre cose ci permette di visualizzare immagini di sfondo sulla console, di visualizzare barre di caricamento all'avvio del kernel e di utilizzare programmi grafici (come mplayer o videogames vari) senza la necessità d'avviare il server X. Inoltre, in alcuni casi, è importante anche al fine del corretto funzionamento del server X stesso, poichè determinati driver se correttamente impostati possono fare ampio utilizzo del supporto kernel al frame buffer.

Slackware Linux include nel kernel di default il supporto automatico alla console frame buffer di tipo "VESA", dove per VESA s'intende un insieme di standard per l'utilizzo delle modalità grafiche avanzate (ossia superiori alla modalità VGA) sulle moderne schede video. Per cui, è probabile che si disponga già di una console in modalità frame buffer, utilizzandola senza sapere di cosa effettivamente si tratta o di come stia funzioando. Inutile dire che, essendo il driver VESA un driver generico, difficilmente supporterà appieno la nostra scheda video, con la giusta risoluzione e le giuste opzioni.

In fase d'installazione, il setup di Slackware richiede il tipo di console che si desidera utilizzare, e come opzione di default propone una console grafica, in modalità frame buffer. Se è stata selezionata una qualsiasi modalità grafica, il file lilo.con conterrà il parametro globale

vga = numero # (genericamente 791, una 1024x760 a 16bit)

All'avvio lilo passerà il parametro al kernel, che tenterà di settare la risoluzione con quella indicata. Se il file lilo.conf non contiene la riga di cui sopra, significa che in fase d'installazione si è esplicitamente scelto di avere la console in modalità testuale. Per attivare la console in modalità grafica usando il driver VESA è sufficiente aggiungere la riga mancante e riavviare l'os. E' possibile che il kernel tenti di avviare la console in modalità grafica anche in assenza di una riga "vga=..." dentro il file lilo.conf. Questo accade perchè la modalità video di default può essere (e viene) settata staticamente all'interno del file immagine del kernel in fase di compilazione. Se si vuole alterare il parametro di default si può usare il comando rdev, od il suo wrapper vidmode, scelta che comunque sconsiglio caldamente salvo necessità particolari. Un altro motivo per cui la console può avviarsi in modalità grafica pur in assenza di una riga "vga=..." è perchè nel kernel è compilato il supporto ad un driver specifico, il quale tenta di settare la risoluzione autonomamente.

Il parametro vga serve per impostare la modalità video solo ed unicamente per il driver VESA (vesafb). Se non è stato compilato il supporto al driver vesafb, il parametro vga verrà ignorato o comunque verrà considerato solo in parte. Nella sezione sul kernel abbiamo espressamente indicato di non usare altri driver all'infuori di radeonfb. Purtroppo però il driver radeon non è in grado di gestire correttamente tutte le schede di questa famiglia (c'era da dubitarne?). In questo caso, è necessario disattivare nel kernel il supporto al driver radeon e ripiegare sul driver VESA, piuttosto che rimanere senza console grafica. Per conoscere le modalità d'utilizzo e configurazione del driver vesafb, rimando all'articolo Framebuffer Console HOWTO in questa stessa wiki.

[modifica] Utilizzo della console con il driver radeonfb

Parlando della configurazione del kernel, abbiamo detto di attivare il supporto alla console frame buffer ed il driver per schede radeon, disattivando ogni altra opzione, il che include il driver VESA. Una volta fatto ciò, al successivo riavvio il Kernel tenterà di avviare la console in modalità grafica utilizzando l'unico driver disponibile, ossia il driver radeonfb. Se si lasceranno altri driver attivati, il kernel tenterà di caricarli nell'ordine in cui figurano nel kernel, salvo diverse indicazioni. Quando questo accade, oltre al device frame buffer primario (/dev/fd0) ne verranno creati altri secondari (/dev/fd1, etc). Purtroppo, non esiste un modo sicuro per determinare in che ordine verranno caricati e quale driver verrà quindi usato per il display primario. Per questo, a meno che non si sappia cosa si sta facendo, è meglio compilare un solo driver per volta (maggiori informazioni sull'utilizzo contemporaneo di più driver sono contenute nell'articolo Framebuffer Console HOWTO).

Nel nostro scenario (presenza unica del driver radeonfb), il kernel tenterà di settare la risoluzione automaticamente interrogando la scheda video tramide VBE/EDID o BIOS, operazione che non sempre può aver successo. Per cui, una volta riavviato il computer con il nuovo kernel, privo di driver vesa, potremmo arrivare a sperimentare veri e propri blocchi del sistema, nel caso in cui il driver radeon non riesca a gestire la nostra scheda specifica. Niente panico, nel caso succeda è possibile forzare il kernel a non usare il driver per radeonfb, specificando a mano in fase di avvio il parametro

vga=normal video=radeonfb:off

aggiungendolo alla fine della stringa del kernel da caricare.

Se invece la console si avvia normalmente con il driver radeonfb, anche se magari non alla risoluzione desiderata, l'unica cosa che dobbiamo fare è cercare di rilevare i parametri ottimali della risoluzione che desideriamo usare e far si che vengano impostati di default all'avvio del sistema.

Il modo più diretto per influenzare la risoluzione all'avvio del sistema è tramite il parametro "video". La sintassi è la seguente

video=driver:[resx]x[resy]-[bpp]@[freq]

per cui supponendo di voler utilizzare la modalità 1280x800 a 23bit a 60hz sarà sufficiente passare a lilo il parametro

video=radeonfb:1280x800-32@60

E' bene fare un po' di prove per ottenere il settaggio ottimale, o più semplicemente consultare il manuale della nostra scheda video/monitor per ottenere un elenco delle combinazioni risoluzione/frequenza disponibili. Una volta trovata la modalità desiderata, è possibile forzare il settaggio automatico della risoluzione all'avvio aggiungendo al file lilo.conf le righe

vga=normal
append="video=radeonfb:1280x800-32@60"

e quindi aggiornare lilo come al solito con il comando lilo privo di parametri.

E' possibile passare parametri aggiuntivi al driver radeonfb. Questo è l'elenco completo:

noaccel

tipo: booleano (true/false)
default: false
descrizione: disable acceleration

default_dynclk

tipo: numerico
default: 0
descrizione: -2=enable on mobility only,-1=do not change,0=off,1=on

nomodeset

tipo: booleano (true/false)
default: false
descrizione: disable actual setting of video mode

mirror

tipo: booleano (true/false)
default: false
descrizione: mirror the display to both monitors

force_dfp

tipo: booleano (true/false)
default: false
descrizione: force display to dfp

ignore_edid

tipo: booleano (true/false)
default: false
descrizione: Ignore EDID data when doing DDC probe

monitor_layout

tipo: stringa
descrizione: Specify monitor mapping (like XFree86)

force_measure_pll

tipo: booleano (true/false)
default: false
descrizione: Force measurement of PLL (debug)

nomtrr

tipo: booleano (true/false)
default: false
descrizione: disable use of MTRR registers

panel_yres

tipo: numerico intero
default: 0
descrizione: set panel yres

mode_option

tipo: stringa
descrizione: Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]"

force_sleep

tipo: booleano (true/false)
default: false
descrizione: force D2 sleep mode on all hardware

ignore_devlist

tipo: booleano (true/false)
default: false
ignore workarounds for bugs in specific laptops

Ad esempio, per disattivare l'utilizzo dei mtrr e contemporaneamente settare una risoluzione specifica, usare

video=radeonfb:1280x800-32@60,nomtrr

Purtroppo però, spesso il driver radeonfb non supporta correttamente ogni tipo di scheda/risoluzione in fase di avvio, nonostante tutti i nostri tentativi (ancora, c'era da dubitarne?) per cui non è possibile settare la risoluzione ottimale in fase di avvio ma solo una risoluzione che gli si avvicina molto. Fortunatamente, su linux esistono una quantità di tool userspace per cambiare la risoluzione della console frame buffer a kernel avviato, fra cui spicca fbset.

[modifica] Personalizzazione manuale della configurazione tramite fbset e fb.modes

fbset è un semplice programma che permette di cambiare a kernel avviato la risoluzione della console frame buffer. fbset utilizza Il file /etc/fb.modes per impostare i vari aspetti delle varie modalità video. fb.modes è utilizzato tanto dal comando fbset quanto da tutti gli altri tool/software che visualizzano grafica all'interno della console (ad esmepio mplayer e fbsplash).

Di default, il file fb.modes contiene una serie di modeline standard, ereditate dalle modalità vesa. Comunque, all'interno della directory /usr/share/doc/fbset-versione è possibile trovare un file con le modeline specifiche per le schede ATI. Procediamo quindi con il sostituirlo a quello standard.

cp /usr/share/doc/fbset-2.1/fb.modes.ATI /etc/fb.modes

A questo punto possiamo editarlo ed eventualmente cambiarne delle parti, per adattarle alle nostre esigenze. Purtroppo, il file fb.modes.ATI non è completo, ed inoltre la sintassi di fb.modes è tutto fuorchè semplice. Esistono comunque un paio di modi per aggirare almeno in parte il problema.

Il primo consiste nel visualizzare le informazioni relative alla modalità corrente, per poi aggiungerle al file fb.modes nel caso mancassero. Questo è ottimo per chi utilizza prodotti come la mobility radeon 9700, la quale ha un supporto vesa a dir poco scadente. Per rilevare la modalità corrente, è sufficiente scrivere fbset privo di parametri. L'output sarà simile al seguente:

mode "1280x800-60"
    # D: 68.904 MHz, H: 48.937 kHz, V: 59.972 Hz
    geometry 1280 800 1280 800 8
    timings 14513 80 8 11 2 40 3
    hsync high
    vsync high
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

A questo punto sarà possibile copiarlo ed incollarlo dentro fb.modes, per poi procedere alla personalizzazione o per utilizzarlo come base per costruire altri modeline, ad esempio:

mode "1280x800-32@60"
    # D: 68.904 MHz, H: 48.937 kHz, V: 59.972 Hz
    geometry 1280 800 1280 800 32
    timings 14513 80 8 11 2 40 3
    hsync high
    vsync high
endmode

Come avrete notato, ho eliminato le righe "accel" e "rgba", in quanto fbset non comprende quel tipo di parametri. Prima di far ciò è possibile provare a cambiare parametri della modalità e vedere se è supportata. Ad esempio, per provare a cambiare la profondità in bit, si può digitare

fbset -depth 32

Se il comando ha successo, allora si può procedere a visualizzare la nuova modalità con fbset privo di parametri e ad aggiungere il risultato al file fb.modes (avendo l'accortezza di rimuovere le righe con i parametri non supportati). Una volta aggiunta una nuova modalità, si potrà utilizzare il suo nome per richiamarla con fbset, ad esempio:

fbset 1280x800-32@60

Se quindi inseriremo questo comando in uno qualsiasi degli script d'avvio (dentro /etc/rc.d/, ad esmpio rc.S o rc.local), ad ogni avvio verrà impostata la risoluzione corretta.

Il secondo metodo per la rilevazione delle modalità consiste nell'utilizzo del tool modetest.

[modifica] Personalizzazione di fb.modes tramite modetest e configurazione del server X

modetest è un tool il cui scopo è generare modeline valide tanto per fbset quanto per X. E' possibile reperirlo sul sito del progetto fbmodes

La compilazione ed installazione sono abbastana semplici, non molto diversi da quello che siamo soliti fare su Slackware:

tar -jxvf fbmodes-1.2.3.tar.bz2
cd fbmodes-1.2.3
make
make install
ldconfig

la necessità di lanciare manualmente ldconfig deriva dal fatto che fbmodes installa una nuova libreria cui si linka dinamicamente, libargh. Senza il comando ldconfig, potremmo ricevere un errore di libreria mancante all'esecuzione del comando.

modetest accetta differenti opzioni. Come minimo, per poter ottenere una modeline, è necessario specificare risoluzione x, risoluzione y e refresh rate desiderati. Ad esempio, per la solita 1280x800 a 60hz:

modetest -x1280 -y800 -r60

Modetest proverà a cambiare la risoluzione, che permarrà fino alla pressione d'un tasto, per poi visualizzare un output simile al seguente:

# fbset mode:
# Generated with: modetest -n -x1280 -y800 -r60
mode "1280x800-60"
    # D: 64.673 MHz, H: 48.120 kHz, V: 60.000 Hz
    geometry 1280 800   1280 800   8
    timings 15462  0 0  0 0  64 2
    vsync high
    hsync high
endmode
# XF86Config modeline
Modeline "1280x800-60"     64.673   1280 1280 1344 1344   800 800 802 802
# TextConfig modelines
"160x100-8x8-60Hz"     48.120   1280 1280 1344 1344   800 800 802 802  font 8x8
"142x100-9x8-60Hz"     48.120   1280 1280 1344 1344   800 800 802 802  font 9x8
"160x57-8x14-60Hz"     48.120   1280 1280 1344 1344   800 800 802 802  font 8x14
"142x57-9x14-60Hz"     48.120   1280 1280 1344 1344   800 800 802 802  font 9x14
"160x50-8x16-60Hz"     48.120   1280 1280 1344 1344   800 800 802 802  font 8x16
"142x50-9x16-60Hz"     48.120   1280 1280 1344 1344   800 800 802 802  font 9x16

Questo è MOLTO comodo per verificare che i settaggi che stiamo provando effettivamente funzionino. Le parti che c'interessano maggiormente sono la sezione "mode" e la sezione "XF86Config modeline". La prima, come già abbiamo visto, andrà inserita all'interno del file /etc/fb.modes, procedendo eventualmente a personalizzarla (cambiando il numero di BPP, aggiustando il refresh, la dimensione della zona invisibile, etc). La seconda potrà essere inserita all'interno del file /etc/X11/xorg.conf per far si che la risoluzione di X e la risoluzione del framebuffer coincidano. Questo è molto molto importante nel caso si voglia far si che il driver di X riesca a condividere la memoria e le funzioni del driver frame buffer (il che incrementa notevolmente le performance), ed è ancora più utile nel caso non si disponga dei modeline specifici per la nostra combinazione monitor/scheda e si desideri personalizzarli all'interno di X. Per quanto riguarda le prove con gli altri parametri, consiglio caldamente di seguire le istruzioni sul sito di fbmodes nella sezione 5 (Online Demo).

Per inserire la modeline nel file xorg.conf, oltre ai parametri specificati nel resto di questa guida inserire nella sezione Monitor la riga prodotta da modetest, ad esempio:

Section "Monitor"
  [...]
  Modeline "1280x800-60"     64.673   1280 1280 1344 1344   800 800 802 802
EndSection

Ed assicurarsi che la modeline figuri nell'opzione Modes all'interno della sezione Screen, sottosezione Display, ad esempio:

Section "Screen"
       Identifier "aticonfig-Screen[0]"
       Device     "aticonfig-Device[0]"
       Monitor    "aticonfig-Monitor[0]"
       DefaultDepth     24
       SubSection "Display"
               Viewport   0 0
               Depth     24
               Modes    "1280x800-60" "1280x800" "800x600" "640x480"
       EndSubSection
EndSection

Infine, controllare che nella sezione "Device" sia presente l'opzione UseFBDev, ad esempio:

Section "Device"
       Identifier  "aticonfig-Device[0]"
       Driver      "fglrx"
       Option      "UseFBDev" "True"
       [...]
EndSection

Può accadere che l'output visualizzato da modetest non corrisponda effettivamente alla risoluzione impostata dalla scheda video, in quanto il driver tenta sempre di adattare le richieste dell'utente per evitare di danneggiare l'hardware. In tal caso, usare fbset per visualizzare la modeline reale, aggiungerla al file fb.modes come spiegato nel paragrafo precedente quindi convertirle nel formato di X con lo script ruby presente nella cartella dove avete estratto e compilato modetest (non viene installato dentro /usr con make install, perciò va eseguito da li dentro). Ad esempio:

chmod +x fb2x.rb
./fb2x.rb < /etc/fb.modes

E' anche possibile ottenere la modeline corrente dall'interno del server X in esecuzione, digitando da una console il comando:

xvidtune -show

Questo comando è molto comodo per verificare che X stia effettivamente usando i modeline che abbiamo impostato. Con xvidtune è anche possibile provare i vari settaggi per le modeline in modo interattivo, da interfaccia grafica, per poi ottenere la modeline in formato testuale premendo il tasto "show".

NB: fate sempre ESTREMA ATTENZIONE nel provare i vari settaggi per la vostra scheda video.
Giocare troppo con settaggi come la frequenza e simili può causare danni hardware, nello scenario peggiore.

Se per caso cambiando risoluzione vedete sballare i font, assumendo dimensioni errate, il motivo è probabilmente che non avete impostato la grandezza del display nella sezione relativa al monitor, un opzione raramente settata. Per via del funzionamento di X e dei vari Desktop Environment, è impossibile ottenere una buona visualizzazione e coerenza nel calcolo delle dimensioni dei font se non segnalate ad X quanto è grande, in millimetri, il vostro monitor. A questo scopo, potete

  • cercare le specifiche tecniche del monitor
  • armarvi di righello e fare qualche confronto con le dimensioni da voi rilevate e quelle che trovate su internet.

Per il monitor del mio laptop, ad esempio, il settaggio corretto è il seguente:

Section "Monitor"
       [...]
       DisplaySize  332 207
       [...]
EndSection

Purtroppo, in taluni casi, è impossibile comunque impostare modeline personalizzate per la propria scheda video radeon, fino ad un certo limite. Questo dipende dalla versione del driver che stiamo usando E dal tipo di monitor collegato. Ad esempio, pare che quando si utilizzi un monitor LCD in un laptop, ogni modeline custom venga ignorato. E' ovviamente necessario fare un po' di tentativi per scoprire cosa si può personalizzare e fino a che punto.

[modifica] Installazione dei driver open source

Più che di installazione è più corretto parlare di configurazione dei driver open source. Questo passo è quanto mai semplice: siccome il driver è già incluso nel kernel linux, dovremo solamente apportare alcune modifiche al file /etc/X11/xorg.conf facendo usare il modulo 'radeon' al server X. Potete, quindi, proseguire saltando direttamente qui.

[modifica] Installazione dei driver proprietari

Per quanto riguarda i driver Open Source, come detto precedentemente, non è necessario installare nessun altro pacchetto aggiuntivo. La sola compilazione del kernel è sufficiente. Per utilizzare i driver porpietari invece è necessario installare il pacchetto specifico. ATI mette a disposizione i propri driver nel formato eseguibile .run. Il formato .rpm non è più distribuito.

L'eseguibile .run può essere installato in due maniere differenti.

[modifica] Compatibilità con Kernel Linux e Server X

Purtroppo i driver propietari non possono essere compilati con ogni versione del kernel linux e del server X. E' molto probabile che con versioni del kernel troppo successive a quelle contemporanee al rilascio del driver stesso (o troppo precedente), semplicemente il driver non si compili. In fase di download del driver, quindi, verificarne la compatibilità leggendo le specifiche di rilascio del driver.

NB: bisogna ricordarsi che ad ogni cambiamento di versione del kernel o del server X i driver proprietari vanno reinstallati o ricompilati.

[modifica] Installazione tramite slackbuild

Questa modalità (consigliata), consiste nell'usare uno slackbuild (grazie al lavoro di targzeta) il quale creerà due pacchetti slackware: uno che è il driver vero e proprio e l'altro che è il modulo per il kernel in uso.

A tal proposito seguite la guida di installazione che ha creato lo stesso targzeta: ATI Proprietary Drivers. Ecco uno slackbuild.

[modifica] Installazione automatica

Questa modalità di installazione,invece, è quella automatica che si effettua con il comando:

sh nome_driver.run

A questo punto seguite le indicazioni che vi fornisce l'installer (una mini-guida la trovate qui): http://www.slackware-italia.com/forum/viewtopic.php?t=3281

Se non ci sono estati errori di compilazione e/o installazione il driver risulterà installato.

[modifica] Caricamento e Configurazione dei driver

Una volta configurato correttamente il kernel ed installato eventualmente il package dei driver propietari, sarà possibile utilizzare finalmente i driver, previa configurazione. Per ottenere dei driver completamente funzionanti, è necessario procedere attraverso tre passaggi:

  • caricamento dei moduli kernel per la gestione del bus (PCI Express od AGP) e dei driver specifici
  • montaggio del filesystem tmpfs
  • configurazione del file /etc/X11/xorg.conf per il corretto funzionamento di X

[modifica] Caricamento dei moduli kernel

Senza il caricamento dei giusti moduli kernel, sarà impossibile ottenere l'accellerazione hardware sotto X. Innanzitutto, occorre verificare che sia caricato il giusto modulo per la gestione del bus. Nel nostro esempio, il bus sarà di tipo AGP.

root@laptop:~# lsmod | grep agp
amd64_agp              12292  1
agpgart                31152  1 amd64_agp

Come potete vedere, è caricato tanto il modulo agpgart quanto il modulo specifico del chipset. Nel caso non compaiano nell'elenco, è possibile caricarli con i comandi:

modprobe agpgart
modprobe chipset_agp

Per quanto riguarda il bus PCI Express, è possibile compilarlo staticamente (come consigliato nella sezione precedente) senza compromettere il funzionamento dei driver X, per cui non è necessario caricare nessun modulo.

A questo punto, è necessario caricare i moduli relativi al tipo di driver che vogliamo utilizzare.

NB: è importante, se si è già installato il driver propietario, verificare che non sia caricato prima del caricamento dei driver Open Source. Per esserne sicuri, è sufficiente digitare "rmmod fglrx" prima di effettuare il caricamento. Lo stesso discorso vale al contrario, per cui prima di caricare il driver propietario digitare "rmmod radeon" e "rmmod drm".

  • Per quanto riguarda i driver Open Source, digitiamo:
modprobe drm
modprobe radeon

Quindi, verifichiamone il corretto caricamento:

root@laptop:~# lsmod | grep drm
drm                    74260  1 radeon
agpgart                31152  2 drm,amd64_agp
  • Per quanto riguarda il driver propietario, invece, il modulo si chiamerà fglrx.
root@laptop:~# lsmod | grep fglrx
fglrx                 726528  11
agpgart                31152  2 fglrx,amd64_agp

Nel caso in cui il modulo non risulti caricato, è possibile caricarlo manualmente:

modprobe fglrx

Se il driver è stato installato nel modo corretto, non dovrebbero esserci problemi di sorta e si potrà passare allo step successivo.

[modifica] Montaggio del filesystem tmpfs

Come spiegato nella sezione sul kernel, per permettere a tutti gli utenti di avere accesso all'accellerazione Hardware sotto X è necessario montare un filesystem specifico, il filesystem tmpfs (una volta chiamato shm). A questo scopo, è sufficiente editare il file /etc/fstab ed inserire la seguente riga in un punto qualsiasi (se non già presente)

tmpfs    /dev/shm    tmpfs    defaults    0  0

quindi, come utente root, digitare

mount /dev/shm

oppure riavviare. Ad ogni riavvio il filesystem verrà montato automaticamente.

A questo punto, è possibile passare allo step finale.

[modifica] Configurazione di X per i driver Open Source

Modificheremo il file /etc/X11/xorg.conf a mano, senza utilizzare nessuna utility offerta dal sistema. In Section "Module" aggiungiamo:

Load "dri"

e assicuriamoci che la riga del modulo glx sia decommentata:

Load "glx"

In Section "Device" sostituiamo la riga:

Driver "vesa"

con

Driver "radeon"

poi aggiungiamo l'opzione:

Option "DRI" "true"

Infine dobbiamo aggiungere questa sezione al fondo del file /etc/X11/xorg.conf:

Section "DRI"
    Group   0
    Mode    0666
EndSection

in modo tale da conferire i permessi agli utenti normali per utilizzare il driver (posto che l'utente sia stato aggiunto al gruppo video nel file /etc/group).

Nota: per chi volesse usare questi driver, è disponibile anche un form on-line nel quale è possibile verificare se il chipset della scheda video è supportato dal kernel, basterà incollare l'output di lspci -n della propria scheda video in questo sito: http://kmuto.jp/debian/hcl/

[modifica] Configurazione di X per i driver Propietari

Per modificare xorg.conf abbiamo anche in questo caso due modalità: quella automatica con il comando

aticonfig --initial --input=/etc/X11/xorg.conf

o quella manuale. Dovremo perciò eventualmente decommentare la riga in Section "Module":

Load    "glx"

e aggiungere:

Load     "dri"

Infine dobbiamo sostituire la riga in Section "Device" della nostra scheda video:

Driver    "vesa"

con

Driver    "fglrx"

[modifica] Parametri aggiuntivi del server X

Esistono alcuni parametri che si possono aggiungere e che sono comuni ai due tipi di driver.

Se la scheda è dotata di memoria video dedicata, possiamo specificare a X il quantitativo di memoria che usa la scheda in questo modo:

VideoRam    memoria_in_bytes

dove memoria_in_bytes è il quantitativo di memoria della scheda (espresso in MBytes) moltiplicato per 1024. Ad esempio io che ho 128 MB di memoria scriverò (128 * 1024 = 131072):

VideoRam    131072

Possiamo anche aggiungere altre informazioni opzionali. Una di queste è relativa all'identificatore dello standard usato dal bus della scheda:

BusID   "PCI:01:00:0"

Tipicamente il numero lo si legge dall'output di lspci. Altri specificatori aggiuntivi possono essere:

VendorName    "ATI Technologies Inc."
BoardName     "ATI Mobility Radeon 9700 128 MB VRAM"

L'importante è che il nome che c'è in Identifier coincida esattamente con quello della Section "Screen" -> Device.

[modifica] Verifica dell'installazione

Bene, ora che abbiamo configurato il driver possiamo verificare se tutto funziona correttamente. Il primo controllo da fare è dare il comando

startx

Se il nostro window manager viene caricato il file xorg.conf non contiene errori. Per chi ha installato i driver open source e vuole vedere se il 3D funziona basta dare i comandi:

glxinfo | grep "direct rendering"
glxinfo | grep OpenGL

se otteniamo 2 output come questi:

direct rendering: Yes
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R300 20060815 AGP 8x x86/MMX/SSE2 TCL
OpenGL version string: 1.3 Mesa 6.5.2
OpenGL extensions:

Allora potete godervi l'accelerazione della vostra scheda video. Per fare un piccolo test prestazionale sulla vostra scheda date il comando:

glxgears

nel quale appariranno a console i fps (frame per secondo) e una finestra a grafica 3D. Valori normali non dovrebbero scendere sotto i 1000 fps.

Per chi ha installato i driver proprietari la verifica è da fare con questi comandi analoghi ai precedenti:

fglrxinfo | grep "direct rendering"
fglrxinfo | grep OpenGL

che (se tutto è andato bene), daranno degli output del tipo:

direct rendering: Yes
OpenGL vendor string: ATI Technologies Inc. 
OpenGL renderer string: MOBILITY RADEON 9700 Generic 
OpenGL version string: 2.0.6011 (8.28.8)

e infine:

fgl_glxgears	(analogo di glxgears)

[modifica] Miglioramento delle prestazioni

Premessa: questo paragrafo contiene delle modifiche che possono incrementare, lasciare invariate, decrementare le prestazioni video, oppure, in alcuni casi, rendere addirittura il sistema instabile. Il risultato dipende dalla macchina, dalla scheda video (dal suo quantitativo di memoria) e da altri fattori, bisogna solo fare tante prove e trovare la configurazione ottimale che massimizzi le prestazioni video del proprio computer.

Possiamo iniziare. Quello che ci serve sono le informazioni relative alla scheda madre e alla scheda video (ovviamente). Diamo il comando:

lspci -vv

il quale mostra tutte le informazioni possibili dei vari componenti riconosciuti. Per la scheda madre (la identificate con il nome di Host Bridge) otterrete un output del tipo:

00:00.0 Host bridge: Silicon Integrated Systems [SiS] 645xx (rev 51)
    Subsystem: ASUSTeK Computer Inc. Unknown device 1927
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
    Latency: 32
    Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size=64M]
    Capabilities: [c0] AGP version 3.5
        Status: RQ=32 Iso- ArqSz=2 Cal=3 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3+ Rate=x4,x8
        Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8

mentre per la scheda video un output del tipo:

01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA])
    Subsystem: ASUSTeK Computer Inc. Unknown device 1942
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
    Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
    Latency: 64 (2000ns min), Cache Line Size: 32 bytes
    Interrupt: pin A routed to IRQ 22
    Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
    Region 1: I/O ports at c800 [size=256]
    Region 2: Memory at dfef0000 (32-bit, non-prefetchable) [size=64K]
    Expansion ROM at dfec0000 [disabled] [size=128K]
    Capabilities: [58] AGP version 3.0
        Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
        Command: RQ=32 ArqSz=2 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8
    Capabilities: [50] Power Management version 2
        Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
        Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Come potete notare, alla maggior parte dei parametri presenti, è postfisso un + o un -. Questo vuol dire che tale parametro è supportato dall'hardware oppure no. A noi interessano i parametri GART64, 64bit, FW, AGP e Rate presenti sotto le voci Capabilities -> Status di ogni componente. Ogni opzione che seguirà andrà inserita nella Section "Device" della scheda video e avrà effetto soltanto se supportata dall'hardware (come è stato appena detto). Vediamoli in dettaglio:

GART64 / 64bit : essi si riferiscono ad architetture a 64 bit.

Option    "AGPGart"    "true"
Option    "GARTSize"    "64"

AGP: indica la connessione della scheda video.

Option    "AGPFastWrite"    "true"

Rate: indica la velocità di trasferimento massima (transfert rate) del bus video dedicato.

Option    "AGPMode"    "8"

FW : è l'abbreviazione di Fast Write, ovvero se sia la scheda madre che la scheda video supportano le scritture rapide, potremo settare alcune opzioni in xorg.conf, altrimenti tali opzioni non avranno alcun effetto. Per riuscire ad abilitare le scritture rapide anche nella scheda madre bisogna cercare nelle impostazioni del BIOS (se presenti).

Option    "TripleBuffer"     "true"
Option    "EnablePageFlip"   "true"
Option    "ColorTiling"      "true"
Option    "UseFBDev"         "true"   #verificare di aver configurato correttamente il frame buffer
Option    "backingstore"     "true"
Option	  "RenderAccel"      "true"
Option    "AccelMethod"      "XAA"    #oppure "EXA"

[modifica] Alcuni tools grafici

[modifica] Driver open source: Driconf

Per chi desidera configurare alcuni aspetti dei driver open source, è possibile installare un configuratore che si chiama Driconf, giunto alla versione 0.9.1. Risolte le dipendenze del pacchetto (pygtk, pycairo, pygobject), lo potremo installare con installpkg. Il pacchetto lo troviamo qui su slacky.eu [1]. Per una lista delle sue caratteristiche e modifiche che tale configuratore può apportare al driver consultate questa pagina: http://dri.freedesktop.org/wiki/ConfigurationOptions

[modifica] Driver proprietari: FglrxKonf

Anche per i driver proprietari è stato creato un front-end grafico. Anch'esso lo possiamo prelevare sempre qui da slacky.eu:[2]. Con esso sarà possibile modificare alcuni aspetti quali la possibilità di attivare il dual-head, tv-out, o di ottenere informazioni sull'installazione.

NOTA: prima di apportare modifiche alla configurazione con questi tools grafici fatevi sempre un backup della configurazione. Il consiglio è comunque quello di apportare le modifiche a mano, e ricorrere in misura minore a modifiche con questi configuratori.

[modifica] Rimozione del driver

[modifica] Rimozione del driver open source

Basterà sostituire il file /etc/X11/xorg.conf con il nostro file di backup.

[modifica] Rimozione dei driver proprietari

  • Per chi invece ha installato il driver senza la creazione dei pacchetti slackware, può lanciare lo script di disinstallazione della ATI con il comando:
sh /usr/share/fglrx/fglrx-uninstall.sh

Successivamente, dovremo rimuovere e installare nuovamente il pacchetto delle librerie mesa (lo possiamo prendere da un mirror o dal cd/dvd di slackware):

removepkg mesa
installpkg mesa-6.5.2-i486-1.tgz

Dopo la rimozione del driver, sostituiremo il file /etc/X11/xorg.conf con il nostro file di backup.

[modifica] Risoluzione dei problemi più comuni

[modifica] Errori di configurazione

E' impensabile fare una panoramica di tutti gli errori possibili e che si possono incontrare durante l'installazione e la configurazione (soprattutto con i driver ATI!); ad ogni modo cercherò di illustrare i problemi più comuni. Se ottenete un messaggio del genere all'avvio del vostro window manager:

Parse error on line 415 of section Device in file /etc/X11/xorg.conf 
File /etc/X11/xorg.conf 
(EE) Problem parsing the config file 
(EE) Error parsing the config file 

allora avete commesso un errore di sintassi nelle opzioni che avete inserito in /etc/X11/xorg.conf: ricontrollatele.

[modifica] Informative dei log

In ogni caso, tenete sempre d'occhio gli eventuali errori del file log di X, con il comando:

grep "(EE)" /var/log/Xorg.0.log

per chi usa i driver proprietari e ha optato per l'installazione senza la creazione dei pacchetti slackware, viene anche creato un log in /lib/modules/fglrx della sua compilazione; consultatelo quindi con il comando:

cat /lib/modules/fglrx/make.$(uname -r).log

[modifica] Problemi con il driver "radeon"

[modifica] Utilizzo del driver generico

Un altro errore, meno frequente, ma che può capitare, riguarda il modulo "radeon" dei driver open source. Su alcune architetture il comando glxgears può dare risultati incoerenti rispetto alle operazioni che l'utente sta facendo e grossi sbalzi riguardo ai fps, se non addirittura crash del sistema. Una possibile soluzione è provare a sostituire il modulo "radeon" con il driver ati generico (presente anch'esso nel kernel slackware). Sostituiremo quindi la riga del modulo "radeon" con:

Driver    "ati"

[modifica] Patch al driver radeon

Per chi ha problemi con il modulo "radeon" può provare i driver patchati che si trovano su un mirror o nel cd/dvd di slackware [3]. Non è escluso che potrebbero risolvere. Per applicare la patch basterà dare il comando di aggiornamento del pacchetto:

upgradepkg xf86-video-ati-6.6.3-i486-3.tgz

Se non funzionano bene si può sempre ripristinare il pacchetto originale.

[modifica] Aggiornamento del driver radeon

In alternativa ai driver patchati e grazie alla modularità del nuovo xorg inserito nella Slackware 12.0, possiamo aggiornare il driver open source con gli ultimi rilasciati per la versione 7.3 di X (sempre se avete problemi con i driver attualmente installati nel vostro sistema). Scaricheremo il pacchetto .tgz all'indirizzo: http://submax.altervista.org/slackware/xf86-video-ati-6.7.197-i486-1sm.tgz. Una volta estratti i files in una directory a piacere, aggiorneremo il driver:

upgradepkg xf86-video-ati-6.7.192-i486-1sm.tgz

[modifica] Problemi con il driver ufficiale (fglrx)

[modifica] Corruzione dello schermo nell'angolo in basso a destra

Con versioni recenti dei driver (> 8.42.x), è molto probabile che si manifesti un problema di corruzione dello schermo usando xorg, nell angolo in basso a destra dello schermo. Per risolvere il problema, è sufficiente assicurarsi che nella "Section Device" del proprio xorg.conf sia presente la riga:

Option     "XAANoOffscreenPixmaps"    "true"

[modifica] Tips & Tricks: abilitare il supporto per i compositing window managers

La slackware 12.0 adotta, tra le molte novità introdotte, la versione modulare di xorg 7.2, il quale supporta alcune opzioni per i cosiddetti "compositing window managers", quali compiz o beryl. In questo paragrafo tratteremo solamente la configurazione di xorg.conf per avere i requisiti neccessari a fare funzionare questi window managers, non l'installazione dei window managers stessi. Ricordo, inoltre, che l'uso di questi window managers può decrementare in modo più o meno marcato le prestazioni video a seconda del tipo di architettura della macchina e il requisito fonamentale per il loro funzionamento è che i driver abbiano il supporto 3D abilitato.

In Section "ServerLayout" aggiungiamo la riga:

Option    "AIGLX"    "true"

Aggiungiamo alla fine del file /etc/X11/xorg.conf questa sezione:

Section "Extensions"
    Option    "Composite"    "true"
    Option    "RENDER"       "true"
    Option    "DAMAGE"       "true"
EndSection

Infine, aggiungiamo queste opzioni nella Section "Device" della nostra scheda video:

Option     "XAANoOffscreenPixmaps"    "true"
Option	   "ADDARGBGLXVIsuals"        "true"
Option	   "AllowGLXWithComposite"    "true"
Option	   "DisableGLXRootClipping"   "true"

Per l'installazione e l'uso dei compositing window manager fare riferimento alle apposite guide di configurazione e installazione presenti in rete.

[modifica] Conclusione

Abbiamo visto come è possibile installare i driver ati su un sistema Slackware GNU/Linux 12.0; ovviamente questa guida può essere usata anche per altre distribuzioni con qualche piccola modifica. Il consiglio della maggior parte di utenti per quanto riguarda i driver di schede ati e di provare prima i driver open source e solo se non si ha un sistema funzionante ricorrere ai proprietari. Bene, è tutto. Spero che questa guida sia utile alla maggior parte di utenti. Se avete suggerimenti, consigli, critiche o trovate errori potete contattarmi via mail.

[modifica] Riferimenti utili

http://www.gentoo.it/doc/ati-radeon-faq.html

[modifica] Ringraziamenti

targzeta, per aver concesso la sua guida sui driver proprietari, per i suoi preziosi consigli e per la sua disponibilità

submax82, per aver rilasciato il pacchetto aggiornato dei driver radeon

nuitari, per gli importanti e significativi aggiornamenti applicati a questa guida


Autore: ekxius - ekxius@gmail.com

Strumenti personali
Namespace

Varianti