Gardez NumLock toujours activé

J'ai déjà physiquement retiré le capuchon de la touche de verrouillage numérique, donc je n'appuie pas accidentellement (j'utilise un clavier très compact). Mais je comprends qu'il y a un bogue dans xorg qui bascule le verrouillage numérique offlorsque je change la disposition du clavier.

J'ai donc besoin de quelque chose qui empêche le verrouillage numérique de "désactiver" ou bien (peut-être plus facile?) Surveille l'état du verrouillage numérique et le active "dès qu'il remarque qu'il est" désactivé ".

Voici une réponse Unix qui semble résoudre ce problème, mais pour LXDE. Que devrais-je faire pour que cette idée fonctionne dans Ubuntu 15.04 et Unity?

Je ne sais pas comment surveiller ou interroger l'état de verrouillage numérique, ni comment modifier l'état de verrouillage numérique par programmation, mais voici une solution qui utilise un script simple qui s'exécute tout le temps. Il semble que cela fonctionnerait, mais je ne suis pas sûr que ce soit intelligent de le faire fonctionner tout le temps?

Le plus propre serait bien sûr de corriger le bogue, mais comme solution de contournement, le script d'arrière-plan fera le travail:

#!/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'"])

Comment utiliser

• Copiez le script ci-dessus dans un fichier vide, enregistrez-le sous NM_on.py

• Testez-le en arrière-plan avec la commande:

  python3 /path/to/NM_on.py
  

• Si tout fonctionne bien, ajoutez-le aux applications de démarrage: Dash> Applications de démarrage> Ajouter, ajoutez la commande:

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

Explication

Nous pouvons obtenir l' Num Lockétat actuel de plusieurs manières:

• exécution de la commande:

  xset q
  

  ce qui donnera une sortie comme:

  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
  .....
  

  ou avec la commande:

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

  qui revient simplement 'on', 'off'ou 'unknown'.

  Étant donné que ce dernier est extrêmement léger, nous pouvons très bien l'utiliser dans un script d'arrière-plan pour vérifier une fois par seconde, et définir la valeur sur 'on', si nécessaire, avec la commande:

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

et il en est ainsi ...

Éditer

Pour une raison quelconque, j'ai raté votre dernier paragraphe, dans lequel vous avez fait référence à une autre réponse avec une solution similaire.

En théorie, j'ai toujours un problème avec les scripts qui appliquent (ré) aveuglément les paramètres, sans vérifier l'état actuel. Il pourrait y avoir un argument pour le faire, si la commande

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

pour obtenir la valeur actuelle, serait plus exigeant que d'exécuter simplement

numlockx on

pour (re) régler numlockx on .
En regardant l'heure à laquelle les deux commandes doivent se terminer (ce qui est au moins une indication), c'est l'inverse; la commande

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

semble être plus "léger".

Exécuter un script d'arrière-plan est une mauvaise idée?

Bien sûr, si vous n'avez aucune raison d'exécuter un script d'arrière-plan, ne le faites pas. Dans le même temps, si un script d'arrière-plan est bien écrit, soigneusement testé, les procédures sont intelligemment optimisées et si cela n'ajoute aucun effet notable sur l'occupation du processeur, il serait stupide de ne pas l'utiliser comme solution de contournement s'il ajoute des éléments importants. fonctionnalité ou vous fait gagner du temps.

J'ai constamment au moins 4 à 8 scripts d'arrière-plan en cours d'exécution. La plupart d'entre eux pendant des semaines sans redémarrage. Je n'ai jamais remarqué d'effet sur mes systèmes âgés. Gardez à l'esprit que votre système exécute de nombreuses boucles de toute façon.