Nouveau e i freeze di Xubuntu 14.04

Di recente ho avuto problemi con due differenti PC aventi entrambi Xubuntu e una scheda Nvidia. Il primo è il mio PC fisso di casa, ormai con qualche annetto, e recentemente è stato aggiornato a Xubuntu 14.04. Va perfettamente, alla faccia dell’obsoleto Windows XP con cui era nato. L’altro è un PC di GrappaLUG, sempre con Xubuntu peraltro reinstallato di recente.

I due hanno manifestato dei fenomeni comuni, come ad esempio:

  • blocco “casuale” del sistema
  • schermata nera al posto del salvaschermo (xscreensaver), da cui non si riesce a uscire
  • a volte neppure la linea di comando va e il sistema è in stallo totale

Entrambi i PC erano configurati con il driver libero Nouveau (che fino alla 13.10 funzionava benissimo) e soffrivano molto meno dei problemi se avviati col parametro nomodeset al boot. Peccato però che tale parametro riduca di gran lunga le risoluzioni disponibili. 😛

Gestione dei driver video su Xubuntu 14.04
Gestione dei driver video su Xubuntu 14.04

Alla fine ho dovuto cedere al fatto che usando il driver proprietario Nvidia il mio PC di casa ha ripreso a funzionare senza problemi. L’unica pecca è che la schermata di avvio col logo colorato viene rimpiazzata da una schermata nera con il logo testuale, di pessimo gusto. 😀

L’altro PC purtroppo non ho ancora potuto sistemarlo, ma dati i sintomi direi che la soluzione sarà analoga. 😉

Anche a voi sono capitati problemi con l’ultima Xubuntu e le schede Nvidia? O magari su altre distribuzioni? Fatemi sapere!

Annunci

Importanti aggiornamenti per la visione e il download dei video da Rai.tv

Mi sono già lamentato numerose volte di quanto il sito Rai.tv sia un disastro di incoerenze multiple, in cui più o meno ogni video viene inserito con metodi leggermente diversi e trovare i link per scaricarli è un procedimento abbastanza arzigogolato. Due esempi di “inutile complicazione” che il mio script non riusciva a gestire sono i seguenti, dovuti al fatto che il sito Rai “dichiara” il tipo di video nella pagina, in modo totalmente a caso, a volte.

  • I video di «Chi l’ha visto», tipo questo — nel codice manca il riferimento al video in formato MP4, ma viene indicato doppiamente lo stesso URL al video, inclusa la variabile videourl_wmv, ed estensioneVideo e MediaItem.type sono impostate ad indicare il formato WMV… peccato che il video sia un file MP4
  • Questa puntata de «I migliori Anni» — è letteramente la fiera dell’incoerenza: MediaItem.type fa riferimento al formato WMV, estensioneVideo indica CSM ma il file è di tipo MP4

Ora, a parte il fatto che anche un ragazzino di 13 anni saprebbe sviluppare il sito in modo più coerente e sensato, capite bene che questa tragedia di informazioni contraddittorie creava serie difficoltà al mio script che cercava di capire che tipo di video c’era sotto e come gestirlo.

Oggi ho rianalizzato la questione e ho inserito ulteriori controlli per aggirare questi problemi. In particolare, se il sito fornisce un esplicito URL al file MP4 posso andare tranquillo, altrimenti in caso di “sospetto WMV” lo script prima controlla che questo sia coerente con il Content-type, dopodiché se è affermativo si occupa di verificare se è un vero file o uno stream MMS. Il controllo di coerenza dovrebbe impedire di cadere nella trappola delle false informazioni, e da quanto ho potuto testare è del tutto robusto.

Già che c’ero, ho aggiornato lo script per gestire altri casi di video (ormai alla Rai non sanno più cosa inventarsi), come ad esempio questa puntata del «Maurizio Costanzo Talk». Ho trovato questo video guardando gli esempi dal piccolo web-service di Paolo Pancaldi, che fa più o meno le stesse cose del mio script (tranne Rai Replay e la riproduzione con player nativo) ma in “stile lato server”, perciò un grazie a Paolo per avermelo fatto scoprire.

Se avete già lo script e volete aggiornare manualmente oppure se volete installarlo da zero, trovate tutti i dettagli nel mio post apposito.

Installare Autopano per ridare funzionalità a Hugin su Ubuntu 13.04

Se utilizzate Hugin — il famoso software per la creazione di immagini panoramiche — su Ubuntu probabilmente ve ne sarete già accorti. Dalla versione 13.04 è stato deciso di rimuovere autopano-sift dai repository, vale a dire il tool usato da Hugin per calcolare i descrittori SIFT e quindi trovare automaticamente dei punti di corrispondenza tra le immagini da unire.

Punti di controllo trovati automaticamente visualizzati in Hugin
Punti di controllo trovati automaticamente visualizzati in Hugin

Questo deriva dall’apertura del bug #1082572, dove si chiede di rimuovere il pacchetto in quanto il progetto risulta abbandonato e usa Mono. Non solo, la richiesta di includere autopano-sift-c (lo stesso programma scritto in C) è stata rifiutata in un altro bug (#323836) con motivazioni abbastanza simili. Per questo motivo ora nei repository manca un componente, seppure questo fosse perfettamente funzionante.

Da ciò ne deriva che sì, Hugin è utilizzabile, con il piccolo dettaglio però che le immagini le dovrete unire totalmente a mano, perché il programma non creerà per voi dei punti di controllo. È vero che i punti di controllo manuali di solito sono migliori, tuttavia nella maggior parte dei casi iniziare con SIFT permette di avere già un’ottima base che poi si può affinare e correggere in poco tempo.

Inoltre è totalmente falso che Hugin è in grado di trovare dei punti di controllo accettabili di suo. Semplicemente la funzionalità interna restituisce pochissimi punti anche in casi facili, di fatto come non averne. Fortunatamente si può recuperare una versione funzionante di autopano-sift-c da questo vecchio PPA e installarla, perché le sue dipendenze sono pressoché nulle.

Potete farlo salvando il pacchetto DEB per la vostra architettura (32 o 64 bit) che trovate in fondo a questa pagina e facendoci doppio click. Vi comparirà la consueta finestra di installazione del pacchetto e vi basterà dare conferma. Infine aprite Hugin e andate nel menu alla voce File » Preferenze » Ricerca dei punti di controllo, impostando Autopano-SIFT-C come predefinito. A questo punto il gioco è fatto e Hugin ritorna ad essere utile come lo era prima!

Freeze con Ubuntu 13.04 su Samsung Serie 5 — la colpa può essere del driver Intel

Se mi seguite da un po’ saprete che il mio portatile attualmente è un Samsung Serie 5, in particolare il mio modello ha codice NP530U3B-A01IT. Questo computer è equipaggiato con una scheda video Intel HD Graphics 3000 e l’accelerazione hardware funziona di default con Ubuntu e i driver open source, anche perché i driver ufficiali Intel sono software libero.

Ho iniziato con Ubuntu 12.04 e poi ho via via aggiornato fino ad arrivare a questi ultimi mesi, in cui avevo effettuato l’upgrade a Ubuntu 13.04 quando quest’ultima era ancora in beta. Da quel momento, mi era capitato di riscontrare ogni tanto dei veri e propri congelamenti (freeze) dell’interfaccia, risolvibili spostandomi in una TTY e poi di nuovo al desktop (Cltr+Alt+F1 seguito da Ctrl+Alt+F7 per capirci).

In un primo momento non ci avevo prestato troppa attenzione, in quanto usavo un sistema in beta, e inoltre spesso succedeva quando Spotify era aperto, e anche Spotify è attualmente un software in fase di sviluppo e non è garantito che sia stabile. Tuttavia ora che Ubuntu 13.04 è uscita da un po’ ho voluto provare a vedere se si poteva fare qualcosa per migliorare la situazione. Ho aggiornato i driver ufficiali e ho cambiato la configurazione di X11 ed ora i freeze succedono brevissimamente solo in caso di carico pesante della CPU (per esempio quando uso VirtualBox dedicando molte risorse alla macchina virtuale) ma questo è comprensibile.

Aggiornamento del driver Intel

Intel mette a disposizione un updater ufficiale che di recente è stato reso disponibile anche per Ubuntu 13.04. Vi basta recarvi alla pagina di download e selezionare il pacchetto per Ubuntu, stando attenti a scegliere quello dell’architettura giusta (32bit o 64bit). Salvatelo e fateci doppio click, vi apparirà la finestra per installarlo.

Vi consiglio anche di sistemare la chiave di autenticazione del pacchetto, per evitare successivi problemi:


sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8D8847D52F4AAA66

Una volta che avete il programma, avviatelo e comparirà una schermata simile a questa:

Strumento di aggiornamento per i driver Intel
Strumento di aggiornamento per i driver Intel

La procedura guidata è molto semplice. Al termine, il pacchetto del nuovo driver sarà installato e vi mancherà solo la configurazione finale di X11.

Configurazione di X11

Il driver Intel così installato sarà stabile e testato. Tuttavia, lo spunto per un’ulteriore personalizzazione mi è venuto dal PPA delle versioni instabili dei driver per Ubuntu, in particolare nella parte che dice:

June 29th, 2012: SNA is now on by default on intel. If you have problems (such as screen corruption, parts of the screen not updating, or crashes with intel_drv.so in the Xorg.0.log backtrace), save this as /etc/X11/xorg.conf

Per questo motivo, aprite il file di configurazione di X11 come amministratore, usando il comando:


sudo xdg-open /etc/X11/xorg.conf

Se non avete fatto altre configurazioni in precedenza, dovrebbe essere completamente vuoto. Copiateci dentro il seguente codice e salvate:

Section "Device"
    Identifier "intel"
    Driver "intel"
    Option "AccelMethod" "uxa"
EndSection

A questo punto riavviate il computer per applicare i cambiamenti.

Conclusione

Nel mio caso la procedura che vi ho spiegato ha contribuito molto a rendere stabile la parte grafica del mio sistema, che ora non ha più blocchi immotivati. Per completezza, vi ricordo anche i parametri del kernel che utilizzo all’avvio del sistema (dentro alla configurazione di GRUB) come li avevo scritti nei commenti al mio precedente post:

pcie_aspm=force i915.i915_enable_rc6=1 i915.semaphores=1

Sveglia silenziosa e microfono spento su Android — ecco come risolvere

Di recente mi sono trovato ad affrontare due diversi problemi legati all’audio sul mio telefono Android (nello specifico uno Star B63M, modello cinese economico ma dalle buone prestazioni). Il primo è ciò che avevo definito solo “un problema con la sveglia”, ovvero al mattino la sveglia, invece di squillare, vibrava e basta. Il secondo è addirittura più fastidioso, ovvero durante una telefonata l’interlocutore non mi poteva sentire.

Inizialmente ho pensato che si trattasse della scarsa qualità del mio dispositivo, ma è bastato cercare e cercare ancora per verificare che si tratta di problematiche assai diffuse su molti dispositivi e versioni di Android. Di seguito vi spiego quindi come potreste risolverli, o perlomeno questi sono semplici passaggi che hanno funzionato al 100% per me.

Sveglia silenziosa — ovvero “silent alarm bug”

Questo problema mi ha “simpaticamente” colpito il primo giorno di università qui in Danimarca. Si tratta in sostanza del fatto che al mattino la sveglia invece di squillare vibra e basta. Per rendere la faccenda ancora più complicata da gestire, nel mio caso reimpostando la sveglia per fare dei test essa suonava senza problemi… fino al mattino dopo, quando era silenziosa di nuovo.

Ironicamente, notando il telefono vibrare e toccando lo schermo, il suono partiva senza problemi. Il mio rimedio iniziale è stato drastico: ho comprato una piccola sveglia da tavolo. 😀 Poi con più calma ho cercato di risolvere la questione cercando di capire cosa poteva essere successo. Ero certo infatti che l’opzione Allarme in mod. silenz. fosse correttamente attivata.

Leggendo un po’ (ad esempio qui), ho scoperto che il problema viene scatenato se cercate di usare insieme la suoneria e la vibrazione. Questo teoricamente si può fare ma nella pratica fa sì che il telefono vibri e basta. Per risolvere il problema quindi, disattivate la vibrazione su tutte le sveglie, anche se sono avviate da applicazioni di terze parti.

Microfono muto — detto anche “silent call bug”

In realtà il problema è un po’ più esteso, non riguarda solo le chiamate: quando capita il microfono è completamente muto e non consente il funzionamento della ricerca vocale, il registratore di suoni, eccetera. Se capita anche a voi, potete testare facilmente usando la ricerca vocale.

Dopo aver letto questo thread ho capito che il mio telefono a volte decide che l’auricolare è connesso anche se ciò non è vero, e disattiva il microfono esterno. Stranamente, l’output dagli speaker integrati funziona benissimo lo stesso. Il post illuminante è il seguente:

Wired Headphone Routing Fix

There is an issue with a lot of Android devices where the OS thinks the headphone is being plugged in and unplugged on its own.

I have rooted 4.0.4 AOKP and it still occured.

Try this free application to resolve it:

https://play.google.com/store/apps/details?id=com.woodslink.android.wiredheadphoneroutingfix

Le impostazioni di SoundAbout
Le impostazioni di SoundAbout

Ho provato ed ha funzionato quasi subito. Questo è il procedimento che per me ha avuto successo e che vi consiglio:

  1. installate l’applicazione SoundAbout e non spostatela nella scheda SD
  2. attivate il riconoscimento degli auricolari ma dite di ignorare il microfono (vedete la figura)
  3. riavviate il telefono
  4. inserite le cuffie
  5. rimuovete le cuffie
  6. testate la ricerca vocale

A questo punto dovrebbe funzionare tutto tranquillamente. 🙂 Ricordatevi che se volete usare gli auricolari per chiamare dovrete riattivarne il riconoscimento all’interno dell’applicazione.