始终保持NumLock

我已经在物理上移除了Num Lock键帽,所以我不小心按下它(我使用非常紧凑的键盘)。 但是我知道xorg中有一个错误,当我切换键盘布局时,会将Num Lock切换为off

所以我需要的东西可以阻止Num Lock“关闭”,或者(或许更容易?)监视Num Lock状态,并在它注意到它“关闭”时立即将其“打开”。

这是一个Unix答案似乎解决了这个问题,但对于LXDE。 为了使这个想法在Ubuntu 15.04和Unity中运行,我需要做些什么?

我不知道如何监视或查询Num Lock状态,或者如何以编程方式更改Num Lock状态,但这是一个使用一直运行的简单脚本的解决方案。 听起来它会起作用,但我不确定让它一直运行是否明智?

最干净的当然是修复bug,但作为一种解决方法,下面的后台脚本将完成这项工作:

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

如何使用

  • 将上面的脚本复制到一个空文件中,将其另存为NM_on.py
  • 使用以下命令在后台测试运行它:

     python3 /path/to/NM_on.py 
  • 如果一切正常,请将其添加到Startup Applications:Dash> Startup Applications> Add,添加命令:

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

说明

我们可以通过多种方式获得当前的Num Lock状态:

  • 运行命令:

     xset q 

    这将产生如下输出:

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

    或者使用命令:

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

    它简单地返回'on''off''unknown'

    由于后者非常轻,我们可以很好地在后台脚本中使用它来检查每秒一次,并'on'必要时使用以下命令将值设置为'on'

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

它确实……


编辑

出于某种原因,我错过了你的最后一段,你提到了另一个类似解决方案的答案。

从理论上讲,我总是遇到盲目 (重新)应用设置的脚本问题,而不检查当前状态。 如果命令, 可能存在这样做的争论

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

获得当前价值,只需运行就会更加苛刻

 numlockx on 

(重新) 设置 numlockx on
看两个命令需要完成的时间(这至少是一个指示),然而另一种方式; 命令

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

似乎更“轻盈”。

运行后台脚本是个坏主意?

当然,如果你没有理由运行后台脚本,那就不要了。 同时, 如果后台脚本编写良好,经过全面测试,则可以巧妙地优化程序, 如果它不会对处理器占用产生任何明显的影响,那么如果它增加了重要性就不能用作解决方法function或节省您的时间。

我经常运行至少4-8个后台脚本。 其中大部分都没有重启几周 。 从来没有注意到我的老人系统有任何影响。 请记住,您的系统无论如何都要运行多个循环。