Nel prossimo mese dovremmo vedere l’arrivo del nuovo kernel 5.17, che tra le novità disponibili presenterà un nuovo driver chiamato x86-android-tablets, fatto appositamente per gestire alcuni bug relativi ai tablet x86. L’autore del driver, Hans de Goede, aveva già presentato in passato numerose patch proprio per gestire le problematiche dei device Android che non funzionavano bene una volta installato Linux al posto del sistema operativo di default.
Questo accade perchè molti tablet x86 Android presentano una tabella DSDT (Differentiated System Description Table) non corretta. Il DSDT è una parte della specifica ACPI, e ha come scopo il presentare al sistema operativo la lista dei device di sistema, il mapping degli IRQ e la descrizione del codice da lanciare per gestire i cosiddetti power events, come ad esempio come spegnere la macchina dopo aver lanciato una richiesta di shutdown dal sistema operativo, oppure come spegnere il monitor quando viene chiuso lo schermo di un laptop, o ancora come far partire o spegnere le ventole. Insieme alle altre tabelle ACPI rappresenta sostanzialmente l’interfaccia verso il mondo hardware della macchina che stiamo operando. Va da sé che un DSDT non corretto possa fare sì che, a fronte di una richiesta di sistema, non si ottenga alcun risultato in quanto questa venga inviata a periferiche non effettivamente esistenti.
Uno dei casi in cui ad esempio sia utile andare a lavorare con le tabelle ACPI è nel mondo Hackintosh, in cui per andare a convincere il sistema operativo di utilizzare o meno una data scheda wireless, o gestire correttamente un power management leggermente diverso da quelli di casa Apple, è necessario decompilare, patchare e reinstallare la tabella DSDT. Ma anche con Linux a volte è necessario fare operazioni di questo tipo, e il Kernel permette di estrarre dal firmware le informazioni presentate da ACPI al boot, trasformarle dal loro formato compilato AML ad una versione ASL/DSL (ACPI Source Language, una sorta di codice sorgente specifico per le tabelle ACPI), modificarle, magari cambiando qualche percorso hardware non proprio corretto, e presentarle al prossimo riavvio della macchina insieme all’initrd.
Per quale motivo un DSDT potrebbe essere non completamente corretto? Uno dei casi possibili è la produzione in serie di diverse tipologie di modelli hardware, ciascuna con differenti indirizzamenti hardware delle periferiche esistenti; alcuni modelli potrebbero non avere l’accelerometro, altri avere un particolare tipo di touchpad, diverso rispetto agli altri. Il DSDT presentato sarebbe poi lo stesso per tutti, e la parte di gestione effettiva delle periferiche sarebbe demandato al sistema operativo built-in, che, tramite una flessibilità maggiore, possa considerare tutte le varie casistiche a runtime. Sostituire quindi il sistema operativo con Linux farebbe sì che ci si potrebbe trovare con un tablet con periferiche non più funzionanti perché indirizzate in maniera erronea.
Per evitare di gestire la cosa tramite la procedura presentata sopra, purtroppo, l’unica alternativa, che è poi la soluzione applicata dal driver x86-android-tablets è il creare una tabella di matching modello/DSDT, che copra tutte le casistiche presenti, in modo che venga applicata la corretta table al boot di sistema.
Un altro passo verso la libertà di utilizzo del nostro sistema operativo preferito su qualsiasi periferica!
Sostenitore di lunga data dell'Open Source, Sysadmin ma anche programmatore, mi appassiona qualsiasi cosa nell'IT che possa permettere un'espressione di creatività. Nostalgico della filosofia dei tempi andati, ma incuriosito dalle potenzialità dei paradigmi moderni.
English (US)