follow me on Twitter

    DualHead e Gnome workarounds

    Questa settimana mi sono cimentato involontariamente nella configurazione del DualHead sulla mia GNU/Linux Box ;-)

    Il DualHead è una modalità di funzionamento dell’interfaccia grafica coadiuvato dalla capacità della scheda video di gestire più periferiche di output contemporaneamente (ad esempio l’ LCD e l’uscita VGA di un portatile).

    Precedentemente questa modalità di funzionamento era supportata da XWindows mediante un estensione chiamata Xinerama.

    Ultimamente la funzionalità di DualHead è invece integrata nel modulo XRandr che è in grado di selezionare al volo la risoluzione grafica delle schede video e anche di attivare le schede video secondarie senza necessità di riavvio di XWindows (necessaria invece con Xinerama essendo configurata staticamente nel file di configurazione di Xorg)

    XRandr, con la possibilità di riconfigurazione live, è un grande passo in avanti per Xorg… ma come tutte le cose nuove introduce anche nuovi problemi :-D

    La modalità DualHead è sicuramente utile per lavorare su più applicazioni contemporaneamente ma è ancora più utile durante presentazioni e seminari, permettendo di eseguire su uno schermo (il proiettore agganciato all’uscita VGA) la presentazione e sull’altro (l’LCD del portatile) la scaletta/mindmap della presentazione, magari con le note riguardanti i dettagli importanti da non dimenticare :-)

    Ho provato ultimamente a configurare il DualHead in una modalità diversa dalla modalità mirror (che semplicemente clona i due output mostrando su entrambi il medesimo desktop) e ho avuto qualche problemino dovuto probabilmente alla non completa integrazione del nuovo sistema XRandr nella applicazioni e desktop environment (nel mio caso GNOME).

    Nel cercare dei workaround a questi problemi ne ho comunque tratto una conoscienza migliore dei meccanismi e delle tecnologie coinvolte e ho deciso quindi di lasciare queste 4 righe di traccia a beneficio di chi potrebbe incontrare i miei stessi problemi ;-)

    Le ultime versioni Ubuntu (e quindi molto probabilmente anche molte altre distribuzioni) integrano un sistema guidato di riconfigurazione degli output video:

    • gnome-display-properties (compreso nel pacchetto gnome-control-center

    Tra l’altro ci deve fare piacere il fatto che tra i contributor c’e’ un cittadino di adozione leccese ;-) (Alberto Milone) che ha contribuito, tra le altre cose, all’integrazione con X-Kit (di cui ne è autore) per automatizzare quelle procedure che richiedono ancora la configurazione di Xorg attraverso il suo file di configurazione statico.

    Ad esempio una configurazione che fa a finire nel file di configurazione /etc/X11/xorg.conf è la risoluzione virtuale totale (cioè la superficie virtuale che verrà spezzettata tra i vari output reali):

    Section "Screen" 
      Identifier "Default Screen" 
      Device "Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller" 
      Monitor "LVDS" 
      DefaultDepth 24 
      SubSection "Display" 
        Depth 24 
        Modes "1280x768" "1024x768" "800x600" "640x480" 
        Virtual 1280 1536 
      EndSubSection 
    EndSection 
    

    Queste modifiche verranno effettuate in maniera completamente trasparente grazie alla collaborazione tra gnome-display-properties, screen-resoluzion-extras, X-Kit e PolicyKit

    Il lavoro di fino degli ultimi anni di freedesktop e dei team di sviluppo di gnome e delle varie distribuzioni stanno finalmente dando i loro primi frutti ;-)

    BUG

    Tutto ha funzionato perfettamente… o quasi… di ritorno dal suspend il tool gnome-display-properties fallisce silenziosamente e non ho avuto ancora la possibilità di approfondire il problema :-(

    Beh… poco male… in ogni caso xrandr è sempre li pronto a servirci attraverso la nostra linea di comando :-D

    Ma rimane comunque un problema troppo fastidioso per essere ignorato:

    i pannelli gnome finiscono nel primo monitor… che per qualche oscuro motivo (almeno sul mio laptop, un Latitude X1) non è l’LCD del laptop ma il monitor esterno…

    … perfetto… il mio obiettivo era ottenere esattamente il comportamento contrario :-(

    Use the Zen: circoscrivere il problema

    In questo caso mi è sembrato naturale pensare che il problema non poteva che risiedere dentro gnome… così prima di andare a guardare i sorgenti o pensato fosse il caso di dare una sbirciata alle chiavi di configurazione GConf con gconf-editor

    Ed eccolo li… è bastato cercare tutte le chiavi di configurazioni contenenti il termine monitor per identificare una chiave interessante /apps/panel/toplevels/panel_0/monitor

    Un rapito test al volo ha dimostrato che semplicemente cambiando la chiave (al volo visto che viene automaticamente ridefinita in caso di assenza del monitor VGA) sposta il pannello sul monitor che preferiamo :-PPPPP

    WORKAROUND

    Dopo aver circoscritto il problema è bastato impacchettare il workaround in un mini-script bash:

    xrandr --output VGA --mode 1024x768 --pos 0x0 --output LVDS  --mode 1280x768 --pos 0x768
    
    gconftool --type int --set /apps/panel/toplevels/panel_0/monitor "1"
    gconftool --type int --set /apps/panel/toplevels/panel_1/monitor "1"
    

    Ohhh… now it’s work!!!

    Happy dualhead, rpl

    OpenWRT snapshot by night

    Dovendo ricondizionare ( :-P ) una fonera per un amico ho deciso di provare questo famigerato tool "AP51 Easy Flash" che automatizza completamente la procedura (rootfs, kernel):
    
    rpl@ubik:~/Works/fon2200$ sudo ./ap51-flash-fonera-1.0-38 eth0 \
     openwrt-atheros-2.6-root.jffs2-64k openwrt-atheros-2.6-vmlinux.lzma
    Reading rootfs file openwrt-atheros-2.6-root.jffs2-64k with 1835008 bytes...
    Reading kernel file openwrt-atheros-2.6-vmlinux.lzma with 786432 bytes...
    rootfs(0x006e0000) + kernel(0x000c0000) + nvram(0x00000000) sums up to 0x007a0000 bytes
    Non arp received. Make sure, the device is connected directly!
    Peer MAC: 00:18:84:81:5d:9c
    Peer IP : 192.168.1.1
    Your MAC: 00:ba:be:ca:ff:ee
    Your IP : 192.168.1.0
    Setting IP address...
    Loading rootfs...
    Sending rootfs, 3584 blocks...
    Initializing partitions...
    Rootfs partition size now 0x006f0000
    Flashing rootfs...
    Loading kernel...
    Sending kernel, 1536 blocks...
    Flashing kernel...
    Setting boot_script_data...
    Done. Restarting device...
    
    Miiiii che noia fa praticamente tutto lui :-(

    Vi toglie tutta l'emozione e il divertimento... come vedere un film conoscendone già il finale :-(((

    tra l'altro la seconda revisione della fonera (FON2200) ha già redboot attivo e quindi non è nemmeno necessario utilizzare hack per aprire ssh, cambiare kernel etc. etc. :-'(

    Se è la vostra "prima volta" vi consiglio caldamente la procedura manuale (http://wiki.ninux.org/LaFoneraDallaScatolaAOpenWrt), molto più divertente :-D

    beh... cosa vedo li sulla porta 80? webif installato di default... diamogli un occhiata, mai provato prima...
    ...
    http://192.168.1.1/
    ...
    Network
    ...
    Host
    ... SBAM
    
    /bin/sh: nvram: not found
    /bin/sh: nvram: not found
    /bin/sh: nvram: not found
    /bin/sh: nvram: not found
    /bin/sh: nvram: not found
    /bin/sh: nvram: not found
    /bin/sh: nvram: not found
    /bin/sh: nvram: not found
    /bin/sh: nvram: not found
    /bin/sh: nvram: not found
    Content-Type: text/html; charset=UTF-8
    Pragma: no-cache
    
    ...
    
    <div class="warning">WARNING: This page has not been updated or
    checked for correct functionality under Kamikaze.</div>
    ...
    
    Miiii... funziona bene ;-)
    al secondo menù ho già beccato una pagina non funzionante?

    aggiorniamo? aggiorniamo!
    magari prima dovremmo correggere i repository?!?!??!
    st'immagine fa proprio... beh il "bello" degli snapshot è l'emozione ;-)
    
    #src snapshots http://downloads.openwrt.org/snapshots/atheros-2.6/packages
    src snapshots src snapshots http://ipkg.k1k2.de/packages/
    src packages http://downloads.openwrt.org/kamikaze/packages/mips
    dest root /
    dest ram /tmp
    src X-Wrt http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages
    
    ORA aggiorniamo:
    
    root@OpenWrt:/etc# ipkg update
    Downloading http://ipkg.k1k2.de/packages//Packages
    Updated list of available packages in /usr/lib/ipkg/lists/snapshots
    Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
    Updated list of available packages in /usr/lib/ipkg/lists/packages
    Downloading http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages
    Updated list of available packages in /usr/lib/ipkg/lists/X-Wrt
    Done.
    root@OpenWrt:/etc# ipkg upgrade
    Upgrading busybox on root from 1.4.2-3 to 1.8.2-1...
    Downloading http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/./busybox_1.8.2-1_mips.ipk
    ipkg: fork failed: Cannot allocate memory
    
    scusa scusa... faccio fuori qualcosa?... httpd?
    
    root@OpenWrt:/etc# /etc/init.d/httpd stop
    Terminated 
    insisti insisti che alla fine ce la farà...
    
    root@OpenWrt:/etc# ipkg upgrade
    ....
    root@OpenWrt:/etc# ipkg upgrade
    ....
    root@OpenWrt:/etc# ipkg upgrade webif
    
    
    ohhh.... facciamo ripartire httpd:
    
    root@OpenWrt:/etc# /etc/init.d/httpd start
    /etc/rc.common: eval: line 1: uci_set_default: not found
    
    ti piacerebbe!!!
    googla di qua e googla di la mi sa che il nuovo webif fa uso di funzionalità inserite nei nuovi uci e base-files (https://dev.openwrt.org/changeset/10086)...

    Aggiorniamo?.... beh...
    
    root@OpenWrt:~# ipkg upgrade uci
    Installing uci (0.3.0-1) to root...
    Downloading http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/./uci_0.3.0-1_mips.ipk
    Installing libuci (0.3.0-1) to root...
    Downloading http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/./libuci_0.3.0-1_mips.ipk
    Configuring libuci
    Done.
    Collected errors:
    Package uci wants to install file /lib/config/uci.sh
           But that file is already provided by package base-files-atheros-2.6
    
    prego prego sovrascrivi:
    
    root@OpenWrt:~# ipkg upgrade uci -force-overwrite 
    Installing uci (0.3.0-1) to root...
    Downloading http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/./uci_0.3.0-1_mips.ipk
    Configuring uci
    Done.
    root@OpenWrt:~#
    
    e ora il passo delicato (della serie "attento a cosa sovrascrivi e fare un diff non fa mai male"):
    
    root@OpenWrt:~# ipkg install base-files-atheros -force-overwrite
    ....
       Configuration file '/etc/passwd'
       ==> File on system created by you or by a script.
       ==> File also in package provided by package maintainer.
          What would you like to do about it ?  Your options are:
           Y or I  : install the package maintainer's version
           N or O  : keep your currently-installed version
             D     : show the differences between the versions (if diff is installed)
        The default action is to keep your current version.
       *** passwd (Y/I/N/O/D) [default=N] ?n
    
    
    ed ora?
    
    root@OpenWrt:~# /etc/init.d/httpd start
    root@OpenWrt:~# 
    
    ohhhh... riproviamo:
    ...
    http://192.168.1.1/
    ...
    Network
    ...
    Host
    ...
    NOW IT'S WORK ;-)

    Live in the Shell #1: ripetere un comando su una lista di file

    Spesso mi è capitato durante la normale manutenzione della mia home, delle directory di building o durante interventi sistemistici vari, di dover ripetere un task su una lista di file. Di solito utilizzo spontaneamente l'approccio da coder:
    
    rpl@ubik:~$  LIST=`find -iname "*~"`
    rpl@ubik:~$  for i in $LIST; echo $i; done
    [...]
    
    
    Il che non è sbagliato... funziona... Ma il bello del lavorare in team è lo scambio di abitudini e conoscenze continuo e naturale, e oggi Domenico M. mi ha fatto notare che c'e' un modo più compatto e sistemistico per svolgere lo stessa operazione:
    
    rpl@ubik:~$  find -iname "*~" -exec echo '{}' \;
    
    
    Ma il bello è che ce ne sarebbe ancora un'altra (e chissa quante altre):
    
    rpl@ubik:~$ find -iname "*~" | xargs echo
    
    
    e allora quale usare? beh... de gustibus. Il primo metodo è un for vero e proprio e si puo' utilizzare in generale con ogni stringa che contenga un elenco di elementi separati da spazi, gli altri sono sicuramente più manegevoli quando la lista andrebbe comunque generata con un find ;-)
    View Luca Greco"s profile on LinkedIn

    Rpl

    La mia foto
    Lecce, Italy
    Fulltime Coder and *nix BOFH