Skype e microfono muto

Per poter essere uditi dagli interlocutori Skype durante una conversazione, occorre accedere al mixer audio preferito ( kmix o similari ), ed attivare, tra i dispositivi di ingresso, non solo il microfono, ma anche il capture. Quest'ultimo controllo è fondamentale, perchè altrimenti anche con il micro al massimo l'audio non lascia il computer. Il livello di capturing deve essere messo al massimo, e deve essere attivata l'opzione di registrazione.

Un altro interruttore che è utile attivare per le conversazioni Skype è il mic boost, che amplifica di 20 DB il segnale microfonico, rendendo la voce ancora più comprensibile al proprio interlocutore. In caso di attivazione di tale switch, è bene non tenere al massimo il controllo del microfono, per evitare effetti di rimbombo e di innesco sulle casse del laptop.

Inoltre, è fondamentale che Skype parta dopo il mixer in uso. Almeno sulla mia macchina, se Skype parte prima di Kmix gli interlocutori non sentono nulla anche attivando correttamente i controlli suddetti.

Gestione dell'energia con ACPI

Fedora consente di gestire l'energia del laptop Toshiba attraverso APM e ACPI. Tuttavia, ACPI ( Advanced Configuration and Power Interface ) è pienamente supportato dal kernel Fedora, ed è inoltre una specifica nativa Toshiba, nel senso che Toshiba è una delle case promotrici di tale standard, quindi rappresenta una scelta quasi naturale nella gestione dell'energia del laptop.

Attivare ACPI come servizio al boot della macchina, al posto di APM, potrebbe comunque non bastare, perchè non sono nuove situazioni nelle quali la macchina, a seguito di un resume, non funziona appropriatamente: blank screen, audio muto, ecc.

La modalità che ho scelto per la gestione tramite ACPI della sospensione e del riavvio del sistema è per ora legata solamente alla sospensione su RAM ( stand-by ). Opzioni quali la sospensione su disco o l'ibernazione completa non sono ancora state provate; in particolare, l'ibernazione richiede moduli software aggiuntivi.

La sospensione viene realizzata semplicemente chiudendo il portatile; riaprendolo, il sistema riparte automaticamente. Non faccio uso delle opzioni messe a disposizione dal modulo KDE Klaptop, non perchè esse non funzionino, ma perchè occorre una impostazione specifica che al momento non mi occorre. E' molto semplice chiudere il portatile ed attivare lo stand-by, e riaprirlo, attivando automaticamente il resume.

Per ottenere questo risultato, da utente root, seguire i passi seguenti.

Nella directory /etc/acpi/actions, inserire il file lid.sh e attivare i permessi di esecuzione. Il file avrà questo contenuto:

#!/bin/sh
/path/to/suspend.sh

dove /path/to va sostituito con il percorso assoluto dello script shell che si occupa della sospensione e della riattivazione del sistema. Un esempio è stato inserito sotto.

Nella directory /etc/acpi/events, inserire il file lid. Il file avrà questo contenuto:

event=button[ /]lid.*
action=/etc/acpi/actions/lid.sh

Questo file determina quale script verrà eseguito alla chiusura del portatile, nel nostro caso lid.sh, che a sua volta invocherà [..]/suspend.sh.

Questo è il file suspend.sh nella mia macchina:

#!/bin/sh

# discover video card's ID
ID=`lspci | grep VGA | awk '{ print $1 }' | sed -e 's@0000:@@' -e 's@:@/@'`

# securely create a temporary file
#TMP_FILE=`mktemp /var/tmp/video_state.XXXXXX`
TMP_FILE=`mktemp /tmp/video_state.XXXXXX`
trap 'rm -f $TMP_FILE' 0 1 15

# switch to virtual terminal 1 to avoid graphics
# corruption in X
chvt 1

# write all unwritten data (just in case)
sync

# dump current data from the video card to the
# temporary file
cat /proc/bus/pci/$ID > $TMP_FILE

# Arresto il network prima del suspend
/etc/init.d/network stop

# Evito che ALSA si inchiodi al resume
amixer -c 0 sset Master mute

# suspend
echo -n mem > /sys/power/state

# restore video card data from the temporary file
# on resume
cat $TMP_FILE > /proc/bus/pci/$ID

# switch back to virtual terminal 7 (running X)
chvt 7

# Riabilito ALSA
amixer -c 0 sset Master unmute

# Riattivo il network dopo il suspend
/etc/init.d/network start

# remove temporary file
rm -f $TMP_FILE

Naturalmente, il file deve avere i permessi di esecuzione.

Questo script gestisce appropriatamente lo schermo, ed evita il blank screen se si chiude il portatile in ambiente X. In ambiente console, occorre riattivare la console con [CTRL] [ALT] [Fx], dove x sta per la console desiderata.

Lo script, che è stato prelevato da questo ottimo articolo assieme ai passi per attivare il supporto ACPI in modalità minimale di stand-by, è stato arricchito da alcune operazioni ( evidenziate in verde ) volte a sospendere e ripristinare correttamente l'intero sistema.

In particolare, prima della sospensione vengono disattivate tutte le interfacce di rete correntemente attive, e viene disattivato il Master control di ALSA, in quanto la sospensione del sistema ( con ALSA come layer sonoro ) blocca ALSA alla riattivazione, disattivando conseguentemente l'audio. Dato che Fedora non ha ( nella release 5 e superiori ) sistemi semplici di riattivazione di ALSA senza effettuare un reboot, l'inserimento di questa semplice sequenza di comandi sembra riattivare correttamente il supporto sonoro. Grazie alle informazioni presenti in questo articolo, e ai files gentilmente messi a disposizione dall'autore, è stato possibile arrivare a questa soluzione.

La riattivazione delle interfacce di rete, necessaria alla mia specifica configurazione, viene effettuata invece automaticamente dallo script.

Flash plugin per Firefox non visualizza tutti i Font

In attesa del nuovo plugin Adobe Flash per Linux, l'attuale versione del plugin Adobe Macromedia Flash per Firefox ( 7.x ) presenta un inconveniente di visualizzazione di caratteri, dovuto all'ambiente di sviluppo del plugin stesso.

Può infatti capitare che un oggetto Flash caricato nell'environment Firefox non visualizzi nessun carattere al suo interno, o solamente una parte.

Per risolvere questo problema, agire come riportato su questa pagina . In pratica, il codice da inserire come utente root da terminale è questo:

[root> ~]# mkdir -p /usr/X11R6/lib/X11
[root> ~]# cd /usr/X11R6/lib/X11
[root> X11]# ln -s /etc/X11/fs
[root> X11]# ln -s /usr/share/X11/fonts

Al termine di queste semplici operazioni, il plugin Flash dovrebbe essere in grado di visualizzare immediatamente i caratteri che prima non venivano visualizzati.

Grazie a tutte le persone che nei vari blog hanno contribuito a diffondere questa (pseudo)patch.

Aprire Mozilla Firefox sempre massimizzato

Il browser Mozilla Firefox salva in chiusura le impostazioni della dimensione della finestra, in modo da riaprirsi la volta successiva nello stesso modo.

Tale comportamento, memorizzato nel file localstore.rdf all'interno dei file personali di Firefox nella cartella $HOME, può diventare un problema, nel momento in cui alcuni siti Internet aprono al click su alcuni loro collegamenti nuove finestre di navigazione e le ridimensionano a grandezze precise. Se Firefox viene chiuso con queste finestre ancora attive, può prendere come dimensione di default quella della finestra ridimensionata, ed il risultato diventa che ogni volta che si apre Firefox, poi occorre massimizzarlo con un nuovo click sul pulsante di massimizzazione.

Per fare sì che Mozilla Firefox si apra sempre massimizzato, occorre:

• Attivare il browser.
• Massimizzare la finestra senza aprire alcun collegamento, nemmeno in una nuova scheda.
• Chiudere il browser.

Questo dovrebbe permettere, da quel momento in poi, l'apertura di Firefox sempre in finestra massimizzata. Ripetere quando necessario queste semplici operazioni, in caso di perdita di questa impostazione.

Nvidia kernel driver per scheda GeForce4 420 GO

Il laptop Toshiba Satellite 1410-604 monta una scheda grafica Nvidia GeForce4 420GO, perfettamente utilizzabile all'interno dell'ambiente Fedora, in particolar modo nei desktop grafici, quali KDE, il mio preferito attualmente.

I driver nativi messi a disposizione dal kernel per questa scheda funzionano relativamente bene, se non si hanno particolari necessità grafiche, quali accelerazioni 3D o similari. Tuttavia, il driver nativo del kernel ( quello per intenderci marcato 'nv' nel file di configurazione di Xorg ) si comporta in maniera leggermente antipatica quando opera, sotto KDE, con le applicazioni della suite Mozilla, cioè Firefox e Thunderbird: alcuni caratteri, quando impostati con una particolare risoluzione, letteralmente spariscono dallo schermo, riapparendo solo se selezionati, o allo scrolling della pagina. Un comportamento che può essere davvero noioso, perchè in alcuni siti web interi paragrafi possono venire omessi del tutto, riapparendo come per magilla solo se si seleziona la pagina, o se si scrolla la stessa.

Questo noioso problema viene risolto installando il kernel nativo Nvidia, già opportunamente compilato e configurato come pacchetto pronto all'installazione, utilizzandolo al posto di quello nativo del kernel. Questo permetterà di utilizzare a piena potenza la scheda grafica in questione, potendo contare su una marea di settaggi disponibili.

Ecco come procedere per installare i moduli kernel nativi Nvidia a bordo del sistema. Solita premessa: le operazioni che seguono, che hanno funzionato nel mio ambiente, sono vostra decisione eseguirle e vostra responsabilità in toto negli esiti.

- Da utente root, e partendo da una console e non da un terminale grafico, installare via yum i pacchetti:

- kmod-nvidia
- xorg-x11-drv-nvidia

I pacchetti in questione potrebbero essere correlati tra loro da dipendenze, non ricordo bene, quindi potrebbe bastare installare il primo di essi. Assicuratevi comunque al termine dell'operazione che entrambi i pacchetti siano a bordo.

- FONDAMENTALE: per attivare X correttamente con i nuovi driver, nel file /etc/modprobe.conf occorre inserire questa riga:

options nvidia NVreg_SoftEDIDs=0 NVreg_Mobile=1 NVreg_FlatPanelMode=1

Una di queste impostazioni permette al modulo nvidia caricato dal kernel di funzionare a bordo del laptop quando X viene attivato. Non so quale di esse sia quella fondamentale, ma so che senza questa riga X si pianta in attivazione con un blank screen.
Uno dei forum Fedora è la fonte di questa preziosa informazione. Cercando su Internet possono trovarsi maggiori dettagli in merito.

- Modificare il file /etc/X11/xorg.conf ( fate prima una copia di backup di sicurezza, mi raccomando!! ), cioè il file di configurazione di X, attivando il driver appena installato. Nella sezione "Files" inserire:

ModulePath "/usr/lib/xorg/modules/extensions/nvidia"

La sezione "Device" dovrebbe essere simile a questa:

Section "Device"

Identifier "Videocard0"
Driver "nvidia"
VendorName "Videocard vendor"
BoardName "nVidia Corporation NV17 [GeForce4 420 Go]"
Option "UseEDID" "FALSE" #EDID still not reading properly
Option "ModeValidation" "NoMaxPClkCheck,NoEdidMaxPClkCheck"
Option "ExactModeTimingsDVI" "1"
Option "IgnoreDisplayDevices" "TV"
Option "DPMS"
Option "BackingStore" "1"
Option "nvAGP" "1"
Option "NoLogo" "true"
Option "MultisampleCompatibility" "1"
Option "RenderAccel" "1" #works
Option "AllowGLXWithComposite" "1"

EndSection

Section "Screen"

Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"

Viewport 0 0
Depth 24
Modes "1024x768" "800x600" "640x480"

EndSubSection

EndSection

Section "Extensions"

Option "Composite" "Enable" #works
Option "RENDER" "Enable" #works
Option "DAMAGE" "Enable" #works
Option "XFIXES" "Enable" #works

EndSection

Naturalmente, sia la sezione "Driver" che quella "Screen" devono andare a sostituire quelle preesistenti. Queste impostazioni sono state prelevate da un esempio di configurazione di X trovato sulla rete, e comunque funzionano senza problemi. Tuttavia, se si ha la necessità di utilizzare a fondo la scheda grafica, o di personalizzare nel dettaglio il comportamento della stessa, è bene scaricare la documentazione ufficiale dal sito nvidia.com e studiarla con attenzione, settando con attenzione le singole impostazioni.

Effettuando il reboot del sistema si scopre che il modulo kernel Nvidia viene attivato insieme agli altri servizi della macchina, e, se tutto è andato bene, X si attiverà correttamente con il nuovo driver Nvidia, veloce, efficiente, e con la suite Mozilla finalmente senza strani behaviour.

I pacchetti software Nvidia installati mettono a disposizione degli utenti anche una serie di utility attivabili via console ed un tool grafico di management all'interno del desktop grafico in utilizzo. Su KDE, si trova nel menu Sistema, e si chiama Nvidia Display Settings. Attraverso di esso, si possono impostare molti dei comportamenti della scheda grafica senza intervenire direttamente nel file di configurazione di X. Le utility via console, invece, posseggono tutte il prefisso nvidia- , e servono essenzialmente a gestire la scheda e ad impostare il file di configurazione di X in maniera minimale ed automatica per il funzionamento con il nuovo driver: cose che comunque possono essere fatte anche direttamente sul file di configurazione o attraverso il tool di management grafico.

Buon lavoro!

Livna: un repository per i pacchetti extras

I repository utilizzati da yum per gli aggiornamenti e le installazioni dei pacchetti software non contengono, per varie ragioni legate anche a motivazioni di copyright ( vedi supporto al formato audio mp3 ), tutto quell'universo di software open raggruppato sotto il generico nome di 'extras'.

Naturalmente, yum può essere istruito ad utilizzare anche altri repository, oltre a quelli di default. Un repository che è senz'altro opportuno inserire nella lista di quelli utilizzati per la gestione del software installato è quello di Livna.

L'indirizzo di Livna è http://rpm.livna.org/ , ed è bene visitarlo, per trovare utili informazioni e per effettuare la corretta installazione delle informazioni di repository, legata alla distro Linux Fedora in utilizzo.

Una volta installato il repository, si avranno a disposizione migliaia di software pronti all'uso, buona parte dei quali non è presente negli insiemi base dei pacchetti di Fedora. Kernel drivers e moduli, pacchetti multimedia, estensioni di supporto non propriamente free, rientrano tutti nel set di software che Livna mette a disposizione.

Ricostruzione del DB repository dei pacchetti rpm a seguito di un rpmdb PANIC

Durante l'esecuzione del software per la gestione dei pacchetti installati a bordo del sistema ( yum ), può accadere che si corrompa il DB utilizzato per il mantenimento delle informazioni sui pacchetti installati.

In tale circostanza, qualsiasi esecuzione del comando yum o suoi derivati, così come l'esecuzione del comando a cui yum si interfaccia, cioè il ben noto rpm, può produrre un output come questo:

rpmdb: PANIC: Invalid argument
rpmdb: PANIC: fatal region error detected; run recovery
error: db4 error(-30977) from dbcursor->c_put: DB_RUNRECOVERY: Fatal error, run database recovery
error: error(-30977) storing record into Requireversion
rpmdb: PANIC: fatal region error detected; run recovery
error: db4 error(-30977) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run database recovery

ripetuto più e più volte.

Il Forum di Fedora on Line ci viene incontro con una soluzione possibile. Si tratta in pratica di eliminare alcuni file dalla directory in cui risiedono fisicamente i dati del DB dei pacchetti installati, e di rigenerare conseguentemente il DB ex-novo. La soluzione è stata testata ed è funzionante.

Da utente root:

- Eseguire il comando rm -f /var/lib/rpm/__db*, oppure, per sicurezza, muovere tutti i file __db* nella cartella /var/lib/rpm in una estensione di sicurezza, per esempio .old oppure .orig.

- Eseguire il comando rpm --rebuilddb

Naturalmente, l'esecuzione di questi comandi è vostra decisione e vostra responsabilità, ma se prendete le necessarie precauzioni, non dovrebbero esserci problemi. A bordo del mio sistema, a seguito di questo problema, questa semplice sequenza di comandi ha permesso di ritornare al funzionamento corretto.