Mantieni NumLock sempre attivo

Ho già rimosso fisicamente il cappuccio del tasto Bloc Num, quindi non lo premo accidentalmente (utilizzo una tastiera molto compatta). Ma capisco che c'è un bug in xorg che attiva Bloc Num offquando cambio layout di tastiera.

Quindi ho bisogno di qualcosa che impedisce a Num Lock di "disattivarsi", o in alternativa (forse più facile?) Monitora lo stato di Num Lock e lo attiva "non appena si accorge che è" spento ".

Ecco una risposta Unix che sembra indirizzare questo, ma per LXDE. Cosa dovrei fare per far funzionare questa idea in Ubuntu 15.04 e Unity?

Non so come monitorare o interrogare lo stato di Bloc Num o come modificare a livello di programmazione lo stato di Bloc Num, ma ecco una soluzione che utilizza un semplice script che viene eseguito continuamente. Sembra che funzionerebbe, ma non sono sicuro che sia intelligente farlo funzionare tutto il tempo?

Il più pulito sarebbe ovviamente correggere l'errore, ma come soluzione alternativa, lo script in background seguente farà il lavoro:

#!/usr/bin/env python3
import subprocess
import time

key = "org.gnome.settings-daemon.peripherals.keyboard numlock-state"
while True:
    time.sleep(1)
    state = subprocess.check_output([
        "/bin/bash", "-c", "gsettings get "+key]).decode("utf-8").strip()
    if state != "'on'":
        subprocess.Popen([
            "/bin/bash", "-c", "gsettings set "+key+" 'on'"])

Come usare

• Copia lo script sopra in un file vuoto, salvalo come NM_on.py

• Esegui il test in background con il comando:

  python3 /path/to/NM_on.py
  

• Se tutto funziona correttamente, aggiungilo alle applicazioni di avvio: Dash> Applicazioni di avvio> Aggiungi, aggiungi il comando:

  /bin/bash -c "sleep 10 && python3 /path/to/NM_on.py"
  

Spiegazione

Possiamo ottenere lo Num Lockstato corrente in più di un modo:

• eseguendo il comando:

  xset q
  

  che darà un output come:

  Keyboard Control:
    auto repeat:  on    key click percent:  0    LED mask:  00000000
    XKB indicators:
      00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
      03: Compose:     off    04: Kana:        off    05: Sleep:       off
      06: Suspend:     off    07: Mute:        off    08: Misc:        off
      09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
      12: Group 2:     off    13: Mouse Keys:  off
    auto repeat delay:  500    repeat rate:  33
  .....
  

  o con il comando:

  gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
  

  che semplicemente ritorna 'on', 'off'o 'unknown'.

  Poiché quest'ultimo è estremamente leggero, possiamo benissimo usarlo in uno script in background per verificare una volta al secondo e impostare il valore su 'on', se necessario, con il comando:

  gsettings set org.gnome.settings-daemon.peripherals.keyboard numlock-state 'on'
  

e così fa ...

modificare

Per qualche motivo, ho perso il tuo ultimo paragrafo, in cui hai fatto riferimento a un'altra risposta con una soluzione simile.

In teoria, ho sempre un problema con gli script che (ri) applicano ciecamente le impostazioni, senza controllare lo stato corrente. Ci potrebbe essere un argomento di farlo, se il comando

gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state

per ottenere il valore corrente, sarebbe più impegnativo che semplicemente eseguirlo

numlockx on

per (ri) impostare numlockx on .
Guardando l'ora in cui entrambi i comandi devono terminare (che è almeno un'indicazione) è comunque il contrario; il comando

gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state

sembra essere più "leggero".

Eseguire uno script in background è una cattiva idea?

Naturalmente, se non hai motivo di eseguire uno script in background, allora non farlo. Allo stesso tempo, se uno script in background è ben scritto, accuratamente testato, le procedure sono ottimizzate in modo intelligente e se non aggiunge alcun effetto evidente sull'occupazione del processore, sarebbe sciocco non usare come soluzione alternativa se aggiunge importanti funzionalità o ti fa risparmiare tempo.

Ho costantemente almeno 4-8 script in background in esecuzione. La maggior parte di loro per settimane senza riavvio. Non ho mai notato alcun effetto sui miei sistemi anziani. Tieni presente che il tuo sistema esegue comunque numerosi loop.