Un peccato dover riavviare Fastidio a parte, questo significa che la nuova beta dei driver nvidia ha finalmente risolto il fastidioso problema che freezava il sistema, e finalmente arch è rock stable E questo 2.6.33, poi, non vedo l’ora che esca, sto testando la rc6 e mi gusta assai, in particolare per l’attesissima introduzione della headphone detection sui Macbook 5,1 e 5,2.

In questo ci viene d’aiuto il buon vecchio vim: prima di tutto per il testo bianco su sfondo nero, che è decisamente più riposante dell’opposto se usato con un font decente. In proposito consiglio terminus (pacman -S terminus-font), un monospace pensato appositamente per i terminali che mantiene un’ottima leggibilità anche in queste condizioni, in corpo 8 per chi ha la vista buona come il sottoscritto, 10 per gli altri. Poi c’è la syntax highlighting, che rende molto più facile il gioco della caccia al commit, da usare regolarmente in congiunzione con la linea set background=dark in /etc/vimrc o in ~/.vimrc per avere il giusto contrasto di colore.

Tutto questo è un buon inizio, resta il problema del saltellamento del bulbo oculare, la vera piaga di tutta la faccenda. Mentre si delineava nella mia testa tutto questo bel giochino ho pensato che un semplice /^commit seguito da tante n sarebbe bastato, e invece no: il cursore va a piazzarsi a fondo pagina, col risultato che vedo solo l’id del commit perdendomi completamente il contenuto. Essendo un utente medio di vim conosco qualche comandino da tastiera, ma non mi sono mai lanciato nell’uso avanzato. Mi sono quindi messo alla ricerca di un modo per far sì che la riga che matcha diventasse la prima della pagina, in modo da avere sempre la descrizione nello stesso punto e risparmiarmi una pupilla che sembra muoversi di moto browniano. E l’ho trovato.

Per far sì che la riga del cursore venga messa in cima alla pagina basta premere zt in modalità comandi. Dato che premere nzt 8739 volte non mi attirava granché, ho pensato di attivare un mapping che mi consentisse di usare un solo tasto per fare tutto. E dunque, ecco svelato l’arcano:

:nmap n nzt

Una volta fatto ciò, ad ogni pressione di n sarà come aver premuto in sequenza i tasti nzt, e dopo aver lanciato la ricerca (/^commit, come si diceva) potremo usare questo tasto per navigare comodamente il ChangeLog.

In aggiunta ho scoperto da poco che qualcuno ha scritto finalmente una patch per ALSA 1.0.19 (ma comunque compatibile con la 1.0.20) che integra il supporto ai MacBook 5,1. Sono quindi utilizzabili tutti i canali audio, anche se i controlli non sono ancora il massimo della vita. La scheda dovrebbe essere automaticamente riconosciuta per i 5,1; i 5,2 hanno una scheda simile, e il riconoscimento può essere forzato inserendo la riga “options snd_hda_intel model=mb5″ in /etc/modprobe.d/modprobe.conf. Attenzione a chi prima aveva impostato il parametro model=mbp, quella linea va eliminata perché tutto funzioni correttamente.

Ma andiamo a vedere i controlli. Nell’immagine che segue possiamo vedere come si presenta il mixer con il kernel 2.6.30.

Al momento non è supportata la headphone detection, quindi esistono tre switch principali: PCM, ovvero il controllo volume principale, Master, che controlla l’uscita dalle casse integrate, e HP, che controlla l’uscita cuffie. È da notare che azzerare il volume di uno o dell’altro non è sufficiente a zittire completamente l’uscita corrispondente, è necessario mettere in muto il canale.

I MacBook, poi, sono provvisti di un piccolo woofer interno. Questo, al momento, è controllato tramite lo slider LFE, mentre il volume dei due midrange/tweeter si imposta sullo slider Front. Le cuffie, chiaramente, non hanno di questi problemi essendo altoparlanti stereo tradizionali, quindi l’unico controllo volume necessario è HP.

Sembrano non avere effetto gli slider Surround e Line, e lo switch Channel, che prima serviva a passare dalle cuffie alle casse integrate. O forse sono io che di tutta questa roba non so che farmene. In compenso, udite udite, finalmente il microfono funziona!

Qualche problema il kernel invece sembra darlo dal lato del wireless: fatico molto, con il craptastico driver proprietario della Broadcom, a recuperare una connessione wireless dopo la sospensione, cosa che non avveniva in precedenza, neanche nelle ultime RC di questa release.

Potete scaricare il PKGBUILD con la configurazione e la patch qui. Buon divertimento!

Prima di tutto l’audio. Al momento il chipset non è perfettamente supportato, ma funziona, con qualche scomodità, passando l’opzione model=mpb3 al modulo snd-hda-intel. Perché sia fatto automagicamente all’avvio è sufficiente aggiungere, in /etc/modprobe.conf, la riga:
options snd_hda_intel model=mbp3
Il mixer ci presenta diversi canali e switch. Uno con cui dobbiamo fare conoscenza subito è Channel, che può passare da due a sei canali: 2ch indica le cuffie, 6ch le casse integrate. Purtroppo ancora non viene rilevato automaticamente se abbiamo collegato delle cuffie, quindi per il momento va impostato a mano. I due slider associati al volume delle casse sono Master (ma dai?) e Line-out, mentre se siamo in modalità cuffia oltre a Master dobbiamo regolare Front, e lo switch Speaker ci dà la possibilità di mettere in muto completamente il suono. Inoltre lo switch IEC958 attiva l’uscita ottica (potrete notare che, togliendo il muto, si accende una luce rossa nell’uscita cuffie).

Purtroppo l’audio non è così semplice da far funzionare. Il kernel 2.6.28 è passato in [core] nel giro di pochi giorni, seguito a ruota dal 2.6.28.1. Mentre la 2.6.28 andava bene, quest’ultima dà qualche grattacapo. Evidentemente uno dei tre commit sul driver snd-hda-intel ha portato ad una regressione, segnalata anche da qualche altro utente su portatili diversi. La soluzione è stata scaricare la nuova versione di alsa-lib, la 1.0.19 e ricompilarla per il nuovo kernel. Le possibilità sono due: sovrascrivere ALSA direttamente nel kernel e ricreare il pacchetto oppure compilare ALSA a parte e mettere i moduli nella cartella /lib/modules/kernel-2.6.28-ARCH/updates, dove saranno letti prima di quelli originali. Una volta fatto questo l’audio dovrebbe ritornare come prima (caveat emptor: reboot necessario).

Ho lavorato un po’ anche sul fronte power saving, prima di tutto installando cpufrequtils, laptop-mode-tools, pm-utils, bc, nvclock e xscreensaver. A livello di risparmio energetico il governor migliore per il processore è ondemand (sì, è meglio anche di conservative), quindi l’ho impostato in /etc/conf.d/cpufreq e ho inserito il demone cpufreq in /etc/rc.conf. Ho poi modificato /etc/acpi/handler.sh in diversi punti; ne riporto le parti interessate.

Premere il pulsante di accensione fa fare al sistema uno shutdown ACPI:

    button/power)
        #echo "PowerButton pressed!">/dev/tty5
        case "$2" in
            PWRF)
                logger "PowerButton pressed: $2"
                halt
            ;;

Collegare e scollegare il portatile dalla rete elettrica modifica la luminosità dello schermo e avvia o ferma il laptop-mode:

    ac_adapter)
        case "$2" in
            AC)
                case "$4" in
                    00000000)
                        #echo -n $minspeed >$setspeed
                        /usr/bin/nvclock -S -15 >/dev/null 2>&1
                        /etc/rc.d/laptop-mode start
                    ;;
                    00000001)
                        #echo -n $maxspeed >$setspeed
                        /usr/bin/nvclock -S +15 >/dev/null 2>&1
                        /etc/rc.d/laptop-mode stop
                    ;;
                esac
                ;;

La chiusura del lid, come su OS X, mette il sistema in sospensione e, alla riapertura, chiede la password tramite xscreensaver (questo solo se il demone è attivo):

    button/lid)
        #echo "LID switched!">/dev/tty5
        case "$2" in
            LID0)
                _res=$( bc <<< "ibase=16; $( tr [:lower:] [:upper:] <<< $4 )%2" )
                case "$_res" in
                    0)
                        nvclock -S $( cat /tmp/.bllev )
                        rm -f /tmp/.bllev
                    ;;
                    1)
                        echo $( nvclock -i | grep '^Backlight' | cut -d' ' -f3 ) > /tmp/.bllev
                        xset dpms force off
                        pidof xscreensaver >/dev/null 2>&1
                        if [ "$?" -eq 0 ] ; then
                            xscreensaver-command -lock >/dev/null 2>&1
                        fi
                        pm-suspend
                    ;;
                esac

            ;;
            *)  logger "ACPI action undefined: $2" ;;
        esac
        ;;

Anche per questa volta è tutto, ma aspettatevi nuovi post quando avrò altre informazioni utili sottomano

Prima di tutto è pressoché fondamentale il kernel 2.6.28, che al momento si trova in [testing], perché è il primo ad introdurre il supporto alla maggior parte dell’hardware per questo portatile. In particolare i moduli hid-apple, bcm5974 e applesmc hanno ricevuto in questa release importanti aggiornamenti. Al kernel ho poi applicato alcune patch recuperate dalla LKML, quattro specifiche per il modulo bcm5974, quello che si occupa del trackpad, una per la ethernet e una per l’undervolting. Le patch sono allegate a questo post, per chi fosse interessato ad applicarle, insieme alla configurazione del kernel che ho utilizzato, e nel corso del post spiegherò cosa fanno esattamente. Ci tengo a precisare che non ricompilo un kernel da un annetto, quindi potrei aver infilato dentro tonnellate di opzioni inutili, ma funziona bene, è molto rapido (12 secondi da grub al login prompt della shell) e c’è più o meno tutto quel che serve.

Dopo pochi giorni di test della home condivisa mi sento di sconsigliarla: mi sono capitate diverse corruzioni del filesystem nel giro di pochi giorni che mi hanno costretto ad un intervento da Mac OS X, dato che gli hfsprogs segfaultano su linux a 64 bit. Ho quindi lasciato OS X su una sola partizione (che mi risparmia alcuni mali di testa anche da quel lato) e formattato la nuova home in ext4. La root è rimasta in ext3.

La scheda wireless funziona abbastanza bene con il driver broadcom-wl, che sta in AUR, anche se alcuni (me compreso) segnalano qualche problema con alcune reti WPA.

Le ultime versioni di pommed e gpomme danno supporto pressoché completo ai tasti funzione della tastiera Apple, retroilluminazione compresa. Entrambi i pacchetti sono disponibili, non aggiornati, in AUR, quindi è necessario modificare $pkgver in 1.25 e l’url di download (quanto odio le url non uniformi…) sostituendo il numero 2689 con 2707. Due i bug riscontrati: la retroilluminazione della tastiera, quando azzerata del tutto, torna da sola a circa un terzo e la retroilluminazione dello schermo non funziona in X. Per quest’ultimo problema il workaround, che permette di risparmiare anche 3W, è spostarsi in shell pura e cambiare da lì la retroilluminazione, per poi tornare nella sessione grafica.

A livello di durata della batteria OS X è piuttosto impressionante… supera tranquillamente le cinque ore in caso di utilizzo “leggero” (navigazione su Internet, posta elettronica, editing di documenti). Molti, su Internet, facevano notare la grande differenza sotto linux, che difficilmente superava le tre ore, io ho deciso di vedere fin dove si può arrivare. Un pacman -S powertop mi ha dato un’idea del consumo effettivo, almeno sotto linux. 15W circa. Molto meno del mio vecchio Compal CL56 classe 2004, ma non certo un gran risultato. Oltretutto, scaldava parecchio più che sotto OS X, dove era praticamente freddo. Ho provveduto all’installazione del pacchetto cpufrequtils, e ho impostato conservative come default governor in /etc/conf.d/cpufreq.

Sempre tramite powertop, oltre ad applicare i consigli di default proposti dal programma, mi sono accorto che circa metà degli interrupt dell’intero sistema, 100 al secondo, veniva dal driver della ethernet, forcedeth. Ho così scoperto che, per un bug presente in molti chipset nforce, gli interrupt sui TX devono essere forzati via software. La nostra scheda fa parte della stessa famiglia di chip, e anche se non presenta il bug il kernel la forza ai 100 int/s perché non fa parte della lista di esclusione presente nel sorgente del modulo, forcedeth.c. La patch aggiunge la periferica a questa lista, riducendo non di poco il consumo del laptop.

Dato che comunque tutto questo aiutava a diminuire il calore fino ad un certo punto (compresa la modalità powersave di cpufreq) mi sono detto che OS X doveva fare qualcos’altro al processore. Undervolting? Ho deciso di provarci, e ho aggiunto phc.patch, inserendo in /etc/rc.local un paio di righe per impostare le tensioni al minimo. Pare che non serva a molto, funzionare sembra funzionare, a leggere i valori in /proc, ma non ho notato una grossa differenza di riscaldamento o consumo. Comunque ho tenuto la patch just in case.

Che cosa fa quindi OS X? Magari clock dinamici sulla scheda nVidia. Ho impostato l’opzione CoolBits in xorg.conf e ho cercato di modificare il clock della scheda, prima tramite nvclock, poi con nvidia-settings. Nessuno dei due programmi ha funzionato, nemmeno con i driver nvidia-beta, disponibili in AUR. Probabilmente questo modello non è ancora supportato.

Dal punto di vista riscaldamento/consumi non sono riuscito ad arrivare oltre, ma comunque in idle sono tra i 9 e i 10 Watt, che dovrebbero garantirmi almeno 4 ore e potrebbero superare le 5 in alcuni casi. Non male direi

L’ultima patch che ho applicato (quattro in realtà, bcm5974-[1-4].patch) serve a fornire un buon supporto al trackpad. Con questa patch diventa possibile sfruttare il multitouch fino a quattro dita, esattamente come sotto OS X. Io, da fan del tapping, ho impostato il driver synaptics per fare clic destro su tapping a due dita e clic centrale su tapping a tre dita. La configurazione, in /etc/hal/fdi/policy/11-x11-synaptics.fdi ho inserito le seguenti opzioni, che rendono il trackpad funzionale, anche se un po’ troppo sensibile:

<merge key=”input.x11_options.EmulateMidButtonTime” type=”string”>75</merge>
<merge key=”input.x11_options.HorizTwoFingerScroll” type=”string”>1</merge>
<merge key=”input.x11_options.MaxTapTime” type=”string”>180</merge>
<merge key=”input.x11_options.PalmDetect” type=”string”>True</merge>
<merge key=”input.x11_options.SHMConfig” type=”string”>True</merge>
<merge key=”input.x11_options.TapButton1″ type=”string”>1</merge>
<merge key=”input.x11_options.TapButton2″ type=”string”>3</merge>
<merge key=”input.x11_options.TapButton3″ type=”string”>2</merge>
<merge key=”input.x11_options.VertTwoFingerScroll” type=”string”>1</merge>

Bene. Questo dovrebbe essere più o meno tutto. Ovviamente se qualcuno ha altre proposte o idee sarò felice di testarle e condividerle, ogni commento è bene accetto!

UPDATE: ho pubblicato la seconda parte del post, la trovate qui.

File allegato: moduli e configurazione per il kernel

Poi, la versione di VirtualBox rilasciata ieri ha finalmente aggiunto il supporto per i guest a 64bit su host a 32bit. Questo significa che potrò avere una macchina (virtuale) Arch64 anche sul fisso, senza dovere per forza installare un nuovo sistema in dual boot o rifare da capo la mia installazione corrente.

Spero di cominciare a contribuire presto! =)

1. The PKGBUILD

Long story short, here’s the code, I’ll comment most important choices later on. I’m using eclipse-mylyn as an example.

pkgname=eclipse-mylyn
pkgver=3.0.3
pkgrel=1
pkgdesc="A task-focused interface for Eclipse"
arch=('i686' 'x86_64')
url="http://www.eclipse.org/mylyn/"
license=('EPL')
depends=('eclipse')
optdepends=('bugzilla: ticketing support')
source=(http://download.eclipse.org/tools/mylyn/update/mylyn-${pkgver}-e3.4.zip)
md5sums=('e98cd7ab3c5d5aeb7c32845844f85c22')

build() {
  _dest=${pkgdir}/usr/share/eclipse/dropins/${pkgname/eclipse-}/eclipse

  cd ${srcdir}

  # Features
  find features -type f -name *.jar | while read _feature ; do
    if [[ ${_feature} =~ (.*\.jar$) ]] ; then
      install -dm755 ${_dest}/${_feature%*.jar}
      cd ${_dest}/${_feature/.jar}
      jar xf ${srcdir}/${_feature} || return 1
    else
      install -Dm644 ${_feature} ${_dest}/${_feature}
    fi
  done

  # Plugins
  find plugins -type f | while read _plugin ; do
    install -Dm644 ${_plugin} ${_dest}/${_plugin}
  done
}

2. Package naming and makedepends

Packages should be named eclipse-pluginname, so that they’re recognizable as eclipse-related packages and it’s easy to extract the plugin name with a simple shell substitution like ${pkgname/eclipse-}, not having to resort to the unneded ${_realname} variable. The plugin name is necessary to tidy up everything during installation and avoid conflicts.

I tried using bsdtar instead of unzip to remove the make dependency, but the test was negative: the archives I tried spitted out lots of errors, so I went the easy way. If someone makes it with bsdtar, I’ll be glad to modify the script.
UPDATE: I was noticed that I can directly use jar, which the user already has since it’s part of the JRE. This is great, since it spares a makedepend! However, jar can’t extract to directories other than the current one: this means that, after the directory creation, it’s necessary to cd before extracting. Since there were many occurrences of the destination path I decided to use a custom variable even though somebody might not like it, because there’s a great improvement in readability.

3. File locations

Eclipse 3.4 (Ganymede) introduced a new way of handling plugins: the dropins folder (located in /usr/share/eclipse/dropins). Eclipse scans this folder looking for plugins, and it supports many directory structures. Source archives provide two directories, features and plugins, each one packed up with jar files. The preferred dropins structure should look like this:

/usr/share/eclipse/dropins/pluginname/features/feature1/…
/usr/share/eclipse/dropins/pluginname/features/feature2/…
/usr/share/eclipse/dropins/pluginname/plugins/plugin1.jar
/usr/share/eclipse/dropins/pluginname/plugins/plugin2.jar

This structure allows for mixing different versions of libraries that may be needed by different plugins while being clear about which package owns what. It will also avoid conflicts in case different packages provide the same library. The only alternative would be splitting every package from its libraries, with all the extra fuss it requires, and it wouldn’t even be guaranteed to work because of packages needing older library versions.
Features have to be unjarred since Eclipse won’t detect them otherwise, and the whole plugin installation won’t work. This happens because Eclipse treats update sites and local installations differently (don’t ask me why, it just does).

3. The build() function

First thing to be noticed is the cd ${srcdir} command. Usually source archives extract the features and plugins folders directly under ${srcdir}, but this is not always the case. Anyway, for most non-(de facto)-standard plugins this is the only line that needs to be changed.
Next is the features section. It creates the necessary directories, one for every jar file, and extracts the jar in the corresponding directory. Similarly, the plugins section installs the jar files in their directory. A while cycle is used to prevent funny-named files

4. Conclusions

So here it is. I hope it’s clear why I’m proposing to standardize Eclipse plugins, and why I took certain routes instead of others. I know it looks a bit complicated for a prototype PKGBUILD, but I think it’s the best way to handle all the problems I’ve encountered. Comments, improvements and corrections are, as always, very welcome.

Tutto questo lavoro mi permette, tra l’altro, di liberarmi della nuova build di arduino che mi stava sul groppone da un po’ di tempo… Divertitevi!

Voglio qui chiarificare le cose sul futuro di due PKGBUILD che mantengo in AUR, tcl-devel e tk-devel, che hanno avuto non poco successo principalmente grazie al supporto all’anti-aliasing dei font, che rende aMSN parecchio più guardabile. La versione 8.5 (stabile) è stata finalmente rilasciata, e al momento si trova in [testing], mentre i lavori per la 8.6 (9.0?) non si sono ancora solidificati in una release alpha. Per questa ragione, nel momento in cui tcl e tk passeranno in [extra], i corrispettivi -devel saranno rimossi dall’AUR, in quanto creerebbero più confusione che altro. Vorrei ricordare a quanti mantenessero pacchetti direttamente dipendenti da questi due di preparare delle nuove release che riportino le dipendenze stabili, in modo da evitare casini.

English version:

I want to clarify here the future waiting for a couple of PKGBUILDs I maintain on the AUR, tcl-devel and tk-devel, which had quite a bit of success, mainly thanks to anti-aliased fonts support that makes aMSN a lot nicer. Finally the (stable) 8.5 version has been released, and at the moment it resides in [testing], while works for a new 8.6 (9.0?) still haven’t solidified in an alpha release. For this reason, as tcl and tk reach [extra], the corresponding -devel versions will be removed from the AUR, since they’d just be confusing. I want to remember to those that maintain packages which directly depend on these two to prepare a new release reporting the stable dependency, thus avoiding any mess up.

A fare da colonna sonora a questa follia pacchettica i Mojow and the Vibration Army e mezza discografia degli Estradasphere, nello specifico It’s Understood, Buck Fever e Passion for Life: se gli ultimi dischi mi avevano appassionato i primi si dimostrano a mio avviso decisamente migliori. John Whooley FTW!

Intanto finalmente si avvicina il via libera per far passare gammu da [extra] a [community], così che possa mantenerlo io insieme a python-gammu e wammu: è bastata una mail ad Eric, che ha subito girato la questione in lista sviluppatori e finora i pareri sono favorevoli. Finalmente!