Repository 32bit  Forum
Repository 64bit  Wiki

Framebuffer Console HOWTO: differenze tra le versioni

Da Slacky.eu.
m
(Supporto VESA tramite uvesafb)
Riga 739: Riga 739:
Se si desidera utilizzare un driver vesa migliore, nel caso in cui non esista un driver specifico per la nostra scheda video, è possibile fortunatamente utilizzare "uvesafb", un driver VESA prodotto da uno sviluppatore indipendente, reperibile sul [http://dev.gentoo.org/~spock/projects/uvesafb/ sito di spock], uno sviluppatore di Gentoo.
Se si desidera utilizzare un driver vesa migliore, nel caso in cui non esista un driver specifico per la nostra scheda video, è possibile fortunatamente utilizzare "uvesafb", un driver VESA prodotto da uno sviluppatore indipendente, reperibile sul [http://dev.gentoo.org/~spock/projects/uvesafb/ sito di spock], uno sviluppatore di Gentoo.
  +
  +
'''NB:''' dalla serie 2.6.24 il supporto è stato incluso nel kernel vanilla. Pertanto non sarà necessario applicare patch.
Le caratteristiche principali di uvesafb, vantaggiose rispetto a vesafb, sono:
Le caratteristiche principali di uvesafb, vantaggiose rispetto a vesafb, sono:
Riga 747: Riga 749:
Gli svantaggi di uvesafb sono:
Gli svantaggi di uvesafb sono:
* la necessità di patchare il kernel
+
* la necessità di patchare il kernel '''per una serie precedente alla 2.6.24'''
* qualche incompatibilità con alcune schede. E' possibile che vesafb supporti un maggior numero di chipset, per quanto meno evoluto.
* qualche incompatibilità con alcune schede. E' possibile che vesafb supporti un maggior numero di chipset, per quanto meno evoluto.
Riga 757: Riga 759:
==Patchare il Kernel==
==Patchare il Kernel==
  +
  +
'''NB:''' Se si possiede un kernel della serie 2.6.24, il supporto è incluso di default, pertanto non è necessario patchare.
Allo scopo di attivare il supporto ad uvesafb, è necessario applicare al kernel la giusta patch, scaricandola sempre [http://dev.gentoo.org/~spock/projects/uvesafb/archive/ dal sito di spock]. E' importante usare l'ultima patch disponibile, '''anche se non corrisponde alla nostra versione del kernel'''. Quindi, innanzitutto ci posizioneremo all'interno dei sorgenti del kernel:
Allo scopo di attivare il supporto ad uvesafb, è necessario applicare al kernel la giusta patch, scaricandola sempre [http://dev.gentoo.org/~spock/projects/uvesafb/archive/ dal sito di spock]. E' importante usare l'ultima patch disponibile, '''anche se non corrisponde alla nostra versione del kernel'''. Quindi, innanzitutto ci posizioneremo all'interno dei sorgenti del kernel:

Versione delle 16:59, 26 gen 2008

Indice

Disclaimer

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

Prerequisiti

Questa guida usa come riferimento la distribuzione 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.

Si consiglia caldamente:

  • di stampare la guida prima di procedere al suo utilizzo. In questo modo, se modificando il kernel o lilo si dovessero commettere degli errori, si potrà comunque avere accesso alle informazioni utili a recuperare l'utilizzo del sistema.
  • di conservare sempre un kernel configurato e funzionante, aggiungendo il kernel modificato (nel caso sia necessario) come kernel aggiuntivo ed opzionale, per lo stesso motivo di cui sopra.

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

Introduzione

Esistono differenti modalità di visualizzazione della console in Linux. La modalità classica è la modalità VGA. 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à grafiche superiori a VGA tramite l'utilizzo del frame buffer e degli standard VESA. 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.

Le distribuzioni più diffuse includono nel kernel di default il supporto automatico alla console frame buffer tramite il driver standard VESA, un driver generico in grado di gestire tutte le schede che rispettano le specifiche VBE (Video BIOS Exensions). 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 funzionando. 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. Inoltre, essendo le distribuzioni configurate per funzionare sul più ampio "spettro" di configurazioni hardware possibili, difficilmente lo stesso driver VESA sarà ottimizzato per ottenere il massimo delle performance.

Lo scopo di questa guida è guidare l'utente attraverso i vari passaggi necessari ad ottenere una corretta configurazione del framebuffer ed una console grafica funzionante che ne faccia utilizzo.

Nozioni di Base

Console e Terminali virtuali

In informatica, per console s'intende tanto l'insieme dei dispositivi hardware (comunemente detto "terminale") quanto le componenti software necessarie all'interazione con un sistema, sia esso un computer od altro.

In un normale personal computer, dal lato hardware la console è solitamente costituita dall'insieme tastiera/monitor, dal lato software da un interfaccia di tipo testuale (CLI, Command Line Interface). Nei moderni computer lo scopo principale della console è amministrativo. Genericamente attraverso la console si visualizzano informazioni sull'avvio o sullo stato del sistema e si avviano gli applicativi o gli ambienti per l'utilizzo effettivo del computer (solitamente grafici).

Per quanto riguarda Linux, è possibile compiere pressoché qualsiasi operazione da console. Considerato però che il terminale fisico dispone spesso di uno spazio relativamente limitato per la visualizzazione delle informazioni (un monitor), è molto facile sentirsi "stretti". Proprio per questo motivo, Linux implementa i cosiddetti "Terminali (o Console) Virtuali" (fra i tanti tipi di console che supporta), il cui scopo è permettere di eseguire sullo stesso terminale fisico più istanze della console, ognuna collegata ad un proprio terminale virtuale, permettendo di switchare fra di esse con la pressione di qualche semplice HotKey (ALT+F1, ALT+F2, etc).

Tramite le console virtuali sarà quindi possibile, ad esempio, effettuare in una console la conversione di un mp3 mentre in un altra console si tiene d'occhio l'utilizzo della CPU con un programma apposito, mentre in un altra console ancora un client bittorrent scarica un file. Per un utente Linux questo modo di operare rappresenta il normale utilizzo del computer, anche se si tratta a tutti gli effetti di una conquista, valutando la storia dei terminali e delle console nell'informatica.

La console VGA

Come detto, il dispositivo normalmente usato per la visualizzazione delle console è il monitor. In realtà, il monitor serve solo per "proiettare" ciò che il vero dispositivo per la gestione video realizza, l'adattatore grafico, o scheda video.

Storicamente parlando, sono esistiti una quantità notevole di adattatori grafici, ognuno con un proprio standard e proprie caratteristiche. Man mano che la qualità degli adattatori grafici cresceva, la qualità dei monitor cresceva di pari (a volte) passo.

Fra tutti gli standard che nel tempo si sono susseguiti (CGA, EGA, etc), lo standard VGA (dovuto ad IBM) è stato il primo ad essere unanimemente accettato ed implementato dai vari produttori hardware e software, diffondendosi al punto tale che oramai è considerato il minimo comune denominatore che i personal computer devono avere per la gestione della grafica. Basti pensare che sistemi operativi diffusi come Windows si avviano visualizzando splash screen in modalità VGA senza nemmeno prendere in considerazione l'ipotesi che l'hardware non possa supportarlo.

Le caratteristiche principali dello standard VGA, utili a questo articolo, sono una risoluzione massima di 640x480 pixel (il pixel per chi non lo sapesse è un singolo punto rappresentabile su schermo) ed una profondità massima di 256 colori a 70hz, oltre alla possibilità di operare sullo schermo considerandolo tanto una matrice di caratteri (text mode) quanto una matrice di punti (APA, All Points Addressable) per la visualizzazione di grafica.

Linux implementa la possibilità di utilizzare la console su dispositivi in grafica VGA per le console virtuali tramite il driver vgacon. Si tratta della normale console a bassa risoluzione cui tutti siamo abituati e che, salvo indicazioni differenti, il kernel Linux carica come driver di default per la console di sistema (vedi oltre). vgacon permette ovviamente l'utilizzo della console in modalità VGA tanto testuale quanto grafica.

SVGA ed oltre

I limiti di VGA si fecero presto sentire, come è ovvio aspettarsi. Per questo motivo, la "Video Electronics Standards Association" (VESA, un consorzio il cui scopo era ed è promuovere e definire standard per l'interoperabilità video) definì un nuovo set di standard, chiamato Super VGA (SVGA). Nella sua prima versione, SVGA permetteva di arrivare ad una risoluzione di 800x600 a 4bit (16 colori), per poi arrivare presto a risoluzioni di 1024x768 ad 8 bit (256 colori) ed oltre. Per quanto oramai lo standard SVGA permetta ben altro, quando si fa riferimento alla "risoluzione SVGA" s'intende una risoluzione di 800x600 pixel, di cui è diventata sinonimo. Per modalità SVGA invece s'intendono normalmente tutte le modalità superiori a VGA (per quanto sia un uso improprio del termine).

Come è solito accadere comunque, molti sviluppatori hardware/software svilupparono nuovi standard al di fuori degli standard VESA (IBM in testa), fra cui citiamo ad esempio XGA, SXGA ed UXGA, ognuna con propri limiti e caratteristiche. Lo scopo è stato a volte l'innovazione, a volte il desiderio di conquistarsi fette di mercato, a volte la pura follia o l'orgoglio smisurato. Il risultato è che all'alba del 2008, dopo 20 anni dalla definizione di VGA, ci troviamo con una confusione assoluta in quanto a standard video e modalità d'accesso e di utilizzo degli adattatori grafici, che raramente rispettano gli standard VESA ed anche quando lo fanno spesso lo fanno a modo proprio. Come se non bastasse, i produttori hardware raramente rilasciano le specifiche tecniche delle proprie schede o dei propri standard. Da questo si deduce quanto possa essere complicato il supporto a questo tipo di dispositivi senza l'utilizzo di driver proprietari.

Nonostante ciò, il kernel linux permette l'utilizzo della console in modalità grafiche superiori alle modalità VGA tramite l'utilizzo della modalità framebuffer.

Framebuffer e Console Framebuffer

Per "framebuffer" s'intende una modalità di utilizzo del dispositivo video basato su un buffer di memoria che contiene le informazioni necessarie alla visualizzazione di un intero fotogramma (detto frame, da cui framebuffer. Rimando ai link a fondo pagina per chi vuole approfondire il discorso).

Su linux questo è implementato tramite un interfaccia standard indipendente dall'hardware, il driver "fbdev", il quale tramite un opportuno driver s'interfaccia a sua volta all'hardware specifico. Gli applicativi disegnano all'interno del framebuffer tramite fbdev, il quale poi visualizza il risultato in parte od interamente utilizzando il driver specifico. In questo modo a conti fatti gli sviluppatori dei vari software non hanno necessità di conoscere alcunché delle schede video che andranno ad utilizzare.

Linux permette di visualizzare le console su dispositivi framebuffer tramite il driver "fbcon", allo scopo di abbattere i limiti delle modalità VGA. Volendo schematizzare, con una console VGA avremo:

Hardware → vgacon → Console

con una console framebuffer avremo:

Hardware → fbdev → fbcon → Console
             ↓
      Driver Specifico

Purtroppo, è facile immaginare che non esistono driver specifici di fbdev per ogni tipo di scheda esistente (basti solo pensare ai vari modelli di schede ATI esistiti ed esistenti). Per questo il kernel linux pur mettendo a disposizione driver per le principali famiglie di schede video (matrox, nvidia, s3, etc) mette a disposizione anche un driver generico che sfrutta gli standard VESA, "vesafb", teoricamente in grado di funzionare su ogni tipo di scheda video a patto che implementi lo standard VESA VBE 2.0 (Video Bios Exstension). Ovviamente essendo gli standard VESA generici per definizione non supportano le caratteristiche peculiari delle singole schede video, tra cui le risoluzioni non standard come quelle wide, per cui vesafb dev'essere considerato veramente l'ultima spiaggia laddove non si riesca ad utilizzare un driver specifico.

Linux e la console

Nelle sezioni precedenti si è appreso come Linux metta a disposizione differenti driver per la console, ma in che modo vengono utilizzati? Il kernel linux utilizza normalmente due tipi di driver per collegare le console all'hardware.

Il primo tipo è quello che viene assegnato dal kernel a tutti i tipi di console virtuali durante il boot process, chiamato "System Driver". In ogni istanza del kernel può essere attivo un solo System Driver e non può mai essere scaricato dalla memoria, per quanto possa diventare inattivo. Questo è il caso di vgacon, solitamente.

Il secondo tipo, detto "Modular Driver", dev'essere esplicitamente caricato. E' possibile avere più Modular Driver in esecuzione sulla stessa istanza del Kernel, ma solo uno d'essi per volta può controllare la console. Questo è il caso di fbcon. Per cambiare Modular Driver su una console è necessario prima disattivare il precedente driver passando la console al System Driver, quindi caricare quello nuovo, operazione detta "Binding/Unbinding". L'operazione tramite cui un Modular Driver prende possesso della console al posto del System Driver è detta "takeover".

NB: è bene non confondere il termine "Modular Driver" con i moduli del kernel, si tratta di due cose differenti. Non è assolutamente necessario che fbcon, fbdev ed i suoi driver siano compilati come moduli per esser considerati tali, anzi, è consigliabile compilare tutto staticamente, se si desidera influenzare il caricamento dei driver all'avvio con i parametri del kernel (vedi oltre).

Per visualizzare il tipo di console driver utilizzati dal kernel, è necessario che sysfs sia abilitato. Se lo è, possiamo esaminare il tipo di driver utilizzati tramite il contenuto di /sys/class/vtconsole/, dove vtcon0 sarà il primo driver caricato (il System Driver), vtcon1 il secondo e via dicendo.

Quindi, ad esempio, per un sistema in cui è in esecuzione come modular driver fbcon:

root@nuitari-laptop:~# cat /sys/class/vtconsole/vtcon1/name
(M) frame buffer device

La (M) indica che si tratta di un Modular Driver. Se si fosse trattato del System Driver, avremmo avuto (S).

Il tipo di System/Modular driver che verranno impostati all'avvio del kernel dipende:

  • dai parametri d'avvio passati al kernel dal bootloader
  • dai supporti ai vari tipi di console compilati all'interno del kernel stesso

Fra tutti i parametri che è possibile passare al kernel per la gestione della console, il più importante è sicuramente il parametro "vga", il quale può assumere uno spettro di valori discretamente ampio (descritto abbondantemente in seguito in questo stesso articolo).

Lo scenario standard

Lo scenario standard è quello in cui il parametro "vga" non è impostato od è impostato a "normal" (od un altra qualsiasi risoluzione VGA). In questo scenario il kernel carica come System Driver per la console il driver "vgacon", per gestirla in modalità VGA.

Trovato fbdev, il kernel carica tutti i driver hardware specifici supportati compilati al suo interno in modo statico, nell'ordine in cui compaiono nel kernel. Se tra questi driver è presente il driver vesafb, linux lo carica sempre per ultimo nel caso siano disponibili altri driver specifici.

Dopo aver caricato fbdev e tutte le sue parti, il kernel procede a verificare se esistono Modular Driver compilati al suo interno in modo statico con cui rimpiazzare vgacon, ad esempio fbcon.

Una volta caricato fbcon, il kernel tenta di effettuare automaticamente un takeover sulla System Console. Se ci riesce, vgacon diventa inerte ed fbcon prende il sopravvento come Modular Driver, sul framebuffer device 0 (/dev/fb0 o /dev/fb/0).

Lo scenario alternativo

Lo scenario alternativo è quello in cui il parametro "vga" è impostato con una qualsiasi modalità grafica superiore alla modalità VGA.

In tal caso il kernel, sapendo che si desidera utilizzare la console in modalità grafica con l'utilizzo di un framebuffer device, non carica il driver vgacon come System Driver ma carica un dummy driver chiamato molto significativamente dummycon.

Il driver dummycon ha la peculiarità di non visualizzare nessun tipo di output, serve solo ed unicamente per permettere al kernel di prendersi il dovuto tempo per caricare il Modular Driver più appropriato secondo lo stesso schema del paragrafo precedente, per poi fargli prendere il sopravvento.

Questo scenario ha due aspetti negativi. Il primo è che se per un caso del destino fbcon non riesce a prendere il sopravvento, ci ritroveremo con una console inutilizzabile poiché muta. Il secondo è che nel momento in cui viene disattivato un Modular Driver per una virtual console (ad esempio per caricarne un altro) ci troveremo con una console nuovamente muta, poiché il controllo viene restituito a dummycon nella sua veste di System Driver.

L'unico pregio di questa soluzione è puramente estetico, in quanto fino all'avvio di fbcon non verrà visualizzato nessun output a video, ideale per la realizzazione di Splash Screen grafici privi di qualsivoglia testo.

Se comunque siamo sicuri di aver configurato correttamente il kernel per l'utilizzo di fbcon (come dovrebbe essere alla fine di questo articolo), nulla vieta di utilizzare l'avvio in modalità grafica inibendo del tutto vgacon. In ogni caso è sempre possibile passare al kernel il parametro "vga=normal" per riottenere la console standard VGA.

Nel caso in cui si desideri utilizzare il driver vesafb (ad esempio perché non è disponibile nessun driver specifico per la nostra scheda) e si desideri altresì avere la modalità grafica impostata fino dal boot process, purtroppo questa rimane l'unica scelta possibile, in quanto vesafb utilizza il parametro "vga" per impostare la propria risoluzione all'avvio e non esistono altri parametri per comunicarglielo.

Configurazione del kernel

Per ottenere un framebuffer device ed una console grafica funzionanti, è innanzitutto necessario che il kernel sia configurato correttamente. Useremo come kernel di riferimento un kernel della serie 2.6.

Innanzitutto, è bene verificare che siano attivate le opzioni generali sui virtual terminal. Le voci interessate si trovano sotto il menù Device Drivers --> Character devices.

--- Virtual terminal
[*]   Support for binding and unbinding console drivers
  • Virtual Terminal abilità il supporto alle Virtual Console descritte precedentemente, ed a meno che non si stia compilando il kernel per un sistema embedded o per un mainframe, è attiva di default.
  • Support for binding and unbinding console drivers è l'opzione che permette di effettuare il takeover del System Driver e che permette di cambiare Modular Driver laddove necessario. Da attivare.

In secondo luogo, è necessario impostare tutte le opzioni relative alla gestione dei vari console driver. Le voci interessate si trovano sotto il menù Device Drivers --> Graphic Support La voce principale è

 <*> Support for frame buffer devices

responsabile dell'attivazione o meno del supporto al frame buffer device. E' importante compilare questa voce in modo statico, in modo che il kernel abbia a disposizione il supporto al frame buffer fino dall'avvio. E anche possibile compilarla come modulo, ma oltre a non avere nessun vantaggio sarebbe necessario modificare l'initrd image, operazione la cui spiegazione esula dallo scopo di questa guida.

Una volta attivata questa voce, si avranno a disposizione numerose opzioni.

  • Enable firmware EDID l'"Extended display identification data" (EDID) è uno standard VESA che serve per permettere ai display di informare la scheda video circa le proprie capacità, in modo da ottenere la giusta risoluzione. E' generalmente una buona idea attivare quest'opzione, alcuni driver senza semplicemente non funzioneranno. Secondo l'help del kernel, l'unico caso in cui vada disattivato è quando si sperimenta un eccessiva lentezza in fase di avvio. La brutta notizia è che, in talune configurazioni hardware (come ad esempio su alcuni laptop), EDID non è supportato a causa della mancanza di un bus I2C che permetta lo scambio dei dati (EDID+I2C = DDC, "Display Data Channel")
  • Enable Video Mode Handling Helpers questa opzione attiva l'utilizzo dello standard VESA GTF (Generalized Timing Formula) per la gestione delle modalità video e delle informazioni fornite da EDID. Anche in questo caso, alcuni driver non possono funzionare senza, è quindi consigliato attivare quest'opzione.
  • Enable Tile Blitting Support quest'opzione abilita il supporto ad una modalità di gestione del frame buffer suddividendolo in "tiles", ossia regioni rettangolari, laddove normalmente è suddiviso in pixel. Quest'opzione va attivata solo ed unicamente se il driver specifico della nostra scheda lo richiede, come nel caso del driver matrox (matroxfb). Altri driver, come quello per schede radeon, semplicemente si rifiuteranno di funzionare se quest'opzione è attivata. Ad esclusione di questi due esempi riportati, è necessario fare dei tentativi per capire se è possibile/necessario utilizzarla o meno.

Sistemate queste opzioni generiche, sarà possibile scegliere quale tipo di driver hardware compilare, a seconda del tipo di scheda video posseduta. Ad esempio, per schede di tipo radeon attiveremo l'opzione

<*>   ATI Radeon display support

Qualsiasi sia il driver prescelto, è necessario compilarlo in modo statico e non come modulo, per gli stessi motivi di cui sopra. Alcuni driver avranno opzioni specifiche. Ad esempio il driver radeonfb dispone delle seguenti opzioni

<*>   ATI Radeon display support     
  [*]     DDC/I2C for ATI Radeon support
  [*]     Support for backlight control
  [ ]     Lots of debug output from Radeon driver

La maggior parte, come si può notare, sono abbastanza ovvie ed è possibile capirle facilmente se si è letta la spiegazione precedente sulle opzioni generali. Nel caso si vogliano informazioni aggiuntive, si può sempre consultare l'help dal menuconfig del kernel.

In taluni casi, purtroppo, non è disponibile un driver per il nostro modello specifico di scheda, oppure addirittura il driver in questione esiste ma non funziona correttamente. In questi casi, è sempre possibile utilizzare il driver standard VESA

[*]   VESA VGA graphics support

che poi altri non è che il driver utilizzato di default nella maggior parte delle distribuzioni di cui abbiamo parlato sopra. Nulla vieta di avere più di un driver compilato staticamente all'interno del nostro kernel. Sarà possibile, in fase di avvio, indicare al kernel che tipo di driver utilizzare (vedi oltre) e come. Nel caso sia compilato più di un driver, il comportamento standard del kernel è di utilizzare il primo driver supportato in ordine di apparizione nel kernel per il framebuffe principale (/dev/fb0), quindi di caricare tutti gli altri driver supportati per i framebuffer secondari (/dev/fb1, etc). Per questo motivo, salvo il passaggio di parametri espliciti, non è possibile determinare in modo esatto quale driver verrà utilizzato per il display primario. Il driver VESA fa eccezione, in quanto se rilevato un driver specifico supportato esso verrà sempre caricato per ultimo.

Una volta selezionate le opzioni relative al supporto per il tipo di frame buffer desiderato, è possibile procedere all'attivazione del supporto per la console in modalità grafica tramite utilizzo del frame buffer. Le opzioni relative si trovano all'interno del menù Device Drivers --> Graphic Support --> Console display driver support

--- VGA text console
[*]   Enable Scrollback Buffer in System RAM
(64)    Scrollback Buffer Size (in KB) (NEW)
[*]   Video mode selection support
<*> Framebuffer Console support
[*] Select compiled-in fonts
[*]   VGA 8x8 font
[*]   VGA 8x16 font
  • VGA text console abilita il supporto alla normale console in risoluzioni VGA. E' consentita un ampiezza di schermo di 80x25 o di 80x50 caratteri. Viene attivata di default nel momento in cui si attiva il supporto ai Terminali Virtuali.
  • Enable Scrollback Buffer in System RAM abilita la possibilità di posizionare il buffer per lo scrollback (la possibilità di visualizzare ciò che è stato stampato su console precedentemente, generalmente tramite la combinazione di tasti SHIFT+PGUP/PGDOWN) nella memoria di sistema invece che nella memoria video. Lo scopo è ottenere una "history" maggiore per lo scrollback, normalmente allocata nella memoria ram della scheda video, la cui dimensione è prefissata ed immodificabile. Attivando quest'opzione, la console rallenterà leggermente. Se non si sente la necessità di scorrere l'history della console direttamente a video, si può tranquillamente lasciare quest'opzione disattivata.
    • Scrollback Buffer Size (in KB) la quantità di memoria in KB da allocare nella memoria di sistema per il buffer di scrollback, generalmente impostato a 64.
  • Video mode selection support quest'opzione attiva la possibilità di selezionare la modalità video da utilizzare fra le varie modalità VESA supportate in fase di avvio del kernel se utilizziamo il driver vesafb nonché fra le modalità VGA standard, tramite il parametro "vga=..." descritto in seguito in questo stesso articolo. Assolutamente da attivare.
  • Framebuffer Console support abilita la possibilità di usare un driver frame buffer per visualizzare la console in modalità grafica (fbcon). Da attivare. Se viene specificato un qualsiasi driver per la modalità framebuffer ma non viene attivata quest'opzione, è molto molto probabile che si ottenga in fase di avvio uno schermo corrotto, invece di una console funzionante.
  • Select compiled-in fonts permette di selezionare font aggiuntivi per la console da compilare in aggiunta a quello standard, fra cui font migliori per la visualizzazione ad alte risoluzioni. Considerato che il nostro scopo è quello di avere una console ad alta risoluzione, attivare quest'opzione.
    • VGA 8x8 font un font aggiuntivo usato dalle alte risoluzioni, utilizzabile dalla modalità 80x50 in su. Attivare.
    • VGA 8x16 font il font standard usato dalle risoluzioni basse ed alte, dalla risoluzione 80x25 in su. Attivare.

A questo punto, tutto ciò che è indispensabile per avere una console in modalità framebuffer è stato configurato.

Su determinati tipi di scheda (bene o male tutte le schede video moderne, tra cui radeon ed nvidia) è possibile che sia richiesta l'attivazione di un altro paio di opzioni del kernel per ottenere il funzionamento dei driver od anche solo delle prestazioni decenti. La prima voce in questione si trova sotto il menù Processor Type and features

<*> MTRR (Memory Type Range Register) support 

assolutamente da compilare in modo statico. Detto in breve, gli MTRR sono registri utilizzati per il controllo della memoria.

La seconda voce in questione si trova sotto File systems --> Pseudo filesystems

<*> Virtual memory file system support

anche questa da compilare in modo statico. Il Virtual Memory File System (tmpfs, una volta chiamato shm), è il cosiddetto "temporary filesystem", indispensabile per fornire l'accesso alla memoria utilizzata dal device driver ad altri utenti oltre a root (uno scenario decisamente sconsigliabile).

L'ultima riguarda il bus I2C, necessario per le interrogazioni EDID qualora siano supportate. La voce principale si trova direttamente sotto Device Drivers

--- I2C support

e viene abilitata di default nel momento in cui si seleziona il supporto al framebuffer. Al suo interno è bene abilitare il supporto alla device interface

<*>   I2C device interface

ai vari algoritmi, sotto I2C Algorithms

--- I2C bit-banging interfaces
<*> I2C PCF 8584 interfaces
<*> I2C PCA 9564 interfaces

ed al driver per l'hardware specifico relativamente al chipset della scheda madre (nell'esempio un nForce3), sotto I2C Hardware Bus support

<*> Nvidia nForce2, nForce3 and nForce4

Opzioni aggiuntive di vgacon

E' possibile, modificando un file nei sorgenti del kernel prima della compilazione, attivare opzioni specifiche di vgacon altrimenti disattivate per default, in quanto non sempre stabili o necessarie.

Il file in questione è il file arch/i386/boot/video.S, le opzioni sono le seguenti:

  • CONFIG_VIDEO_SVGA - abilita l'autodetect dei vari chipset SVGA. Disattivato di default poiché inaffidabile.
  • CONFIG_VIDEO_LOCAL - abilita l'inclusione dei "local modes" nel menù "ask" del parametro "vga" (vedi oltre). I local modes vengo attinti dallo stesso file nella parte successiva alla riga "local_mode_table:". Nel file è presente un commento che descrive il formato della tabella.
  • CONFIG_VIDEO_400_HACK - forza il settaggio di 400 scanlines per le modalità standard VGA. Questo settaggio è stato incluso per permettere ai possessori di alcuni BIOS buggati di resettare la scheda video per eliminare la spazzatura derivante dalla visualizzazione dei logo pre-boot.
  • CONFIG_VIDEO_GFX_HACK - include alcuni hack speciali per settare delle modalità video usati da alcuni driver speciali (es.: 800x600 su Thinkpad IBM). Permette di settare qualsiasi modalità video e di forzare la risoluzione dei testi invece di recuperarla dal BIOS. Per utilizzare questa funzione, è necessario usare il valore 0x0f08 per il parametro "vga" (vedi oltre).

Ad esempio, per attivare la rilevazione automatica del chipset e delle modalità SVGA, sarà sufficiente cambiare la riga

#undef CONFIG_VIDEO_SVGA

in

#define CONFIG_VIDEO_SVGA

Configurazione di lilo

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"

All'avvio sarà possibile quindi selezionare una qualsiasi voce del menù e, a tergo, scrivere i parametri da usare. Supponiamo ad esempio di voler usare il parametro vga=normal e di avere una voce in menù chiamata linux-2.6.23. Scriveremo

linux-2.6.23 vga=normal
NB: nel caso in cui si usi lilo in modalità grafica, è possibile premere il tasto di tabulazione
per avere accesso al prompt di lilo ed immettere i parametri

Ad un certo punto, decideremo di voler utilizzare in modo automatico i parametri scelti per l'avvio della modalità desiderata. A questo scopo è sufficiente aggiungere un paio di rige a lilo.conf. Per il parametro "vga" useremo la riga:

vga=modalità

per il parametro "video" useremo la riga:

append="video=..."

Quindi, il file lilo.conf potrebbe apparire nel seguente modo:

# LILO configuration file

# Start LILO global section
lba32 # Allow booting past 1024th cylinder with a recent BIOS
boot = /dev/hda
prompt
timeout = 50

vga = 791 # VESA framebuffer console @ 1024x768x64k
append = "video=radeonfb:off" # disabilita il supporto al driver radeonfb, se compilato nel kernel
[...]

Per una spiegazione sul funzionamento di questi due parametri, leggere oltre.

NB: è bene ricordarsi che è indispensabile eseguire il comando lilo privo di parametri 
dopo ogni modifica al file lilo.conf, per far si che le modifiche siano effettive.

Parametri per la selezione della modalità

Una volta compilato ed installato il kernel, al successivo riavvio il kernel potrebbe tentare autonomamente d'utilizzare una modalità grafica per la console secondo lo schema descritto nella sezione "Nozioni Basilari". E' possibile alterare la rilevazione della modalità video con una serie di parametri, che ora andremo a descrivere nel dettaglio.

Il primo parametro è presente dentro il kernel stesso, compilato staticamente al suo interno, e viene usato solo in assenza del parametro "vga". Se si vuole alterare il parametro di default presente nel kernel si può usare il comando rdev, od il suo wrapper vidmode, scelta che comunque sconsiglio caldamente salvo necessità particolari.

Il secondo parametro è "vga". Passato dal bootloader, esso permette di determinare che tipo di risoluzione dev'essere utilizzata per i driver vesafb e vgacon. Impostandolo per una risoluzione VGA (normal od extended in genere), permette di inibire il caricamento del driver vesafb, se presente. Non esiste altro modo per bloccare il caricamento di vesafb. Se vga verrà impostato per una modalità grafica superiore a VGA, verrà utilizzato per settare la risoluzione di vesafb se presente ed inibirà automaticamente il caricamento di vgacon in favore di dummycon.

Il terzo parametro è "video", il quale passato dal bootloader permette di impostare tutti i driver di fbdev, incluso quello vesa (con l'eccezione della risoluzione), nonché di disattivarli se è il caso. E' possibile passare più di un parametro video, uno per ogni driver che si desidera impostare.

Per forzare il caricamento di un driver piuttosto che di un altro, è possibile utilizzare una combinazione dei parametri vga e video.

Il parametro "vga" nel dettaglio

Come spiegato precedentemente, il parametro vga permette di determinare la risoluzione che dovranno utilizzare vgacon e vesafb. Il parametro vga accetta i seguenti valori:

  • normal avvia la console in modalità VGA 80x25. E' la modalità standard
  • extended avvia la console in modalità VGA 80x50
  • ask visualizza un menù dal quale è possibile selezionare una modalità fra quelle rilevate (vedi oltre)
  • NUMERO un codice numerico rappresentante una modalità valida

Nel caso in un qualsiasi modo tramite "vga" venga selezionata una modalità superiore a quelle VGA, come spiegato precedentemente vgacon non verrà caricato. E' quindi indispensabile avere il supporto ad fbcon con un driver specifico compilato nel kernel, o tutto ciò che otterremo sarà una console muta. Inoltre, nel caso in cui venga selezionato un valore rappresentante una modalità superiore a VGA e si è compilato il driver vesafb per il framebuffer, il parametro vga verrà utilizzato per determinare la modalità grafica di vesafb.

Nel caso si usi l'opzione "ask", il kernel visualizzerà un menù da cui sarà possibile scegliere una modalità video. Per esser precisi, visualizzerà inizialmente un messaggio che ci chiederà se veramente vogliamo visualizzare il menù o se vogliamo proseguire. Se premiamo "spazio" o aspettiamo 30 secondi, il kernel procederà al normale avvio, se premiamo "invio" invece visualizzerà il menù. Il menù apparirà in questo modo:

Video adapter: <nome del dispositivo rilevato>
Mode:    COLSxROWS:
0  0F00  80x25
1  0F01  80x50
2  0F02  80x43
3  0F03  80x26
....
Enter mode number or `scan':

Come si può vedere, fra le altre cose Linux visualizzerà il nome dell'adattatore video che ha rilevato. Questo nome può essere tanto generico (VGA, VESA VGA) quanto specifico di un chipset SVGA (Trident, etc). Il chipset specifico non verrà rilevato di default a meno che non si modifichi manualmente il kernel in fase di compilazione (vedi sezione relativa al Kernel), per cui il più delle volte si vedrà un laconico "VESA VGA" (un adattatore VGA compatibile VESA).

Il primo valore è il numero progressivo della modalità all'interno del menù (è possibile usarlo per selezionare la modalità video), il secondo valore è l'ID della modalità video in esadecimale (è il valore che è possibile passare tramite "vga" per selezionare quella precisa modalità in fase di avvio), il terzo valore rappresenta il numero di caratteri per riga e per colonna che verranno visualizzati in ognuna modalità.

I modi visualizzati saranno parzialmente ordinati: innanzitutto verranno visualizzate le due modalità VGA standard corrispondenti ai valori "normal" ed "extended" di vga, per poi proseguire con qualche modalità speciale (sempre fra le modalità VGA), le modalità locali (un altra opzione da attivare in fase di compilazione del kernel), le modalità VESA rilevate e le modalità SVGA specifiche, queste ultime nel caso sia stato attivato l'auto rilevamento del chipset.

La lista visualizzata sarà però abbastanza incompleta. E' possibile immettere il valore "scan" invece del numero progressivo della modalità video per ottenere un elenco più nutrito. Se si immetterà come valore "scan", lo schermo inizierà a lampeggiare selvaggiamente, poiché Linux tenterà di rilevare tutte le modalità VESA supportate con interrogazioni BIOS. Una volta finiti i test, verrà riproposto lo stesso menù ma leggermente cambiato: le modalità SVGA se presenti non saranno più mostrate e tutte le modalità rilevate da "scan" saranno poste prima delle modalità VESA presentate precedentemente.

Nel caso si desideri passare a "vga" direttamente l'id numerico (vengono accettati anche valori decimali, non solo esadecimali) della modalità desiderata (come quelli visualizzati dal menù di "ask"), è bene conoscerne il formato (soprattutto considerato che rappresenta la scelta più comune).

I vari ID che è possibile assegnare sono divisibili in 3 categorie principali:

  • 0x0000 - 0x00ff : le modalità del menù "ask" in base all'ordine progressivo. Non è consigliabile usarle al di fuori del menù stesso in quanto potrebbero cambiare da boot a boot.
  • 0x0100 - 0x017f : le modalità BIOS standard. Corrispondono alla tabella delle modalità BIOS incrementate tutte di 0x0100 (vedi sotto)
  • 0x0200 - 0x08ff : le modalità VESA BIOS standard. Corrispondono alla tabella delle modalità VESA BIOS incrementate tutte di 0x0200 (vedi sotto)
  • 0x0900 - 0x09ff : le modalità Video7 BIOS (uno standard per alcune modalità proprietarie)
  • 0x0f00 - 0x0fff : modalità speciali varie, tra cui le più importanti sono
    • 0x0f00 : standard 80x25, non resetta la modalità se è precedentemente settata (=FFFF)
    • 0x0f01 : standard con font di 8 pixel (80x50 su VGA)
    • 0x0f04 : conserva la modalità corrente
  • 0x1000 - 0x7fff : modalità impostate in base alla risoluzione. In pratica, si tratta di un codice composto dalla traduzione esadecimale della risoluzione orizzontale e di quella verticale in caratteri, secondo lo schema: 0xVVHH (V sta per verticale ed H per orizzontale). Ad esempio, supponendo di voler rappresentare in questo modo la risoluzione 132x43, considerato che in esadecimale 132 vale 0x84 e che 43 vale 0x2B, il codice sarà 0x2B84. Di fatto, questo è l'unico modo per rappresentare in modo univoco risoluzioni non standard.
  • 0xff00 - 0xffff : alias per conservare la retro compatibilità. Nella fattispecie:
    • 0xffff : alias di 0x0f00 (standard 80x25)
    • 0xfffe : alias di 0x0f01 (VGA 80x50)

Nel caso si voglia selezionare come modalità video una modalità BIOS standard, si possono tranquillamente utilizzare le opzioni di default, oppure utilizzare la seguente tabella, già corretta con l'aggiunta di 0x0100:

Modalità standard BIOS su Linux
ID Risoluzione
0x0100 text 40*25 16 color (mono)
0x0101 text 40*25 16 color
0x0102 text 80*25 16 color (mono)
0x0103 text 80*25 16 color
0x0104 CGA 320*200 4 color
0x0105 CGA 320*200 4 color (m)
0x0106 CGA 640*200 2 color
0x0107 MDA monochrome text 80*25
0x010D EGA 320*200 16 color
0x010E EGA 640*200 16 color
0x010F EGA 640*350 mono
0x0110 EGA 640*350 16 color
0x0111 VGA 640*480 16 color
0x0112 VGA 640*480 16 color
0x0113 VGA 320*200 256 color

Personalmente ritengo che difficilmente si dovrà scegliere una modalità basandosi su questa tabella. Più probabile è invece che si desideri selezionare una modalità basandosi sulla tabella delle modalità VESA BIOS supportate. A tal scopo, è possibile consultare la seguente tabella, già corretta con l'aggiunta di 0x0200:

Modalità standard VESA su Linux
320×200 640×400 640×480 800×500 800×600 896×672 1024×640 1024×768 1152×720 1280×1024 1440×900 1600×1200
16 color palette 0x0302 0x0304 0x0306
256 color palette 0x0300 0x0301 0x036F 0x0303 0x032F 0x036A 0x0305 0x0365 0x0307 0x0360 0x031C
15-bit (5:5:5) 0x030D 0x0321 0x0310 0x0370 0x0313 0x0330 0x036B 0x0316 0x0366 0x0319 0x0361 0x031D
16-bit (5:6:5) 0x030E 0x0322 0x0311 0x0371 0x0314 0x0331 0x036C 0x0317 0x0367 0x031A 0x0362 0x031E
24-bit (8:8:8) 0x030F 0x0323 0x0312 0x0372 0x0315 0x0332 0x036D 0x0318 0x0368 0x031B 0x0363 0x031F
32-bit (8:8:8) 0x0324 0x0329 0x0373 0x032E 0x0333 0x036E 0x0338 0x0369 0x033D 0x0364 0x0342

E' bene ricordare che per poter utilizzare modalità VESA superiori a VGA, è necessario avere compilato fbdev con il giusto driver ed fbcon. Inoltre, è bene ricordare nuovamente che si potrà settare una risoluzione VESA con "vga" solo ed unicamente utilizzando il driver vesafb. Esistono altri modi per la rilevazione delle modalità video VESA BIOS supportate, verranno presi in esame in seguito.

Difficilmente la configurazione del framebuffer va oltre la selezione della modalità VESA più adatta nella maggior parte delle distribuzioni odierne, in quanto comunemente viene usato il driver vesafb di default per avere una maggiore compatibilità. Per ottenere il meglio, comunque, è necessario andare un po' oltre, cercando di scoprire quali risoluzioni specifiche la nostra scheda video supporta.

Rilevamento delle modalità vesa supportate

Esistono una quantità di tool per rilevare le modalità vesa supportate e le loro caratteristiche. Alcuni funzionano meglio, altri peggio, alcuni s'installano facilmente, altri richiedono un po' di lavoro. Ne esamineremo due. E' possibile che comunque non si riesca a rilevare tutte le risoluzioni disponibili per la nostra scheda video. In tal caso è necessario armarsi di pazienza e fare alcuni tentativi.

Rilevamento tramite vbetest

Il modo più semplice è utilizzare l'utility vbetest, inclusa nel package lrmi, reperibile presso il sito del progetto su SourceForge. E' sufficiente scompattare il pacchetto in una qualsiasi directory e compilarlo, senza installarlo all'interno del sistema (ho avuto un messaggio di errore tentando di farlo e guardando sul forum del progetto sembra che non sia stato l'unico).

tar -zxvf lrmi-0.10.tar.gz
cd lrmi-0.10
make
./vbetest

Il comando interrogherà il bios della scheda video per ottenere una lista delle risoluzioni supportate, producendo un output simile al seguente:

VBE Version 2.0
ATI MOBILITY RADEON 9600
[...]
[259] 800x600 (256 color palette)
[275] 800x600 (5:5:5)
[276] 800x600 (5:6:5)
[277] 800x600 (8:8:8)
[290] 800x600 (8:8:8)
[261] 1024x768 (256 color palette)
[278] 1024x768 (5:5:5)
[279] 1024x768 (5:6:5)
[280] 1024x768 (8:8:8)
[291] 1024x768 (8:8:8)
[263] 1280x1024 (256 color palette)
[281] 1280x1024 (5:5:5)
[282] 1280x1024 (5:6:5)
[283] 1280x1024 (8:8:8)
[292] 1280x1024 (8:8:8)
[...]

A questo punto, una volta individuato il modo desiderato, sarà possibile utilizzarlo per l'opzione vga di lilo.conf, avendo l'accortezza di sommargli 512. Il motivo per cui questo va fatto è che il valore riportato da vbetest è decimale, non esadecimale. 512 corrisponde all'esadecimale 0x200 e come detto sopra per avere l'ID della modalità in formato Linux corrispondente all'id della modalità VESA, è necessario sommargli 0x200. Per cui, ad esempio, volendo usare la risoluzione 1280x1024 a 16 bit, dobbiamo sommare a 282 il valore 512, ottenendo 794. Pertanto, useremo la stringa:

vga=794 

Non è necessario convertire il valore decimale in esadecimale, lilo ed il kernel li accettano entrambi.

Rilevamento tramite hwinfo

Il comando hwinfo fa parte di un package che ha visto i suoi natali su Suse, portata poi su Open Suse. Si tratta di un tool che interroga l'hardware e crea un database abbastanza dettagliato, al punto che è la base per il rilevamento hardware di Yast, il noto tool di Suse. Il problema per ottenere hwinfo su Slackware è che bisogna necessariamente prelevare il pacchetto o dal repository di Suse o dal repository di un altra distribuzione, non esiste un sito principale da cui scaricare i sorgenti. Inoltre, hwinfo fa riferimento ad alcune estensioni del kernel modificato di Suse. Il modo migliore per ottenere hwinfo su Slackware, da quel che ho potuto verificare, è scaricare i sorgenti dal sito Debian, inclusa la patch. Questi sono i link diretti alla versione corrente (alla stesura di questo articolo):

http://ftp.de.debian.org/debian/pool/main/h/hwinfo/hwinfo_13.41.orig.tar.gz

http://ftp.de.debian.org/debian/pool/main/h/hwinfo/hwinfo_13.41-1.diff.gz

quindi procedere all'estrazione/patchamento/compilazione

tar -zxvf hwinfo_13.41.orig.tar.gz
gunzip hwinfo_13.41-1.diff.gz
patch -p0 < hwinfo_13.41-1.diff
cd hwinfo-13.41
cat debian/patches/* | patch -p0
make
make install

L'operazione richiederà molto tempo, poiché durante la compilazione verrà anche costruito il database con le specifiche dell'hardware. Una volta completato il tutto, sarà possibile ottenere le specifiche della scheda video digitando il comando:

hwinfo --vbe

L'output sarà il seguente:

[...]
 Mode 0x0301: 640x480 (+640), 8 bits
 Mode 0x0310: 640x480 (+1280), 15 bits
 Mode 0x0311: 640x480 (+1280), 16 bits
 Mode 0x0312: 640x480 (+1920), 24 bits
 Mode 0x0321: 640x480 (+2560), 24 bits
 Mode 0x0303: 800x600 (+800), 8 bits
 Mode 0x0313: 800x600 (+1600), 15 bits
 Mode 0x0314: 800x600 (+1600), 16 bits
 Mode 0x0315: 800x600 (+2400), 24 bits
 Mode 0x0322: 800x600 (+3200), 24 bits
 Mode 0x0305: 1024x768 (+1024), 8 bits
 Mode 0x0316: 1024x768 (+2048), 15 bits
 Mode 0x0317: 1024x768 (+2048), 16 bits
 Mode 0x0318: 1024x768 (+3072), 24 bits
 Mode 0x0323: 1024x768 (+4096), 24 bits
[...]

A questo punto, una volta individuato il modo desiderato, sarà possibile utilizzarlo per l'opzione "vga" come già visto. Non è necessario addizionare alcunché al valore restituito da hwinfo, in quanto è già in formato linux.

Il parametro "video" nel dettaglio

Come descritto precedentemente, nel caso in cui sia stato compilato il supporto al framebuffer device e ad fbcon all'interno del kernel, all'avvio Linux caricherà tutti i framebuffer device disponibili assegnando loro un numero progressivo (/dev/fb0, /dev/fb1, etc, oppure /dev/fb/0, /dev/fb/1, etc). Quindi, procederà ad effettuare il takeover della console sul System Driver usando fbcon con il framebuffer device 0. E' bene ricordarsi che i driver saranno caricati nell'ordine di comparizione nel kernel, con l'eccezione di vesafb che verrà sempre caricato per ultimo in presenza di driver specifici utilizzabili.

Tramite il parametro video è possibile passare parametri specifici ad ogni driver di fbdev, tra cui per importanza spicca la possibilità d'inibirne del tutto il caricamento. Il formato del parametro è il seguente:

video=driver:[risoluzione],parametro[=valore],parametro[=valore],...

Il tipo di parametri ed i valori che essi possono assumere dipendono dal driver specifico, ognuno ha i suoi. La sintassi più comune per il parametro "risoluzione" è la seguente:

[resx]x[resy]-[bpp]@[freq]

Con l'eccezione di vesafb, tutti i driver supportano il parametro "off" e molti supportano il parametro "risoluzione" (vesafb usa "vga", come descritto precedentemente), per cui se vogliamo ad esempio inibire il caricamento di radeonfb (nel caso l'abbiamo compilato) sarà sufficiente usare la stringa:

video=radeonfb:off

oppure, facendo un esempio più complesso, volendo dire a radeonfb di usare una risoluzione di 1280x800 a 32 bit a 60hz, di disattivare l'uso dei MTRR e di usare una dimensione fissa verticale di 800 pixel per il monitor LCD, scriveremo:

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

Sempre seguendo l'esempio, supponendo di voler disabilitare il driver radeonfb in favore di vesafb e di voler disabilitare su vesafb l'uso degli mtrr, scriveremo:

video=radeonfb:off video=vesafb:nomtrr

Un analisi più approfondita delle opzioni di video è impossibile, in quanto come detto dipendono dal driver specifico che si sta tentando d'usare. vesafb ha le sue così come radeonfb ha le sue, e via dicendo. Per avere un elenco completo delle varie opzioni disponibili, è possibile consultare la directory "Documentation/fb" all'interno dei sorgenti del kernel.

Modalità d'utilizzo della console

Una volta che si è capito come utilizzare i due parametri che ci permettono di selezionare le modalità video, è ora possibile decidere come avviare la propria console.

Modalità VGA tramite vgacon

Come detto precedentemente, vgacon è il System Driver predefinito. In un sistema privo di supporto alla console framebuffer verrà semplicemente utilizzato di default. Nel caso in cui invece un supporto alla console framebuffer sia presente, per poter caricare esplicitamente la console in modalità VGA tramite vgacon è possibile passare al kernel il parametro

vga=normal

il quale provvederà anche a disattivare il caricamento di vesafb, se presente. Se inoltre sono presenti altri driver di fbdev oltre a vesafb, sarà necessario passare i parametri "video" necessari a disattivarli. Ad esempio, in presenza anche di radeonfb:

vga=normal video=radeonfb:off

Modalità VESA framebuffer tramite fbcon e vesafb

Nel caso sia stata attivato il driver standard VESA (vesafb), sarà necessario specificare un valore corrispondente ad una modalità vesa valida all'interno del parametro vga.

Ad esempio, per avviare la console in modalità framebuffer con vesafb ad una risoluzione di 1024x768 a 16 colori, consultando la tabella di cui al precedente capitolo, sarà sufficiente scrivere:

vga=0x0317

Nel caso in cui siano presenti nel kernel altri driver specifici oltre a vesafb, considerato che come detto vesafb viene caricato sempre per ultimo se vengono rilevati altri driver utilizzabili, è necessario ancora una volta inibirli con l'utilizzo del parametro video. Pertanto, continuando sull'esempio di radeonfb, per disattivare il driver specifico ed usare la console in modalità framebuffer con vesafb alla risoluzione voluta, dovremo scrivere:

vga=0x0317 video=radeonfb:off

Ovviamente al contempo è possibile settare altre opzioni di vesafb, ad esempio:

vga=0x0317 video=radeonfb:off video=vesafb:nomtrr

E' bene chiarire che con vesafb sarà possibile utilizzare solo le modalità standard VESA nella stragrande maggioranza dei casi. Esiste una possibilità molto remota che tramite l'interrogazione VBE/EDID il driver riesca ad ottenere informazioni sulle risoluzioni aggiuntive supportate, ma è veramente ma veramente remota. Per supportare modalità VESA non standard (normalmente raggruppate sotto il termine SVGA, per quanto improprio), sarà necessario utilizzare nella stragrande maggioranza dei casi il driver specifico.

Modalità SVGA framebuffer tramite fbcon ed il driver hardware specifico

Nel caso si decida di compilare (staticamente, come spiegato precedentemente) un driver hardware specifico per avere accesso a tutte le feature e le modalità specifiche della nostra scheda, come già detto il kernel tenterà di utilizzarlo automaticamente, salvo differenti indicazioni, per cui non è necessario immettere nessun parametro, semplicemente fbcon prenderà il sopravvento su vgacon.

Nel caso in cui sia stato compilato staticamente più di un driver hardware specifico, per assicurarsi che nessun'altro driver di fbcon venga utilizzato al posto di quello desiderato, è bene utilizzare il parametro video per disattivare gli altri driver. Ad esempio, supponendo di avere compilato sullo stesso kernel il supporto a schede radeon ed a schede nvidia, per quanto possa essere improbabile che vengano caricati entrambi, è possibile sincerarsene usando la stringa:

video=nvidiafb:off

per inibire ad esempio il caricamento del driver nvidiafb. Per cui il kernel tenterà ovviamente di utilizzare l'unico driver restante, ossia secondo il nostro esempio radeonfb. Nel caso in cui si sia compilato anche il driver vesafb e si voglia esser sicuri che non sia caricato, è possibile modificare la stringa nel seguente modo:

vga=normal video=nvidiafb:off

anche se comunque, come già detto, il driver vesafb viene caricato per ultimo nel caso in cui ci sia un driver specifico utilizzabile.

Considerato tutto, se si ha l'accortezza di compilare solo il supporto relativo alla propria scheda video con in aggiunta forse solo vesafb (ma magari nemmeno quello), è molto probabile che non sia necessario usare proprio nessun parametro d'avvio. Il kernel semplicemente tenterà di usare l'unico driver disponibile, o comunque quello che riterrà più corretto.

Per settare la risoluzione, il kernel interrogherà la scheda video tramide VBE/EDID o BIOS, a seconda delle opzioni presente nel kernel, operazioni che non sempre possono aver successo. Per cui, una volta riavviato il computer con il nuovo kernel, potremmo arrivare a sperimentare veri e propri blocchi del sistema nel caso in cui il driver specifico non riesca a gestire la nostra scheda.

Niente panico, nel caso succeda è possibile forzare il kernel a non usare il driver in questione, ripiegando su vgacon, specificando a mano in fase di avvio il parametro

vga=normal video=DRIVER:off

come già visto precedentemente, aggiungendolo alla fine della stringa del kernel da caricare. Se invece la console si avvia normalmente con il driver prescelto, 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 (vedere la sezione su lilo in merito).

Come già visto precedentemente, Per impostare opzioni e risoluzione con driver differenti da vesafb e vgacon è possibile utilizzare il parametro "video", il quale permette nella maggior parte dei casi di settare risoluzione ed opzioni varie a seconda del tipo di supporto fornito dal driver in uso. La sintassi più comune è, ripetiamolo:

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

E' bene tenere presente che non tutti i driver supportano questa sintassi e non tutti i driver supportano le stesse opzioni. Per avere un elenco delle opzioni supportate ricordo che è possibile guardare il file specifico nella directory Documentation/fb/ all'interno dei sorgenti del kernel. Ad esempio, supponendo di voler utilizzare la modalità 1280x800 a 23bit a 60hz con il driver radeon, sarà sufficiente passare a lilo il parametro:

video=radeonfb:1280x800-32@60

Com'è ovvio, questa sintassi è molto più potente della forma "vga=..." (che comunque è supportata solo da vesafb e vgacon), poiché ci permette di accedere direttamente alle caratteristiche del driver della nostra scheda video specifica, tra l'altro in un formato decisamente più umano. Inoltre ci permette di settare il refresh video in modo semplice e diretto. 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.

NB: per quanto sia necessario usare il parametro "video" per impostare la risoluzione di un driver specifico, è bene ricordarsi che è possibile comunque passare il parametro "vga=NUMERO" con una modalità superiore a VGA per inibire il caricamento di vgacon. Allo stesso tempo, è bene ricordarsi che se si usa questa forma ed è stato compilato il driver vesafb in aggiunta al driver specifico, esso verrà automaticamente caricato ed impostato secondo il parametro vga, anche se per un framebuffer device secondario.

Una volta trovata la modalità desiderata, è possibile forzare il settaggio automatico della risoluzione all'avvio modificando il file lilo.conf come spiegato nell'apposita sezione.

Purtroppo però, spesso i vari driver specifici non supportano correttamente ogni tipo di scheda/risoluzione in fase di avvio (c'era da dubitarne?) per cui non è possibile settare la risoluzione ottimale 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, che verranno analizzati in seguito in questo stesso articolo.

Supporto VESA tramite uvesafb

Come si sarà potuto notare leggendo questo articolo fin'ora, il driver vesafb presenta numerose mancanze, la più grande delle quali è forse l'impossibilità di utilizzarlo senza inibire vgacon, dato che entrambi utilizzano il parametro "vga".

Se si desidera utilizzare un driver vesa migliore, nel caso in cui non esista un driver specifico per la nostra scheda video, è possibile fortunatamente utilizzare "uvesafb", un driver VESA prodotto da uno sviluppatore indipendente, reperibile sul sito di spock, uno sviluppatore di Gentoo.

NB: dalla serie 2.6.24 il supporto è stato incluso nel kernel vanilla. Pertanto non sarà necessario applicare patch.

Le caratteristiche principali di uvesafb, vantaggiose rispetto a vesafb, sono:

  • la possibilità di utilizzarlo come Modular Driver conservando il caricamento di vgacon come System Driver, dato che uvesafb non usa il parametro "vga"
  • il supporto allo standard VBE 3.0, con tutto quel che ne consegue, tra cui la possibilità di settare il refresh video in fase d'avvio (operazione impossibile con vesafb)
  • il supporto del parametro "video", tramite il quale è possibile settare la risoluzione in modo più intuitivo ed "umano".

Gli svantaggi di uvesafb sono:

  • la necessità di patchare il kernel per una serie precedente alla 2.6.24
  • qualche incompatibilità con alcune schede. E' possibile che vesafb supporti un maggior numero di chipset, per quanto meno evoluto.

A differenza di vesafb, uvesafb usa un programma userspace allo scopo di settare la risoluzione correttamente. Per questo non sarà sufficiente patchare il kernel, bisognerà compilare ed installare anche un helper userspace, chiamato v86d.

Prerequisiti all'installazione

Per poter installare correttamente uvesafb, come abbiamo detto sarà necessario compilare un helper userspace, v86d. A questo scopo è innanzitutto necessario avere installato sulla propria distro il package klibc, allo scopo di ottenere il compilatore klcc. Dato che klcc usa gli header del kernel, il primo passo è patchare il kernel.

Patchare il Kernel

NB: Se si possiede un kernel della serie 2.6.24, il supporto è incluso di default, pertanto non è necessario patchare.

Allo scopo di attivare il supporto ad uvesafb, è necessario applicare al kernel la giusta patch, scaricandola sempre dal sito di spock. E' importante usare l'ultima patch disponibile, anche se non corrisponde alla nostra versione del kernel. Quindi, innanzitutto ci posizioneremo all'interno dei sorgenti del kernel:

cd /usr/src/linux

quindi procederemo a scaricare la patch

wget http://dev.gentoo.org/~spock/projects/uvesafb/archive/uvesafb-0.1-rc3-2.6.23-rc3.patch

infine, applicheremo la patch

patch -p1 < uvesafb-0.1-rc3-2.6.23-rc3.patch

A questo punto, digitando il solito "make menuconfig", sotto la sezione "Device Drivers → Graphic Support", proprio sopra al vecchio "VESA VGA graphics support", avremo anche il nuovo:

<*>   Userspace VESA VGA graphics support

Alla domanda "che si fa con il vecchio driver VESA quando uvesafb è attivo", la risposta è "dipende". In teoria è inutile conservare il supporto al vecchio vesafb, usando uvesafb. In pratica, se lo si desidera, è possibile lasciarlo attivato usando la sintassi che è stata descritta nei paragrafi precedenti per impostarlo, tramite il parametro "vga".

Una volta attivato (anche in questo caso, come sempre fino ad ora, incluso direttamente e non come modulo) possiamo procedere a compilare e reinstallare il kernel. Prima di effettuare l'operazione comunque, è bene assicurarci che sia attivo anche il supporto a "Connector", una componente del kernel che permette di dividere i driver in due parti, una parte "kernel space" ed una parte "user space". Lo troviamo sotto "Device Driver → Connector - unified userspace <-> kernelspace linker"

--- Connector - unified userspace <-> kernelspace linker
[*]   Report process events to userspace

La prima voce abilita il supporto a Connector e viene selezionata di default nel momento in cui si abilita uvesafb. La seconda voce permette di abilitare il supporto a Connector per la notifica degli eventi relativi ai processi nello userspace.

Una volta compilato tutto e riavviato il sistema, per quanto uvesafb ancora non funzioni per via della mancanza di v86d, sarà possibile procedere alla compilazione delle klibc.

Installazione delle klibc

E' possibile ottenere klcc dal sito ufficiale del kernel Linux. La compilazione e l'installazione richiedono pochi semplici passaggi. Supponendo quindi di voler installare klibc versione 1.5 (l'ultima disponibile alla scrittura di questa guida), procederemo nel seguente modo:

wget http://www.kernel.org/pub/linux/libs/klibc/klibc-1.5.tar.bz2

Ottenuto il package, procediamo a scompattarlo:

tar -jxvf klibc-1.5.tar.bz2

Per procedere alla compilazione, è necessario creare un symlink alla cartella dei sorgenti del kernel nella directory principale. Se si è proceduto alla ricompilazione del kernel come descritto in questa guida non si dovrebbero avere problemi in merito.

cd klibc-1.5
ln -s /usr/src/linux linux

A questo punto è sufficiente lanciare la solita procedura di make/make install

make
make install

per sicurezza eseguire ldconfig

ldconfig

quindi verificare il successo dell'operazione

klcc --version

Installazione di v86d

Come detto precedentemente, v86d è l'helper userspace di uvesafb. Senza non sarà possibile utilizzare il driver.

E' possibile reperire v86d sempre sul sito di spock. La compilazione sarà pressoché identica al solito:

wget http://dev.gentoo.org/~spock/projects/uvesafb/archive/v86d-0.1.2.tar.bz2
tar -jxvf v86d-0.1.2.tar.bz2
cd v86d-0.1.2
./configure --with-klibc
make
make install

A questo punto, se il kernel è stato compilato ed installato nel modo corretto, è possibile procedere ad utilizzare uvesafb immediatamente, riavviando il sistema. Un unico appunto va fatto per gli utilizzatori dell'initrd image.

Aggiornamento dell'initrd

Se si sta utilizzando un initrd image, è necessario includere all'interno dell'immagine l'eseguibile di v86d. Per scoprire se si sta usando un initrd image, nel caso non lo si sapesse, è sufficiente analizzare il contenuto del file /etc/lilo.conf. Se contiene una riga del tipo

[...]
image = /boot/vmlinuz-2.6.22.10
 initrd = /boot/initrd.gz
 root = /dev/myvg/mylv
[...]

allora si sta utilizzando un immagine initrd, ed è quindi necessario compiere qualche step aggiuntivo.

Innanzitutto è necessario copiare l'eseguibile di v86d dentro il tree dell'initrd. Su slackware il path di default è /boot/initrd-tree, per cui:

cp -p /sbin/v86d /boot/initrd-tree/sbin/

quindi è necessario aggiornare l'immagine, su Slackware eseguendo il tool mkinitrd privo di parametri:

mkinitrd

infine, è necessario aggiornare lilo. Sarà quindi possibile eseguire il riavvio.

Modalità VESA framebuffer tramite fbcon ed uvesafb

Se si è svolto tutto correttamente, al riavvio sarà disponibile questo nuovo driver. La procedura di configurazione è la stessa che abbiamo visto per i driver proprietari, per cui, supponendo di voler settare una risoluzione specifica all'avvio di 1024x760 a 32 bit a 60hz, possiamo usare il parametro:

video=uvesafb:1024x768-32@60

Anche in questo caso, se è stato compilato più di un driver oltre ad uvesafb è possibile disattivarlo con opzioni video multiple, ad esempio supponendo diaver compilato anche il driver radeonfb:

video=uvesafb:1024x768-32@60 video=radeonfb:off

e via dicendo. Come tutti gli altri driver proprietari e non, uvesafb supporta una nutrita serie di opzioni. E' possibile trovarle nella directory Documentation/fb del kernel (quando si patcha il kernel viene creato un nuovo file, "uvesafb.txt")

Personalizzazione manuale della risoluzione tramite fbset e fb.modes

Indipendendtemente dal fatto che si utilizzi il driver generico VESA o un driver hardware specifico, è probabile che si possa desiderare di personalizzare maggiormente la configurazione. A questo scopo è possibile utilizzare fbset.

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 esempio 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 i modelli principali di scheda. Nel caso esista un file per il nostro modello, procediamo quindi a sostituirlo a quello standard. Quindi, ad esempio, per una scheda ATI Radeon:

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, i vari file presenti dentro /usr/share/doc/fbset-versione non sono completi, 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 i parametri della modalità corrente 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, accel e rgba). 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.

Personalizzazione di fb.modes tramite modetest

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 abbastanza 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).

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, è sufficiente usare nuovamente fbset per visualizzare la modeline reale impostata da modetest, per poi aggiungerla al file fb.modes come spiegato nel paragrafo precedente.

Per quanto riguarda le prove con gli altri parametri di modetest, consiglio caldamente di seguire le istruzioni sul sito di fbmodes nella sezione 5 (Online Demo).

La seconda riga di nostro interesse, "XF86Config modeline", 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, come spiegato nella prossima sezione.

Configurazione del server X

Una volta ottenuta una console grafica in modalità frame buffer funzionante, è possibile procedere alla configurazione del server X.

Se si sono seguite con precisione le sezioni precedenti, a questo punto dovremmo avere a disposizione dentro il file /etc/fb.modes delle modeline corrette e corrispondenti alla risoluzione attualmente in uso sulla console. L'operazione che adesso dovremo fare è convertire queste modeline nel formato di X.

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 di modeline specifiche per la nostra combinazione monitor/scheda e si desideri personalizzarle all'interno di X.

Per inserire la modeline nel file xorg.conf, utilizzare 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). La funzione di questo script è convertire le modeline nel formato di X

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

quindi inserire nella sezione Monitor la riga relativa alla modeline desiderata prodotta da fb2x.rb, 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

Per rendere effettive le modifiche, quindi, riavviare il server X. E' possibile visuallizzare la modeline corrente dall'interno del server X in esecuzione, digitando da una console (ad esempio da kterm) 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. Questo dipende dal driver che stiamo usando, dalla sua versione e dal tipo di monitor collegato. Ad esempio, pare che quando si utilizzano monitor LCD in un laptop ogni modeline custom venga semplicemente ignorato. Altri driver ancora prediligono le informazioni ottenute con VBE/DDC/EDID sopra quelle imputate dall'utente. E' ovviamente necessario fare un po' di tentativi per scoprire cosa si può personalizzare e fino a che punto.

Conclusioni

Abbiamo analizzato come funziona una console in modalità grafica di tipo frame buffer, come configurare le opzioni del kernel e come impostare la risoluzione che preferiamo tramite i parametri dei driver e tramite utility di livello userspace. Ovviamente, si potrebbe dire altro ancora sulla configurazione della console e sull'utilizzo del frame buffer, spero che questo articolo possa essere una base di partenza per approfondire ulteriormente l'argomento.

FAQ

Q Posso evitare di ricompilare il kernel ed usare il kernel standard di Slackware?

A No, a meno che non si voglia usare il driver vesafb. Il kernel standard di slackware ha compilati tutti i driver specifici come moduli
ed ha attivate una serie di opzioni che possono essere problematiche con alcune schede, come le schede radeon.
Pertanto, è consigliato ricompilare il kernel secondo i consigli di questa guida.

Ringraziamenti

Autore: Samuele "Nuitari" Diella - samuele.diella@gmail.com

Articoli Correlati

Slackware Graphic Boot Splash HOWTO

Links Esterni

Strumenti personali
Namespace

Varianti