Linux Mint 21.1 Vera

Ho comperato a fine 2022 un Thinkpad L15 Gen3 con cpu Intel I7 e scheda video Intel Iris. Linux Mint 21 (e 21.1) girano senza problemi, riconoscendo tutto l'hardware. Il problema che ho avto riguarda la docking station Lenovo modello 40AFxxxx, sulla quale NON FUNZIONA IL VIDEO in quanto richiede l'uso del protocollo DisplayLink, che per Linux e` supportato ma solo da driver proprietari e pare che abbia un sacco di problemi. Ho quindi comperato una dock Lenovo modello 40AYxxxx che funziona perfettamente con il mio monitor esterno 2K su HDMI e su DP.

Linux Mint 21.1 introduce diverse modifiche grafiche fra le quali l' ORRENDO tema del cursore "Bibata", e in generale i temi moderi sono tragicamente "grigio su grigio". Vediamo come ho aggiustato un poco le cose a riguardo.

• Per rimettere il tema del cursore precedente, occorre prima di tutto selezionarlo tramite l'apposito programma grafico "Themes". Purtroppo pero` questo porta uno strano risultato: in alcuni casi, su alcuni programmi e al logon, si rinfaccia quel cavolo di Bibata. Per commutare TOTALMENTE ad un tipo di cursore diverso, occorre andare da command line e scegliere il tema che volete per il cursore. Ora lo avrete OVUNQUE.

  sudo update-alternatives --config x-cursor-theme

• Per avere la barra del titolo della finestra selezionata che non sia grigio su grigio come tutte quelle non selezionate, ma sia del colore di base del tema (nel mio caso azzurro), si può applicare questo css "personalizzato": https://github.com/the-allanc/minty-color-titles. Occorre semplicemente salvare il file "gtk.css" come "~/.config/gtk-3.0/gtk.css" (e fare logout e login). Allego il file in questione a questa pagina gtk.css nel caso in cui quello originale per qualche motivo non fosse più disponibile.
• Per avere dei bordi alle finestre, possiamo lavorare sempre su "~/.config/gtk-3.0/gtk.css" e aggiungere una voce per definire i bordi delle finestre. Nel file allegato a questa pagina gtk.css ci sono già comprese le mie modifiche per i bordi, in versione "a due colori" per le finestre attive e in background, e anche a un solo colore (uso quello di background) per le finestre attive e non attive. Chiaramente ci sono infinite possibilità che io nemmeno posso intuire, data la mia ignoranza di come si creino gli stili per GTK.
• Se volete provare a modificare la config dovete ricaricare Cinnamon ogni volta che fate una modifica per renderla attiva: potete farlo al volo premendo CONTROL-ALT-ESC.

Da qualche versione precedente (direi dalla 19 in poi) mi sono reso conto che il mouse bluetooth se non lo sposti va rapidamente in timeout, qualcosa nel link si disattiva, e quando lo vai a usare c'e` un paio di decimi di secondo di latenza prima che riparta. Lo trovo estremamente fastidioso.

Mi era chiaro che il problema è dovuto al power management, ma mi era sfuggito un dettaglio importante: non è il power management del device bluetooth, ma il power management del link usb fra il computer e la scheda bluetooth montata dentro di esso. Io mi scervellavo a cercare il problema sul link BT fra il PC e il mouse, dovevo cercarlo sul link USB fra il PC e la scheda BT che è montata al suo interno.

Questa semplice operazione di impostare il power control è diventata un incrocio fra una farsa e un delirio. Nel tempo, facendo varie prove, ho scoperto le seguenti cose delle quali non ho trovato alcuna spiegazione:

• Delirio 1: A seconda se ho la docking (il pc e` un portatile) collegata oppure no, il numero del device usb cambia (e fin qui ci potrebbe stare, quando li enumera trova molta roba in piu` se c'e` la docking connessa), ma la vera anomalia è che con la docking connessa il numero riportato da lsusb è compatibile con quello che vedo andando a esplorare il filesystem sotto /sys/bus/usb, quindi per capirci se guardo il numero di bus e device indicato da lsusb lo ritrovo correttamente sotto /sys/bus/usb, infatti andando a vedere se il device 3-10 corrisponde come ID, trovo una corrispondenza:

# lsusb
...
Bus 003 Device 010: ID 8087:0026 Intel Corp. AX201 Bluetooth
...
# cat /sys/bus/usb/devices/usb3/3-10[[/idVendor]] 
8087
# cat /sys/bus/usb/devices/usb3/3-10[[/idProduct]] 
0026

Se invece non ho la docking collegata (e ho riavviato per essere sicuro di "resettare" il discovery dei device) allora lsusb mi riporta un altro numero di bus e device (1-5) ma sotto /sys/bus/usb il device 1-5 non è quello giusto, non è la scheda bluetooth bensì è la webcam integrata. Sotto /sys/bus/usb, il device usb bluetooth è ancora nel bus 3/10! Mi chiedo da dove prenda i suoi dati di bus e device il comando lsusb per fare sì che non conincidano con quello che trovo sotto /sys/bus/usb. Ammetto che probabilmente è un problema di mia ignoranza, ma sento come lo zampino di Systemd in questo ennesimo caso di insensatezza intrinseca di Linux.

• Delirio 2: Una regola di udev creata per modificare il power management e metterlo da "auto" a "on" (lo scopo di tutta questa battaglia) funziona benissimo se la lanci a mano, ma non funziona in alcun modo quando dovrebbe partire al boot. Infatti la regola di udev (che vedremo dopo) lanciando a mano 'udevadm test -a add /sys/bus/usb/devices/usb3/3-10 viene applicata, ed essendo nominata "99-xxx" viene applicata per ultima, infatti il risultato finale è che il power save viene spento, come vorrei. Lanciando a mano udevadm trigger -v --attr-match=idVendor="8087" --attr-match=idProduct=0026 ottengo il medesimo risultato, la regola viene applicata correttamente (anche se in questo caso non ho output di debug che mi dice cosa accade). Nel tentare di capire come mai non venga lanciata la regola al boot, sono arrivato a ricerare l' initramfs (update-initramfs -u -k all) e anche a verificare che il mio file di regole venisse davvero incluso dentro a initramfs (lsinitramfs /boot/initrd.img-5.15.0-67-generic | grep "il nome del mio file di regole"). È tutto come dovrebbe essere, ma al boot NON VIENE APPLICATA LA REGOLA. Ci ho rinunciato e la applico dopo il boot usando una unit di systemd.

Dopo aver passato un paio d'ore o forse più (complice il fatto che per fare un test devo ribootare la macchina sulla quale sto lavorando) a cercare di capire come mai la mia regola di udev non si applica al boot, ho rinunciato e ho aggirato il problema. Vediamo come:

• Creare una regola per udev che imposti il powersave per il nostro device a "on" invece di "auto". Il nostro device, l'abbiamo visto prima, e` identificato come Vendor 8087 e Product 0026. Questa identificazione non è "variabile" come il numero del bus, per cui funziona correttamente in qualsiasi configurazione hardware, anche se il numero del bus cambia. Avrei potuto banalmente usare echo on > /sys/bus/usb/devices/3-10/power/control ma se poi il numero del bus cambia il trucco non funziona più. Usando udev e i vendor e product id ottengo una identificazione univoca (essendo che ho una sola interfaccia con quegli id, ovviamente). Insomma, creo un file con nome /etc/udev/rules.d/99-usb-power.rules e ci scrivo dentro che voglio che il power control sia ON e non AUTO. Notare che ho messo due righe, una che specifica una condizione di "add" e una no, questo è uno dei tanti tentativi di farlo funzionare al boot, alla fine l'ho lasciato così ma sono abbastanza sicuro che una delle due righe sia supeflua.

  99-usb-power.rules

  SUBSYSTEM=="usb", ATTR{idVendor}=="8087", ATTR{idProduct}=="0026", TEST=="power/control", ATTR{power/control}="on"
  SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="8087", ATTR{idProduct}=="0026", TEST=="power/control", ATTR{power/control}="on"

• Verificare se la regola di udev funziona, lanciandola a mano e poi vedendo se il power control per il nostro device è passato a "on":

  # udevadm trigger -v --attr-match=idVendor="8087" --attr-match=idProduct=0026
  
  # cat /sys/bus/usb/devices/usb3/3-10/power/control 
  on

• Se non va, possiamo tentare un test con debug, dal quale dovremmo vedere le azioni compiute dalle varie regole

  udevadm test -a add /sys/bus/usb/devices/usb3/3-10

• Una volta che abbiamo visto che va, dobbiamo lanciare a mano la regola di udev in quanto al boot NON SI APPLICA E NON SO PERCHÉ. Creerò quindi una unit per systemd che lancia uno shell script che lancia udev per impostare quel cavolo di parametro.
  • Creo il file della unit, con il nome /etc/systemd/system/bluetooth-no-power-save.service

    bluetooth-no-power-save.service

    [Unit]
    Description=Disable Power save on bluetooth
    
    [Service]
    ExecStart=/usr/sbin/disable-powersave-bluetooth
    
    [Install]
    WantedBy=multi-user.target

• Creo lo script che viene eseguito dalla unit, il file è /usr/sbin/disable-powersave-bluetooth e ovviamente lo rendo eseguibile.

  disable-powersave-bluetooth

  #!/bin/sh
  /usr/bin/udevadm trigger -v --attr-match=idVendor="8087" --attr-match=idProduct=0026

• Ricarico systemd, abilito il servizio, eseguo il servizio:

  systemctl daemon-reload
  systemctl enable bluetooth-no-power-save.service
  systemctl start bluetooth-no-power-save.service

• A questo punto dovrebbe essere tutto a bolla, riavviando il PC la regola di udev non verrà applicata al boot (chissà perché) ma verrà applicata da systemd dopo il boot, e quindi alla fine, se tutto va bene, vedremo che il powersave è disattivato per il nostro device bluetooth usb:

  # cat /sys/bus/usb/devices/usb3/3-10/power/control 
  on

Ho impostato il locale a "Inglese Danimarca" (en_DK.UTF-8) per quanto riguarda le impostazioni di ora e data, per avere la lingua inglese (come uso) e un formato europeo della data.

Va commentata la riga SendEnv LANG LC_* nel file /etc/ssh/ssh_config per evitare che quando faccio ssh verso qualche macchina remota questa "impari" il mio locale e faccia ogni sorta di casino. Che si tenga il suo, di locale.

Sul Thinkpad (e non solo, ma non so dirvi su quali portatili) è possibile accedere ai valori impostati nel controller della carica della batteria e anche modificarli, volendo, per ottenere l'effetto di stressare meno la batteria (a scapito della durata di una singola carica, si aumenta la vita totale della batteria).

I valori che ci interessano sono (sul mio portatile):

cat /sys/class/power_supply[[/BAT0]]/charge_control_start_threshold 
0
cat /sys/class/power_supply[[/BAT0]]/charge_control_end_threshold 
100

Questi valori indicano che la carica inizia quando la batteria non e` al 100% (il valore di "0" immagino non stia a indicare realmente "0" ma semplicemente "sempre") e che la carica finisce quando la batteria è al 100%.

Supponiamo però di voler conservare la batteria per quanti più anni possibile: potremmo decidere di iniziare la carica solo quando la batteria scende sotto al 75%, e di non caricarla oltre l' 85%. Per fare questo, come root, eseguiamo:

echo 85 > /sys/class/power_supply[[/BAT0]]/charge_control_end_threshold
echo 75 > /sys/class/power_supply[[/BAT0]]/charge_control_start_threshold

Queste impostazioni rimangono sempre salvate e funzionano anche a PC spento, in quanto vengono salvate dentro al circuito di controllo della carica che ovviamente funziona anche a PC spento.