Eeepc Asus e acpi

Già in passato avevo manifestato un pò di sofferenza riguardo la scelta di Asus di piazzare Xandros come distribuzione per l’eeepc.

In ogni caso al di là della scelta della distribuzione un computer (in particolare un portatile) distribuito direttamente dalla casa madre con Gnu/Linux ha importanti vantaggi nel senso che tutto il suo hardware si presume sia completamente supportato.

photo credit: Retrocactus

l’assenza del tasto windows è sicuramente già un ottimo vantaggio 😀

Questo vale sia in termini di scelta di periferiche con driver che supportano Linux, sia la scrittura di driver appositi per il computer che si vuole commercializzare.

L’Eeepc ovviamente non fa eccezione, tutto è supportato a meraviglia…ma ci sono alcuni “ma”…

I driver wireless hanno licenza proprietaria! Esisono schede wireless (vedi intel) con ottimi driver open ufficiali che rispettano in tutto e per tutto gli strumenti che il kernel e i tool (iwconfig iwlist ecc..)mettono a disposizione.

I driver madwifi invece sono un pò un mischiotto, di per se sarebbero driver aperti ma dipendono da molto codice proprietario, fatto sta che a mio parere sono tutt’altro che integrati col kernel, vedi l’obbligo di usare wlanconfig al posto di iwconfig per operazioni particolari e il non supporto al nuovo stack mac80211

Piccola parentesi, c’è un progetto che ha come obbiettivo realizzare dei driver completamente aperti per schede wireless con chip atheros, ma al momento non c’è nulla di utilizzabile.

Oltre a questo normalmente il tasto dolente è il supporto all’acpi nei portatili; l’eeepc ha ovviamente un modulo acpi ufficiale asus che viene usato in xandros e del quale sono stati rilasciati i sorgenti. Quando però leggi queste cose ti cascano le braccia: (dalla lista Debian-eeepc-dev)

I happened to look at the patched asus_acpi.c module that was posted
by Asus and then updated for more recent kernels, and almost barfed.

It’s 75% dead code — the Eee PC support is just stuck on at the end.
And of course it conflicts with the real asus_acpi.ko in any Debian
kernel package.

So I cleaned it up, renamed it eeepc_acpi, and packaged it as a
separate out-of-kernel Debian package that can be built with
module-assistant.

Here’s the comparison from “wc”:
1907 6180 50911 asus_acpi.c
453 1434 13037 eeepc_acpi.c

Qui si dice che la Asus ha patchato il codice per i kernel più recenti ma sul sito ufficiale non ho trovato nessuna patch e il modulo col kernel 2.6.24 non si compila!

In ogni caso basta leggere e guardare la differenza di peso in kb dei due moduli per rendersi conto del pastrocchio che hanno combinato alla Asus 😀 . Nella lista il massaggio dopo dice “I read the asus code some time ago and seems to be a LITTLE bit crazy xD” .

A questo punto mi domando una cosa, se un’azienda così importante come Asus fa un lavoro…diciamo mediocre… con un componente così importante con i driver acpi sapendo che tutti avrebbero spulciato il suo codice, cosa combinano tutti i giorni aziende più o meno importanti di Asus con software di cui nessuno vedrà i sorgenti? 😀 mha…

Per questo motivo in debian e in Ubuntu (ma presumo in tutte le distro con kernel 2.6.24) verrà usato il modulo eeepc-acpi e non quello asus. Questo purtroppo sputtana gli hotkeys così come sono configurati dai vari script di supporto a ubuntu, quelli del team Debian-Eeepc hanno risolto con un loro pacchetto eeepc-acpi-scripts che però va in conflitto con acpi-support il quale permette l’integrazione con la gestione dell’alimentazione di gnome per esempio. Togliendolo non si hanno le icone fighe (del volume per esempio) quando si premono i tasti. Si potrebbe tranquillamente soprassedere, ma credo che riadattare al nuovo acpi gli hotkeys degli script di supporto per ubuntu non sia niente di difficile e a breve ci proverò.