Ubuntu ha scelto la strada di un nuovo display server, Mir, per raggiungere l´obbiettivo della convergenza di tutti i form factor nella base di codice del prossimo Unity Next. Mir sarà ovviamente in grado di far leva sull´attuale stack grafico open source per il desktop, composto dai moduli KMS del kernel, dalla libreria Mesa e dai driver grafici. Ma trattandosi di codice che dovrà girare, senza modifiche, anche su piattaforme mobili, dove lo stack open non è disponibile, si pone il problema di come farà Ubuntu Touch a supportare l´accelerazione grafica sui dispositivi embedded.
Kevin Dubois, uno dei principali sviluppatori di Mir, è entrato nel dettaglio della strategia di Canonical, che come già anticipato (fatto passato in secondo piano durante la diatriba con la comunità di Wayland) sull´unico stack grafico open presente in campo embedded che si sia già abbondantemente affermato: quello di Android. L´ecosistema Android richiede ad ogni produttore di fornire tre componenti per rendere funzionante il loro driver grafico:
- Un modulo del kernel - ha il controllo diretto dell´hardware, ma la sua responsabilità principale e di inoltrare al firmware della GPU i comandi che agiranno sul buffer grafico, e di ricevere quelli elaborati.
- Una implementazione di libhardware - parte dell´HAL (Hardware Abstraction Layer) di Android, sono delle librerie che fanno da collante tra le componenti a basso livello e quelle ad alto livello; in particolare si occupano di operazioni preliminari sui buffer.
- Una libreria userspace OpenGLES e EGL - è qui che il vendor inserisce il codice specifico della sua GPU, con la completa implementazione della specifica OpenGL che sfrutta l´hardware a disposizione.
In quanto ad apertura, la prima è ovviamente sempre open source, essendo il kernel GPL; la seconda componente è a volte proprietaria, a volte aperta, mentre chiaramente la libreria OpenGL del produttore è quanto di più proprietario esista nello stack. Tuttavia, per come è implementato e licenziato Android, le componenti proprietarie si interfacciano con quelle open source attraverso un set di API che hanno due caratteristiche importanti: sono accessibili (i file header che le espongono sono sotto licenza Apache e/o Khronos) e stabili, essendo sotto il controllo combinato di Google e del gruppo Khronos che rilascia le specifiche OpenGL.
In sostanza lo stack Android, dice Dubois, "non è nè al 100% closed nè al 100% open" ma è abbastanza aperto da poter essere implementato e da non costituire un bersaglio in continuo movimento. Mir replicherà le funzionalità open source di Android al proprio interno e si interfaccerà con l´indispensabile componente proprietaria binaria.
Questo comporta vantaggi immensi per Ubuntu, sostiene Dubois. Innanzitutto, non c´è alcun bisogno di buttarsi di nuovo nell´eterno gioco delle richieste di supporto al produttore: il loro driver funziona così come viene fornito, senza modifiche. Canonical non deve preoccuparsi di scrivere un proprio HAL, essendo espressamente necessario quello di Android. Ed infine, cosa più importante per gli utenti, sfruttando quanto già presente si ereditano le performance e la gestione energetica già ottimizzate tipiche di Android. Nelle parole di Dubois, con questa strategia Ubuntu "metterà le fondamenta di Mir e Unity Next non sulla sabbia, ma sulla roccia".