In questo post si cercherà di approfondire il Kernel Mode Setting di Linux. Negli ultimi mesi si è sempre più parlato di questa funzionalità e delle potenzialità che essa offre. Sembra doveroso, quindi, approfondire l´argomento e capire cosa è realmente il mode-setting.
Cosa è il Kernel Mode Setting. "Il Kernel Mode Setting è una funzionalità che consente di impostare la risoluzione dello schermo e la profondità del colore (il numero di bit utilizzati per rappresentare un singolo pixel grafico), così come altri parametri che hanno a che fare con l´inizializzazione della parte grafica." Implementare il KMS nel Kernel Linux significa configurare all´avvio della macchina la scheda grafica secondo le impostazioni indicate dai parametri di boot.
Sebbene il KMS sia concettualmente immediato da capire esso nella pratica richiede una riorganizzazione non banale dei moduli e del codice. Basti pensare al fatto che lo stack grafico Linux/FOSS utilizzato per anni è frammentato su più livelli, e non tutti interni al kernel: vga driver (kernel), framebuffer driver (kernel), DRM driver (kernel), X drivers (userspace), DRI e DDX driver (userspace), e altre librerie di gestione (userspace). Il Kernel Mode Setting implica lo spostare funzionalità dal layer userspace dell´X Server in quello interno al Kernel Linux.
Affrontare il problema dell´inizializzazione della scheda grafica e delle impostazioni dello schermo video non è proprio semplice. La questione, infatti, deve essere analizzata da due punti di vista. Da un lato bisogna snellire e rivedere parte dell´architettura di rendering dell´X Server, dall´altro bisogna importare codice nel Kernel Linux e aggiungere tutto quello che manca (interfacce, moduli, IOCTL). Non meraviglia, dunque, che il lavoro che si sta compiendo per l´implementazione del KMS è davvero complesso, e richiede uno sforzo sinergico di tutta la comunità open source.
Un brevissima storia. Si è iniziato a parlare ufficialmente di Kernel Mode Setting a partire dal Kernel Linux 2.6.29 (23 marzo 2009), il primo a riportare nelle Release Note la sezione KMS. In realtà il cammino verso il KMS era già iniziato da tempo, e solo col Kernel Linux 2.6.28 (25 dicembre 2008) si era entrati nel vivo dei lavori allorquando era stata rilasciata una versione stabile del modulo "GEM ("Graphic Execution Manager")". Questo nuovo componente si occupa della gestione della memoria delle GPU, e nelle intenzioni degli sviluppatori del Kernel dovrebbe sostituire quello TTM (Translation-Table Maps) attualmente in uso.
Nel mondo delle distribuzioni Linux il supporto al Kernel Mode Setting è per lo più ancora in divenire. Infatti, non tutte le distribuzioni Linux sono allo stesso punto, e non tutte hanno seguito lo stesso percorso. Probabilmente Fedora è la distribuzione che prima si è mossa su questo fronte, e fin dalla release F10 (ma forse anche da F9) ha cercato di portare in casa il risultato, completandolo parzialmente con il rilascio di Fedora 11. Ubuntu, invece, sta seguendo tutt´altra strategia puntando a qualcosa di più stabile e definitivo, ma sempre seguendo gli sviluppi del Kernel Linux. Infatti, sebbene Fedora sia stata la prima distribuzione ad avere il KMS c´è anche da dire che questo lavoro è stato frutto di investimenti personali. Ubuntu, dal canto suo sta seguendo l´evoluzione del Kernel Linux e del server grafico X.
Moblin, la distribuzione Linux di casa Intel per i netbook e i nettop, fa storia a se. Intel in questo caso controlla tutta la catena di produzione, dalla progettazione e realizzazione dei chipset grafici fino allo sviluppo dei driver e delle librerie software. Questo ha ovviamente comportato un indubbio vantaggio che è tutto confluito in Moblin fin dal rilascio della versione
V2 Alpha2 avvenuta il 24 marzo 2009.
Il Kernel Linux 2.6.31 attualmente in fase di sviluppo potrebbe avere "un Kernel Mode Setting molto più maturo". Già a partire dalla Release Candidate 1, infatti, è stato reso noto che si stanno stabilizzando il più possibile i driver ATI e nVidia in merito proprio all´utilizzo del KMS. I driver Intel per quanto detto sopra sono stati fin da subito capaci di gestire il KMS (ndr almeno su Moblin).
I vantaggi del KMS. Il Kernel Mode Setting apporterà vantaggi a diversi livelli. Ecco i principali:
- Il controllo delle impostazioni verrà spostato e "centralizzato" nel Kernel Linux. Un solo modulo sarà coinvolto con conseguente minore ridondanza di codice, snellimento e uniformità delle procedure di gestione, nonché riduzione dei livelli software "attraversati";
- Sarà possibile implementare "un processo di boot più fluido", con un´unica splash grafica dall´avvio del kernel fino all´entrata nel desktop grafico, e senza reset del monitor o riscalature grafiche;
- La gestione "del suspend e del resume" dell´hardware grafico avverà tutta nel kernel, anche in questo caso il tutto risulterà più veloce e snello;
- Sarà possibile eseguire un "Server X come utente non privilegiato" (No-Root X), e questo a tutto vantaggio della sicurezza del sistema;
- Si potrà ipotizzare la scrittura di "un nuovo driver del framebuffer", più veloce e funzionale;
- Il Kernel Linux potrà gestire delle "splash grafiche di diagnostica", per mostrare agli utenti in maniera più semplice eventuali messagi di warning ("blue penguin of death").
Per una descrizione più dettagliata di alcuni di questi aspetti si rimanda alla mail di annuncio del KMS.
Strumenti per sperimentare il KMS. Va premesso che a differenza di tante altre funzionalità grafiche fare prove o esperimenti col Kernel Mode Setting non è ne semplice e neanche immediato (richiede competenze di programmazione, e conoscenza del Kernel Linux e delle schede grafiche). Oltre a questo va anche detto che usare il KMS può rivelarsi rischioso se non si è consapevoli di quello che si sta facendo. Ovviamente, nulla di preoccupante, e nella quasi totalità dei casi preserverete la stabilità del sistema e l´integrità dei dati, ma potreste incontrare problemi nel reimpostare la configurazione dell´X Server.
Gli utenti Fedora sono certamente quelli più avvantaggiati in quanto hanno a disposizione già questa funzionalità nell´ultima versione F11 Leonidas. Ovviamente dovrete capire se la vostra scheda grafica è supportata.
Gli utenti Ubuntu al momento possono seguire due strade. Possono provare ad installare un kernel 2.6.30 secondo quanto indicato sul Wiki, e questo dovrebbe andare bene per chi ha una scheda grafica Intel. Gli utenti che hanno una scheda grafica nVidia o ATI possono invece utilizzare una delle due spanshot di Ubuntu 9.10 rilasciate dal team "xorg crack pushers" sui canali PPA di Canonical. Occhio, Ubuntu non ha ancora un supporto completo al KMS.
Chi invece vuole usare il KMS di Moblin deve semplicemente allinearsi all´ultima versione di questa distribuzione e installarla ovviamente su un dispositivo compliant, il che vuol dire su una macchina con Intel Atom e processore grafico Intel.
Inoltre, gli utenti Debian posso fare riferimento a quest´unica risorsa presente sul wiki (se ne avete altre segnalatele tra i commenti).
Una passeggiata tra Kernel e X Server. Parlare tecnicamente di Kernel Mode Setting non è banale, bisogna giocoforza parlare del Kernel e dell´X Server e di come queste due entità interagiscono.
Un buon punto di partenza può essere la documentazione del modulo DRI, e in particolare il Control Flow Diagram riportato sul sito ufficiale del progetto. Questo diagramma mostra i componenti che vengono usati quando l´X Server, o più in generale un applicativo grafico che usa l´infrastruttura X.Org, disegna un oggetto grafico. I blocchi in alto corrispondono agli applicativi utente, il blocco in basso rappresenta il kernel e l´hardware grafico, nel mezzo trovate una serie di blocchetti che corrispondo alle librerie e ai demoni coinvolti nell´operazione di Rendering.
Tipicamente il server X può accedere all´hardware grafico in due modi: passando per il modulo DDX o per quello DRI/DRM (Direct Rendering). Nel caso dell´accesso DDX il server X usa questo modulo come intermediario, passandogli i comandi e i dati di rendering. Il modulo DDX a sua volta accede all´hardware grafico passando o meno per il kernel. Nel caso dell´accesso DRI/DRM invece il server X, o chi per esso, comunica direttamente con l´hardware grafico, eliminando un passaggio e accelerando il tutto (meno copie di dati, e accesso diretto alla RAM mappata). In questo caso la libreria DRI in userspace si interfaccia col driver DRM in kernel space che gli fornisce l´accesso desiderato.
L´introduzione del Kernel Mode Setting ha comportato una evoluzione di questa architettura, e non certamente uno stravolgimento.
Come detto poco sopra il KMS è stato introdotto nel Kernel Linux solo dopo la stabilizzazione del driver GEM. Il principale componente che lavora sul KMS è il driver DRM, che ora implementa delle nuove IOCTL per l´accesso da user space, cioè da parte degli applicativi grafici. La riscrittura del driver DRM ha comportato una revisione delle librerie in user space, è nata così la libreria DRI2. Il modulo DDX, come si può apprendere anche dal Wiki di X.Org, è stato snellito di molto.
Il processo di boot cambia. All´avvio la gestione dell´inizializzazione grafica verrà fatta dal Kernel, mentre l´X Server dovrà eventualmente preoccuparsi solo di impostare i corretti parametri, cioè risoluzione, profondità di colore, frequenza di refresh, e così via. Ovviamente se i parametri impostati dal Kernel Linux sono gli stessi usati dall´X Server allora la reimpostazione non sarà necessaria e questo a vantaggio dell´utente finale che non accuserà il passaggio dall´uno all´altro gestore grafico.
La descrizione che è stata fatta è molto di alto livello, sono stati tralasciati tutti gli aspetti relativi ai driver grafici presenti in X, così come tutto l´eventuale discorso relativo a Mesa e OpenGL, che sebbene non direttamente coinvolti potrebbero subire lievissime modifiche. L´idea di questo post è quella di fare il punto della situazione e di fornire spunti per ulteriori approfondimenti.
Per i curiosi, eccovi l´elenco delle IOCTL aggiunte: DRM_IOCTL_MODE_GETRESOURCES, DRM_IOCTL_MODE_GETCRTC, DRM_IOCTL_MODE_GETOUTPUT, DRM_IOCTL_MODE_SETCRTC, DRM_IOCTL_MODE_ADDFB, DRM_IOCTL_MODE_RMFB, DRM_IOCTL_MODE_GETFB. Ovviamente rimandiamo alla documentazione del Kernel Linux per una comprensione
No-Root X. In questi giorni si inizia a parlare di un´altra piccola rivoluzione che il Kernel Mode Setting si porta dietro ed è quella del No-Root X, ovvero dell´X Server eseguito come utente non privilegiato. Sulla mailing list del progetto Gnome si sta discutendo il come poter implementare la funzionalità, importando probabilmente parte del lavoro fatto per Moblin.
Da quel che sembra l´X Server ha bisogno dei diritti di root per 5 motivi:
- I/O probing;
- tty/VT probing e controllo;
- invocazione di IOCTL del driver DRM;
- PCI probing;
- Gestione input;
Di questi cinque punti quelli che più bloccano l´esecuzione di X come utente non root sono il primo, il terzo e il quarto; il KMS sembra sbloccarli. Per i punti 2 e 5 esistono delle soluzioni alternative a quelle attuali, e che passano per librerie wrapper e il sistema di sicurezza PAM. Date una occhiata alla discussione per farvi una idea.