Teoria

L’idea di baste è usare il wiimote come lettore della posizione delle dita, quindi posizionato davanti all’utilizzatore (magari sul monitor) e sistemare dei led ad infrarosso sulle dita dell’utilizzatore.
L’hardware richiesto è composto dal wiimote e da un esoterico intrico di fili e led che vanno sulla mano dell’utilizzatore. (Posterò un immagine quanto prima…)

Per quel che riguarda il software invece quello di cui ho bisogno sono principalmente due componenti:
- un driver per il wiimote a livello kernel.
Si deve occupare di leggere i dati dal wiimote e renderli disponibili al sistema tramite un device file (un file in /dev per intenderci..)
- un driver per il server X.
Deve leggere i dati dal device file, interpretarli e rigirare gli eventi appropriati al server X

Lo stato attuale dell’arte non fornisce nessuno di questi due componenti, quindi il mio lavoro parte da zero.
Per prima cosa mi sono occupato di scrivere un driver per il server X. Partendo da questa ottima guida e spulciando il codice di alcuni driver (mouse, evdev…) sono riuscito a realizzare un driver che legge da un file di dispositivo e muove il puntatore di conseguenza. C’è anche l’emulazione dei tasti del mouse, quindi rimpiazza completamente un mouse.
Per quanto riguarda il driver livello kernel non sono riuscito a mettere insieme neanche un proof of concept ma ho trovato una via alternativa e decisamente non elegante per poter comunque ottenere un risultato usabile.
Quello che al momento si può fare è usare le dita esattamente come un mouse e fare tutto quel che un mouse permette di fare. Sulla mano sono posti 3 led in corrispondenza di 3 dita e devono essere usati così: il led centrale comanda il puntatore, il led sinistro indica click sinistro e il led destro indica click destro. Per simulare un click bisogna tenere  i led fuori dal “campo visivo” del wiimote (ad es. piegando il dito) e mostrarli solo quando si intende cliccare.

Pratica

Come si mettono insieme tutte ste cose e si fa funzionare il tutto?
Questa procedura comporta l’installazione di software in fase di sviluppo ed è altamente sconsigliato eseguirla su un sistema su cui abitualmente si lavora.
Anzitutto serve la versione git di X. Per chi usa gentoo basta digitare

layman -a x11
autounmask x11-base/xorg-server-9999
emerge -av xorg-server

Per chi non usa gentoo un punto di partenza può essere questo.
Ora manca solo il mio software. Si trova qui e su gentoo può essere installato con

cd ~
git clone git://repo.or.cz/Fiinger.git
cd Fiinger
./autogen.sh –prefix=/usr
make
make install (da root o via sudo)

Il driver è installato, ma mancano ancora diverse cose: un device che piloti il driver e una entry in xorg.conf che indichi a X di utilizzare il nuovo driver. Partiamo dalle cose semplici, questa è la sezione relativa da aggiungere a xorg.conf

Section “InputDevice”
Identifier    “Fiinger1″
Driver    “fiinger”
Option    “Device”    “/dev/scullpipe”
EndSection

e non dimenticate di aggiungere anche

InputDevice    “Fiinger1″ “CorePointer”

nella sezione ServerLayout.
Ci siamo quasi, manca solo un driver che gestisca il wiimote. Sfortunatamente non esiste e io non l’ho ancora scritto (e chissà se mai lo scriverò…) ma c’è un “metodo alternativo”. Nella directory Fiinger/apps/ c’è tutto il necessario, ovvero un driver “finto” che si comporta come una pipe e un programma utente che si collega al wiimote e rigira i dati letti al “driver-pipe”.
Il driver è preso dagli esempi del libro “linux device driver 3rd edition” e tutto il merito va agli autori del libro. Il programma utente è scritto da me e usa la libreria wiiuse per interfacciarsi col wiimote.
Vediamo come usare il tutto.
Per prima cosa bisogna compilare e caricare il modulo del driver:

cd ~/Fiinger/apps/kfiinger-module/
make
./scull_load (da root o via sudo)

A questo punto è necessario riavviare il server X in modo che il driver sia caricato e usabile. Potete verificare il successo tramite

xinput list –short

e dovreste vedere una riga del genere:

“Fiinger1″     id=2    [XExtensionPointer]

Ora non resta che lanciare il programma utente e testare l’effettivo funzionamento (o meno) del tutto.

cd ~/Fiinger/apps/wirft
make
./wirft <screen-x-resolution> <screen-y-resolution>

Naturalmente per testare il tutto serve avere un pc bluetooth-enabled, un wiimote, e il famoso “aggeggio”.

Se tutto è andato bene il mouse seguirà le dita!

Appena posso posterò anche un video che mostra il tutto in azione.

[blocks B     ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B     ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2)

Il problema è noto al bug track della gentoo e qui c’è la soluzione (un workaround veramente…)

Quello che ci serve è una cartella in cui conservare il tree alternativo di portage, generalmente si usa /usr/local/portage, quindi, per iniziare ci basterà un

mkdir /usr/local/portage

dopodichè dobbiamo assegnare un nome all’overlay, non obbligatorio ma carino, e poi emerge si lamenta se l’overlay non ha un nome. Per farlo dobbiamo creare la cartella /usr/local/portage/profiles e quindi un file chiamato repo_name contenente il nome del nostro overlay.

mkdir /usr/local/portage/profiles
echo “overlay name” > /usr/local/portage/profiles/repo_name

Ora non ci resta che dire al sistema che esiste un overlay e che vogliamo usarlo, per far questo basta aggiungere la riga

PORTDIR_OVERLAY=”/usr/local/portage”

al file /etc/make.conf

Ora l’overlay è pronto ad ospitare gli ebuild, basta posizionarli seguendo il classico <nome_categoria>/<nome_pacchetto>/<nome_pacchetto>-<versione>.ebuild ed emergerli normalmente.

Ora, il sistema fa già il boot in 33 secondi, quindi i 30 secondi mi sembravano troppo vicini al tempo attuale. In realtà si è rivelato parecchio difficile abbassare questo tempo anche solo di un secondo.

Ma partiamo dall’inizio e vediamo che strumenti abbiamo a dispozione:
app-benchmarks/bootchart – demone che tiene traccia dell’utilizzo di cpu e disco al boot e genera un grafico. è quello che userò per misurare il cambiamento di prestazioni.
sys-apps/readahead-list – un demone che si occupa di leggere anticipatamente dei file dal disco in modo che i processi invocati successivamente si trovino i file necessari già in ram.

Installazione:
Entrambi i programmi sono in portage, quindi basterà un emerge -av per installarli sul sistema.

Configurazione:

Bootchart ha bisogna di essere impostato al boot del sistema come parametro di grub (o lilo), quindi bisogna editare il grub.conf o menu.lst a seconda della versione di grub; ecco un pezzo del mio grub.conf:

title=Gentoo-development-playground-bootcharted
root (hd0,7)
kernel /boot/playground-2.6.27-r1 root=/dev/sda8 vga=0×318 init=/sbin/bootchartd

Bisogna inoltre abilitare bootchart su /etc/conf.d/rc impostando:

# Set to “yes” if you want to benchmark system boot with bootchart.
# You’ll need to emerge the app-benchmarks/bootchart package for this to work.
RC_BOOTCHART=”yes”

Il file di configurazione vero e proprio di bootchart si trova invece su /etc/bootchartd.conf e permette di impostare dove verrà salvato il grafico generato e in che formato.

Readahead ha tre file di configurazione che si trovano in /etc/readahead-list/ e contengono semplicemente una lista di file da (pre)caricare al boot. Naturalmente questa lista di file non è fissa (sopratutto su gentoo) e dipende da quali servizi sono lanciati all’avvio del sistema (quelli nei runlevel boot e default). La configurazione quindi si riduce a creare questa lista. Quella data con il pacchetto è generica e sicuramente non la più adatta; ecco il risultato ottenuto sulla mia macchina con la configurazione originale:

OpenRC parallel boot with readahead-list

Naturalmente non sono soddisfatto di questo risultato, sta sopra i 30 secondi e poi non ho modificato nulla… Vediamo come posso migliorare i file di conf.

Sul bug track della gentoo ho trovato degli utili consigli in proposito. Il primo consiste nel cancellare dai file di config originali tutti i file che non esistono sul sistema in questione, perchè appartenenti a programmi non installati. Ecco come si fa:

a=$(<runlevel-boot ); echo “$a” |xargs ls -1 2>/dev/null > runlevel-boot
a=$(<runlevel-default ); echo “$a” |xargs ls -1 2>/dev/null > runlevel-default
a=$(<exec_sbin_rc ); echo “$a” |xargs ls -1 2>/dev/null > exec_sbin_rc

Ma anche con questo miglioramento non ho ottenuto variazioni nel tempo di boot. Quindi sono andato oltre e ho provato a creare la mia lista di file sempre seguendo i consigli postati in quel bug report. Per ottenere la lista dei file ho usato questo e quest’altro script che generano la lista dei file usati dai servizi impostati allinterno dello script. Per impostare i servizi da monitorare basa editare lo script e aggiungere o togliere i servizi desiderati dalla variabile svc. Quindi ne ho creato due copie, uno con i servizi del runlevel boot e uno coi servizi del runlevel default. Lo script genera tanti file di log e li stampa a schermo concatenati, quindi bisogna redirigere l’output dello script su un file oppure concatenare i vari file di log in un unico file. Fare anche attenzione a eventuale output non correlato ai file aperti dai servizi.I file risultanti però son pieni di nomi duplicati e al momento non ho trovato un modo di elimiare i duplicati senza riordinare i nomi dei file. Riordinando i nomi dei file infatti si perdono i benefici del readahead.

Questo è il grafico del boot con i file di configurazione generati via script:

OpenRC parallel boot with readahead-list configured

E anche stavolta non è cambiato nulla…

Analizzando i grafici, i processi che richiedono più I/O sono HAL, X e python (chiamato in causa da wicd), quindi proviamo ad effettuare il readahead dei file che riguardano solo questi tre servizi. Usando gli stessi script generiamo il file di conf.
Ecco il risultato ottenuto:

OpenRC parallel boot with readahead-list configured with just hald, X and wicd

Anche stavolta nessun miglioramento.

Conclusioni:
Nonostante l’idea che sta dietro readahed-list sia molto buona, il mio processore consuma decisamente più dati di quanti ne possa leggere l’hard disk. Quindi il collo di bottiglia è sempre l’hard disk e, come si vede dal grafico, non c’è mai un momento in cui l’utilizzo della CPU superi l’utilizzo del disco. Mancando questo momento non c’è quindi spazio per readahead-list che dovrebbe leggere dal disco nei momenti in cui esso non è utilizzato.
In definitiva readahed-list può risultare un ottimo tool per processori un po datati, o per pc che abbiamo un disco solid state (verificherò anche questo appena posso); mentre si rivela inutile nel caso di processori dual o quad core. Questo si può comunque determinare con più precisione analizzando il grafico generato da bootchart.

Anzitutto le patch sono 18 ed è previsto che vengano applicate in cascata, quindi volerne applicare una sola che non sia la prima richiede una conoscenza del codice di fvwm che non ho. Quindi le ho applicate tutte, i cambiamenti necessari riguardavano solo percorsi di file sbagliati e file non più esistenti. Ho anche creato un overlay per ospitare il mio ebuild modificato.

La sintassi del file diff (o patch) è questa; abbastanza semplice.

Istruzioni:
Posizionare la patch in /usr/local/portage/x11-wm/fvwm/files.
Modificare l’ebuild di fvwm aggiungendo le varie patch con epatch “percorso_patch” nella funzione src_unpack, per ogni file di patch (rimuovere anche le patch già previste “ufficialmente” dalla gentoo in quanto già incluse). Ricalcolare il digest dell’ebuild e emergere normalmente fvwm.

Patchset modificato

Configurazione:
Apache – come al solito è mio amico e non da mai problemi…
Proftpd – il server è facilmente configurabile, gli utenti hanno già accesso con i dati usuali. é necessario configurare gli account anonimi, ma non mi interessano.
Samba – la configurazione è stata fatta senza grossi dubbi o problemi, ma non ho avuto modo di testarla ancora.
Mysql – Ho installato la configurazione con emerge, ma non ho avuto tempo di smanettare.

questi sono alcuni piccoli tool che uso per abbellire fvwm:
media-gfx/imagemagick
x11-misc/habak
app-admin/conky USE=”hddtemp wifi” + USE=”nvidia” in package.use
x11-misc/transset-df
app-i18n/scim (non ho idea di cosa faccia, controllare)(configura il layout della tastiera, e manco molto bene…)
x11-misc/xcompmgr
x11-misc/trayer
TINT2 (installato a mano, devo creare un ebuild sul mio overlay)
x11-themes/gtk-chtheme

e con i programmi “base” direi che ci siamo; passiamo ai programmi “pesanti”

app-text/epdfview USE=”gtk” (qui sono stato forzato a scegliere tra gtk e qt, per ora gtk, magari qt si aggiunge dopo…)
dev-java/sun-jdk (questo è richiesto da firefox…)
www-client/mozilla-firefox USE=”java xulrunner” (fallito, indagare!!!) (era colpa delle wxwidgets non impostate… risolto!)
net-www/netscape-flash
net-ftp/filezilla
x11-misc/grun
media-gfx/gimp USE=”smp mng”
media-gfx/scrotnet-p2p/qbittorrent (la compilazione fallisce a causa di commoncpp2. Il problema è il bug #236177. é indicata la soluzione.)
app-cdr/graveman USE=”alsa ffmpeg flac ogg dvdr mp3 vorbis” + USE=”amr mmxext ssse3 id3tag” su package.use distribuite tra vari pacchetti.

Da qui in poi sono tutti programmi su cui non ho ancora deciso, perciò passiamo all’installazione e configurazione dei server.

app-admin/system-config-printer (hard masked, “smascherarlo” in seguito)
app-arch/unrar-gpl
app-arch/p7zip
app-arch/unarj
app-arch/arj
app-arch/lha
app-arch/lzop
app-arch/rar
app-arch/unzip
app-arch/zip
app-benchmarks/bootchart (questo servirà solo per riuscire a fare il boot in meno di 30sec)
sys-apps/eject
app-admin/sudo
app-admin/superadduser
www-client/links USE=”fbcon jpeg png tiff svga sdl aalib dga ggi xinerama libcaca imlib”
app-portage/gentoolkit
sys-libs/gpm
sys-apps/gawk
net-analyzer/traceroute
net-analyzer/nmap USE=”-gtk” in package.use (lo uso solo da commandline)
sys-power/cpufrequtils
sys-apps/dbus
app-misc/hal USE=”acpi laptop networkmanager”
sys-power/acpid
app-portage/cfg-update
dev-util/xxdiff (questo ha tirato in ballo le qt3)
net-wireless/ipw3945 (questo è stato problematico)
x11-base/xorg-x11 USE=”hal X xprint”

media-sound/alsa-utils
media-video/linux-uvc

dev-util/strace
sys-process/lsof

Una volta arrivati ad X inizia il grosso del lavoro.
Prima però ci va un emerge -DuN world per uniformare le USE flag fra i programmi installati.
Spazio occupato finora: 3Gb~

CFLAGS=”-march=core2 -mmmx -msse -msse2 -msse3 -mssse3 -O2 -pipe”
CXXFLAGS=”${CFLAGS}”
MAKEOPTS=”-j3″
CHOST=”x86_64-pc-linux-gnu
ACCEPT_KEYWORDS=”~amd64″

analizzandole:
-march: rappresenta il tipo di processore, il valore core2 corrisponde al mio processore, si può usare solo con gcc >= 4.3.2. Questo implica che per ora userò la keyword ~amd64 per abilitare i pacchetti “instabili”
-mmmx e -m(s)sse*: abilitano le feature mmx e (s)sse del processore.
-O2: ottimizzazione livello 2, buono ma non estremo (instabile)
-pipe: le fasi di compilazione comunicano tramite pipe, incrementa la velocità (generalmente…)
Stessa cosa per le cxx flags.
L’opzione MAKEOPTS è impostata a 3 perchè il core2 ha due cpu, quindi num_cpu+1 = 3

Le altre modifiche fatte al file sono:

USE=”mmx sse sse2″
LINGUAS=”en”
VIDEO_CARDS=”nvidia”
INPUT_DEVICES=”evdev keyboard mouse synaptics”

e si spiegano da sole, a parte la USE che ancora deve essere impostata, ma merita un discorso a parte…
Prima occupiamoci di compilare il kernel, sempre seguendo l’handbook.
Una volta effettuato il chroot cambiamo profilo e mettiamo il no-multilib con

ln -snf /usr/portage/profiles/default/linux/amd64/2008.0/no-multilib /etc/make.profile

vediamo che danni ci porterà un profilo pure 64bit.
Danni ne sono arrivati parecchi… Tra i più gravi: manca una versione funzionante di flash (gnash funziona, ma la CPU schizza alle stelle); wine e skype non possono essere installati. Motivi sufficienti a farmi ritenere che il mondo pure 64 non sia ancora pronto. Cambio profilo in developer. Si fa tramite eselect profile

Vai col kernel e giù fino ai tool di sistema.
Per ora voglio syslog-ng, logrotate, vixie-cron e slocate.
Non ho ancora modificato la USE di default perchè non ce stato bisogno di farlo al momento.

Ricapitolando: ho un sistema base ma ho saltato il passaggio del bootloader e mi manca un client dhcp wire(d|less)