Col senno di poi

È stato un Capodanno difficile per il mio portatile: non ha particolarmente apprezzato la Moretti che gli è stata versata sulla tastiera. In effetti neanche io sono un grande estimatore della suddetta. Un’azione tempestiva mi ha permesso di salvare quasi tutto, ma un ferito è rimasto sul campo di battaglia: la tastiera, inebriata dall’alcool, ha iniziato a sputare fuori caratteri casuali a gruppi di tre o quattro.

Questo è l’inizio dell’odissea: recuperata dell’acqua demineralizzata ho smontato la tastiera pezzo per pezzo e ci ho dato una bella lavata, ma purtroppo non l’ho potuta rimontare. Durante il lavaggio, infatti, si sono staccate le capsule di quattro tasti, e finché non avrò deciso qual è il metodo più furbo per reincollarle mi toccherà girare con una tastiera usb nello zaino: non è il massimo della vita, ma fa davvero figo avere la scheda madre a vista e la tastiera retroilluminata

Così armato ero convinto di poter resistere, ma avevo fatto i conti senza l’oste: la mia tastiera infatti, essendo da desktop, non ha il tasto Fn, che tra le varie cose mi serve a cambiare la luminosità dello schermo. Mi ritrovo quindi con uno schermo semibuio (l’ultima volta era stato usato di notte) ma poco male, mi dico, tanto posso sempre usare xev per intercettare i keycode e poi rimapparli con xmodmap sui tasti multimediali della tastiera usb. E invece no. Il mio splendido portatile, ho scoperto poche ore fa, non usa un metodo standard per la gestione dell’acpi, e invece di generare eventi da intercettare richiede un complesso sistema di polling.

Dopo qualche smanettamento infruttuoso mi capita in mano il modulo omnibook: lo usavo tempo fa proprio per gestire certe cose che l’acpi tradizionale non supporta, come ad esempio la temperatura del processore, la gestione delle ventole, il touchpad… e, vengo a sapere, lo schermo! Credo di potermela cavare compilandomi il modulo (che ovviamente non è stato inserito nel main tree), ma mi sbaglio di grosso. Le strutture del kernel per la gestione degli schermi lcd sono cambiate parecchio dall’ultima release del modulo, che risale a quasi un anno fa. Per fortuna nel repository svn sono state fatte le modifiche necessarie, quindi mi basta usare quello.

Sorvolo sulle problematiche tecniche di svn in https sulla rete (mal) proxata del Politecnico («Grazie amici!») che mi hanno costretto a patcharmi a mano i file necessari (a me bastava che compilasse, e l’operazione è stata piuttosto lunga modificando due soli file, non voglio pensare al resto). Procedo dunque pedissequamente all’inserimento di svariati blocchi del tipo #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,21) solo per trovarmi davanti a… un altro errore di compilazione!

Ora, io non ho mai veramente letto il codice di un modulo del kernel, men che meno mi è capitato di cercato di capire cosa non andasse per metterlo a posto. Questa volta mi è toccato farlo, dato che nessuno aveva ancora messo mano alla cosa. Vado a spulciare linux/backlight.h, drivers/video/backlight/backlight.c e relativi changelog per scoprire che la funzione class_get_devdata(class_device *dev) non si può più utilizzare, perché per le backlit devices è stata definita una funzione dedicata, bl_get_data(backlight_device *bl_dev), incompatibile con la precedente. Sostituisco, lancio il make… compila! Certo non significa nulla, bisogna ancora verificare che funzioni… insmod… in /proc/omnibook vengono creati tutti i nodi necessari, lcd compreso.

 [root@paradigm ~]# echo 7 > /proc/omnibook/lcd

E luce fu.