La notizia del rilascio, da parte di Raspberry Pi Foundation e Broadcom, dei driver dell´architettura ARM in uso dal mini-pc sotto una licenza open source (alcuni componenti in BSD, altri sotto GPL) ha destato scalpore ed entusiasmi. In particolare nel comparto grafico, i vendor ARM da sempre si dimostrano più che restii ad aprire questa sensibile parte dello stack. Sullo stesso blog ufficiale si loda infatti Broadcom come il primo produttore a scegliere la via dell´open source per la loro GPU Mobile VideoCore IV integrata nel system-on-chip BCM2835.
Purtroppo la realtà è ben diversa, e la portata dell´annuncio è molto minore di quanto si potesse sperare: David Airlie e Luc Verhaegen, due sviluppatori coinvolti a fondo nello stack grafico del kernel Linux (DRM e driver, rispettivamente) hanno smascherato negli stessi commenti del blog ufficiale la natura del codice rilasciato e la sua sostanziale inutilità per la comunità.
Il modus operandi tipico dei vendor ARM è quello di rilasciare un modulo open source per il kernel da far lavorare poi con un altro componente proprietario in user-space. La particolarità di Broadcom consiste nell´aver rilasciato sotto licenza open anche il componente in user-space. In entrambi i casi, c´è un componente che rimane comunque proprietario ed è il firmware della GPU: è il caso anche dei comuni driver grafici per il desktop Linux, come nouveau, che hanno bisogno di caricare il firmware proprietario per inizializzare la GPU al boot. Normalmente questo firmware contiene solo delle routine di configurazione dell´hardware o di gestione energetica, ma nel caso della GPU VideoCore IV esso contiene la parte fondamentale che si credeva fosse stata resa open source, ovvero lo stack OpenGL ES. Questo rende impossibile qualsiasi contributo di terze parti.
David Airlie nel suo blog ha assolutamente escluso che questo pseudo-driver possa essere integrato nel mainline del kernel Linux:
No. È come nel caso delle schede Ethernet dotate di TCP offload, dove l´intero stack TCP/IP è in esecuzione sul firmware della scheda. Queste schede possono sembrare una soluzione interessante, finché poi non si trovano bug nel firmware o salta fuori che la loro implementazione del TCP/IP non è affatto buona. Lo stesso problema si ripresenta con questa roba. Ci scommetto che la loro implementazione GLES fa schifo, perché tutte quelle che [i vendor] fanno sono schifose, ma il punto di rendere tutto open source è quello di consentire ad altri di apportare migliorie ed è assolutamente impossibile in un caso come questo.
Quindi, davvero, un bel big FAIL per Raspberry Pi e Broadcom per essersi persino prese il disturbo di fare un comunicato stampa per questa roba, se avessero semplicemente postato il codice e basta sarebbe stato ok, nessuno sarebbe stato neanche un po´ più felice di prima, ma qualche idiota ha creduto che questo schifoso layer di servizio meritasse un comunicato, ridicolo.