Linux ModemManager Blacklist

(OpenSuse 11.4)


Networkmanager ha un modulo che si chiama modem-manager che prova a configurare modem su qualsiasi USB-Serial compaia: [http://comments.gmane.org/gmane.linux.network.networkmanager.devel/17250]

Per escludere alcune porte ho creato /etc/udev/rules.d/77-mm-usb-device-blacklist.rules:

  # Disabilita alcuni dispositivi dall'essere rilevati e interrogati da modem-manager
  
  ACTION!="add|change", GOTO="mm_usb_device_blacklist_end"
  SUBSYSTEM!="tty", GOTO="mm_usb_device_blacklist_end"
  
  SUBSYSTEMS=="usb", GOTO="mm_usb_device_blacklist_vendorcheck"
  GOTO="mm_usb_device_blacklist_end"
  
  LABEL="mm_usb_device_blacklist_vendorcheck"
  
  SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTDOCOXM", ENV{ID_MM_DEVICE_IGNORE}="1"
  SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTDOCOXM", ENV{ID_MM_PORT_BLACKLISTED}="1"
  
  LABEL="mm_usb_device_blacklist_end"

Il file di esempio qui sopra aggiunge alla black list di dispositivi da non configurare l'adattatore USB con serial nr. "FTDOCOXM".
Per evitare che modemmanager faccia anche solo il probe iniziale delle porte, e' stato necessario compilare la patch che ho trovato qui: [http://bugzilla-attachments.gnome.org/attachment.cgi?id=154215]

copiare il plugin generic

  # cp ./plugins/.libs/libmm-plugin-generic.so /usr/lib/ModemManager

e aggiungere le regole come:

  SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTDOCOXM", ENV{ID_MM_PORT_BLACKLISTED}="1"

Per esempio, il probe di modemmanager mi attivava l'alimentazione dispositivo su di un programmatore LPC900icp

Per rilevare ATTRS{idVendor}, ATTRS{idProduct} e ATTRS{serial} dei dispositivi USB:

  # tail -f /var/log/messages

Nota: gli adattatori USB Serial con chipset Prolific NON sembrano avere serial nr, quindi non e' possibile utilizzare questo metodo. I chipset FTDI invece sono OK.

Change FTDI USB-Serial latency in Linux

If you try to change the settings like this, it won't work:

  # cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
    1
  # echo 16 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
  # cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
    1

The low_latency flag is set by default, which forces it to 1, always. You have to run the follwing command to disable it:

  # setserial /dev/ttyUSB0 ^low_latency

Then you can modify the latency_timer entry:

  # cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
    16
  # echo 8 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
  # cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
    8

GDB and Geany IDE: Remote Cross Debugging

Embedded Linux System Debugging with Geany

Remote debugging is when GDB runs on one machine and the program being debugged runs on another. This is useful in embedded systems, and often in this case it's called remote cross-debugging because the target CPU is differerent from the host used for developing code.
gdbserver can be used to remotely debug the program without needing to change it in any way.

The Geany IDE debugger plugin does not support remote debugging natively. Some graphical debugger such as Insight or the Eclipse IDE support it, but not Geany. And I like Geany very much, while I don't like Eclipse: so I arranged a patch/workaround to do it (based on plugin version 0.21).

Compiling the patch

Download geany plugins sources [http://plugins.geany.org/downloads.html] and install geany and gtk devel packages for your distribution. You'll need also Geany devel package installed. Compiling debugger plugin needs also vte-devel package installed.

  # cd geany-plugins-0.21.1

  # ./configure --prefix=/usr --mandir=/usr/share/man/

  # cd debugger/src

  # make

Compiled plugin is in the debugger/src/.libs/ directory (debugger.so). You will need to copy it in /usr/lib/geany (or where your distribution places the geany plugins), or install it with:

  make install

Geany can use an addictional path for plugins search (see Geany options), and if you want to use it you will have to configure the sources with:

  # ./configure --prefix=/your/path/to/plugins --mandir=/usr/share/man/

Here below the patch for dbm_gdb.c file:

---

  --- geany-plugins-0.21.1/debugger/src/dbm_gdb.c.original
  +++ geany-plugins-0.21.1/debugger/src/dbm_gdb.c
  @@ -96,6 +96,9 @@
   
   /* flag, showing that on debugger stop we have to call a callback */
   gboolean requested_interrupt = FALSE;
  +
  +/* flag: remote debugging session*/
  +gboolean remote_session = FALSE;
   
   /* autos list */
   static GList *autos = NULL;
  @@ -598,6 +601,9 @@
    */
   gboolean load(char* file, char* commandline, GList* env, GList *witer)
   {
  +char *ip;
  +char *port;
  +
    /* loading file */
    GString *command = g_string_new("");
    g_string_printf(command, "-file-exec-and-symbols %s", file);
  @@ -610,11 +616,38 @@
     return FALSE;
    }
   
  - /* set arguments */
  - command = g_string_new("");
  - g_string_printf(command, "-exec-arguments %s", commandline);
  - exec_sync_command(command->str, TRUE, NULL);
  - g_string_free(command, TRUE);
  + /* is it a remote target? */
  + /* (remote sessions handle commandline on debugserver side) */
  + if (commandline[0] == '@') {
  +  ip = commandline + 1;
  +  port = strchr(ip, ':');
  +  if (port != NULL) {
  +   *port = '\0';
  +   port++;
  +  }
  +  else {
  +   port = (char *)"3278";
  +  }
  +  if (ip == '\0') {
  +   ip = (char *)"127.0.0.1";
  +  }
  +  if (port == '\0') {
  +   port = (char *)"3278";
  +  }
  +  command = g_string_new("");
  +  g_string_printf(command, "target remote %s:%s", ip, port);
  +  exec_sync_command(command->str, TRUE, NULL);
  +  g_string_free(command, TRUE);
  +  remote_session = TRUE;
  + }
  + /* set arguments in non-remote sessions */
  + else {
  +  remote_session = FALSE;
  +  command = g_string_new("");
  +  g_string_printf(command, "-exec-arguments %s", commandline);
  +  exec_sync_command(command->str, TRUE, NULL);
  +  g_string_free(command, TRUE);
  + }
    
    /* set locale */
    command = g_string_new("");
  @@ -678,7 +711,14 @@
    }
    free_start_messages();
   
  - exec_async_command("-exec-run &");
  + if (remote_session) {
  +  exec_async_command("break main");
  +  sleep(2);
  +  exec_async_command("continue");
  + }
  + else {
  +  exec_async_command("-exec-run &");
  + }
   }
   
   /*
  @@ -686,6 +726,9 @@
    */
   void restart(char* terminal_device)
   {
  + if (remote_session) {
  +  dbg_cbs->report_error(_("Restart command not available in remote sessions"));
  + }
    dbg_cbs->clear_messages();
    exec_async_command("-exec-run &");
   }

---

Remote debugging

After compiling and installing this patched plugin, enable Debugger plugin in Geany. Remote debugging can be used inserting in the debugger plugin tab "Command Line" field the following format string:

  @remoteipaddr:port

for example:

  @192.168.2.51:4567

If you don't specify remoteipaddr, the default used is 127.0.0.1; if you don't specify port, the default used is 3278.

On the remote side, you'll have to start gdbserver:

  # gdbserver localhost:4567 yourprogram [yourprogram options]

Command options must be specified on the gdbserver side, when debugging remotely.

Cross debugging

The remote device can be a target CPU different from the host. For example it could be an embedded ARM Linux board. In this case you have to use a shell script to start geany with the correct path for the right gdb executable (x86 gdb executable can not debug other target CPUs than x86); let's suppose your ARM gdb executable is gdb-arm-linux (you can download it from emdebian: gdb-arm-linux-gnueabi_7.2-1_i386.deb) and you installed it in your ~/bin/arm-linux-emdebian/usr/bin/ directory:

• create a symlink gdb to gdb-arm-linux:

    # cd ~/bin/arm-linux-emdebian/usr/bin/
  

    # ln -s gdb-arm-linux gdb
  

• then create a shell script like this and use it for starting Geany:

    #!/bin/sh
    PATH=/home/yourhome/bin/arm-linux-emdebian/usr/bin/:$PATH
    geany $1
  

Notes

A few notes on remote debugging use:

• don't use "Restart" command in remote debugging session: it can't be used
• a breakpoint is automatically placed at main start (break main) so program stops there after first run, but it's not shown in Geany
• place manually yourself a breakpoint in the place where program stops initially: it will prevents other breakpoints garbage later

This does not want to be a definitive solution: it's a dirty patch/workaround for my needs.

Eizo EV2316W: xrandr settings

Setting up Eizo Flexscan EV2316W LCD Monitor under Linux with xrandr

Using OpenSuse 11.4 and a DELL d820 laptop.

The monitor supports a max pixel clock of 148.50:

# xrandr --newmode "1920x1080"  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync
# xrandr --addmode VGA 1920x1080

# xrandr --output LVDS --off
# xrandr --output VGA --mode 1920x1080


If you are using KDE4 you may experiment a "mouse disappear" problem after changing screen resolution as shown; the only workaroud I found is the following (needs sudo):

# sudo /bin/chvt 1; sudo /bin/chvt 7

Here below a script for automating this:

Philips 226V4LAB: xrandr settings

Setting up Philips 226V4LAB LCD Monitor under Linux with xrandr

Using OpenSuse 11.4 and an old eeePC 701.

The monitor seems to support a max pixel clock of 138.50:

# xrandr --newmode "1920x1080R"  138.50  1920 1968 2000 2080  1080 1083 1088 1111 +hsync -vsync
# xrandr --addmode VGA1 1920x1080R

# xrandr --output VGA1 --rate 59.9* --mode 1920x1080R
# xrandr --output VGA1 --rate 59.9* --mode 1920x1080R --output LVDS1 --off



Here below a script for automating this:

Scelta del monitor

Parametri di selezione per un video LCD da programmatore Recentemente mi sono trovato a voler acquistare un nuovo monitor da collegare al mio PC portatile quando e' in configurazione "dock", cioe' quando non lo uso come laptop ma in modo piu' simile ad un desktop. Ho fatto dunque delle ricerche e delle riflessioni sui parametri di scelta da usare che puo' essere utile ricordare.

L'utilizzo che faccio del monitor e' lavorativo, e nello specifico quello dello sviluppatore elettronico embedded: CAD elettronico, documentazione, navigazione internet, email, ma soprattutto programmazione software e firmware (quindi editor di testo, finestre terminale). Tutte le mie considerazioni sono da riferire a questo utilizzo.

Uso sempre solo Linux.

Dimensioni

Mi sono orientato intorno ai 20": penso che meno di 17" sia inutile rispetto al video del laptop, e piu' di 24 non adatto all'uso che ne faccio. 21" o 23" sono perfetti.

Tipologia pannello

TN o IPS? Opaco o lucido? Retroilluminazione?

TN o IPS?

TN e' la tecnologia piu' vecchia:

• ha tempo di risposta leggermente piu' basso, quindi e' piu' veloce (positivo)
• costa meno (positivo)
• ha una resa colori meno realistica (negativo)
• ha un angolo di visione verticale meno esteso (negativo)

Al contrario, IPS e' una tecnologia piu' recente, i cui unici aspetti negativi sono che costa di piu' ed ha un tempo di reazione leggermente piu' alto (typ. 6~10ms contro i 5ms dei TN). In considerazione dell'utilizzo che ne faccio, in cui la resa colori e la velocita' sono secondari, mi sono orientato su un TN.

Opaco o lucido?

Il video lucido attira l'attenzione e sembra piu' bello, ma e' solo un'impressione estetica: riflette di piu' la luce e stanca gli occhi, quindi e' meglio un video OPACO.

Retroilluminazione?

La possibilita' di regolare finemente luminosita', contrasto e temperatura di colore e' molto importante per la qualita' della visione e stanchezza dell'occhio.
Oggi tutti i video sono retroilluminati a LED, perche' costa meno, consuma meno, da' una luminosita' e contrasto maggiori, una resa dei colori migliore, dura di piu'.
Questo tipo di retroilluminazione pero' ha un grosso svantaggio: la regolazione della luminosita' e' fatta con una tecnica che si chiama "PWM" e consiste nell'accendere e spegnere ad una frequenza relativamente alta i LED; maggiore e' il tempo in cui stanno accesi rispetto a quello in cui stanno spenti, maggiore e' la luminosita' media prodotta.
Questo metodo funziona bene con le fonti luminose ad alta persistenza, cioe' che ci mettono un po' di tempo ad accendersi ed un altro po' a spegnersi: in tal caso infatti la luminosita' risultante e' veramente la media di ON e OFF della fonte luminosa; i LED purtroppo (per questa tecnica) hanno una velocita' di accensione e spegnimento elevatissima, quindi bassissima persistenza, quindi si accendono e spengono veramente durante i cicli di ON e OFF del PWM. Il risultato e' che chi ha occhi molto sensibili alla persistenza vede il video "vibrare" alle basse luminosita', soprattutto se la frequenza del PWM non e' elevatissima. Questo effetto e' chiamato "flickering", ed e' visibile da circa il 10% della popolazione (io sono tra questi). Anche chi non ricade in quel 10% che vede il fenomeno, inconsciamente si stanca di piu' lavorando su un video con flickering, e puo' essere anche soggetto a mal di testa verso fine giornata.
Per evitare del tutto il flickering i LED andrebbero controllati in corrente, ma cio' comporterebbe due problemi:

• costo maggiore
• cattiva resa dei colori

Al momento c'e' un solo produttore al mondo che si e' ingegnato per risolvere questo problema: EIZO ha rilasciato a Novembre 2013 una serie di video con tecnologia chiamata "EyeCare" che regola la luminosita' con un misto di PWM e corrente.
[http://www.tomshw.it/cont/news/eizo-eyecare-stop-ai-mal-di-testa-davanti-al-monitor/43828/1.html]

Consumo

Chissenefrega del consumo, un LCD a LED comunque non consuma niente. EnergyStar aveva senso con i video CRT.

Marca

Credo che tutti i pannelli LCD siano in realta' prodotti da una o due marche cinesi al mondo, probabilmente una delle quali e' LG. Questo potrebbe far pensare che non abbia senso prendere altre marche, ma non e' vero: il controllo delle regolazioni, gli optional, la retroilluminazione e il controllo di qualita' sono fatti dalla marca che li vende, e sono cose che contano. Sui monitor di fascia bassa inoltre non e' raro trovare dei pixel guasti, e normalmente il produttore accetta la sostituzione solo se sono piu' di 4 o 5; marche blasonate non hanno questo problema (di solito).

Scelte

Ho acquistato due monitor, uno per uso intensivo ed uno per uso occasionale.

Eizo Flexscan EV2316W LCD Monitor

23", TN, retroilluminazione LED EyeCare, 1920x1080. Molto soddisfacente, possibilita' di regolazioni finissime e numerose. Ottimo, anche se un po' costoso. Con il video all'altezza degli occhi si nota leggermente la differenza di colore tra la parte alta e la parte bassa (angolo di visualizzazione verticale), che probabilmente in un pannello IPS non si noterebbe (per 100 euro in piu').
Dotato anche di hub USB per collegare direttamente tastiera e mouse, altoparlanti, supporto girevole per la visione verticale, sensore luce ambiente per l'auto-adeguamento della luminosita'. Il manuale e' completissimo, con tutte le informazioni necessarie per impostarne l'uso anche su X11 Linux (xrandr).

Philips 226V4LAB LCD Monitor

21.5", TN, 1920x1080. Abbastanza scarso; appena sufficiente solo se usato alla massima definizione. Prezzo ottimo, pero' (un terzo del EIZO) e definizione massima buona. Possibilita' di regolazioni scarse e poco fini. Non sarebbe adatto se ne facessi un uso intensivo, e forse non mi soddisfa nemmeno per l'uso occasionale. Alle basse luminosita' si vede il flickering (o meglio: io lo vedo). Il manuale e' scarso (il pixel clock massimo, ad esempio, non l'ho trovato). Tutto sommato e' appena accettabile solo perche' costa poco e lo uso poco.

Del perche' la lampada a basso consumo sucks

Ho nostalgia della cara, vecchia illuminazione artificiale a incandescenza; le lampadine a basso consumo mi fanno schifo!

1) Costano 10 volte tanto le lampadine ad incancescenza: OTTO euro, dico otto euro minimo. Non se ne trovano a meno. Si, magari in un discount trovi lo scaffale con quelle a due euro, ma sono rottami che a malapena si accendono. Una lampadina standard quanto costava? Un euro? due? Zerocinquanta?

2) Durano UGUALE a quelle standard. Questa e' la mia percezione, non un dato oggettivo: mi sembra che si rompano con la stessa frequenza delle vecchie lampadine. Magari durano un po' di piu', ma poco. E non me ne accorgo.

3) Fanno una luce atroce. Alcune (quelle da DUE euro di cui sopra) secondo me fanno BUIO: attirano la luce ambiente come piccoli, malevoli buchi neri. Producono una luce vibrante, ci mettono un quarto d'ora ad accendersi e mezz'ora ad arrivare alla luce emessa massima; ho tre lampadine a basso consumo in bagno e rischio di tagliarmi quando mi faccio la barba se non mi alzo mezz'ora prima per accenderle!

4) COME CA**O PENSANO DI SMALTIRE QUELLE ROTTE? Una lampadina classica era un pezzo di vetro pieno di vuoto (o gas inerte) con un po' di latta: reciclabile al 100%, costo zero. Una lampadina a basso consumo e' fatta di: plastica, metallo, vetro, gas (non si sa bene quale e quanto dannoso sia), circuito stampato, stagno, rame, componenti elettronici vari. E forse ho dimenticato qualche pezzo.
NON E' RECICLABILE. Infatti non si sa mai dove buttarla.

5) Mi rompono le balle con la coscienza ecologica, e poi sul viale fuori casa c'e' accesa per tutta la notte un'alogena da centomilioni di kilowatt ogni cinque metri. Bah.

Spero solo nell'avvento dei LED, che pero' porteranno con se' il problema del flickering nella regolazione della luminosita' (problema gia' presente nei monitor LCD retroilluminati a LED).