Я уже физически удалил ограничение клавиши Num Lock, таким образом, я случайно не нажимаю его (я использую очень компактную клавиатуру). Но я понимаю, что существует ошибка в Xorg, который переключает Num Lock к off
когда я переключаю раскладку клавиатуры.
Таким образом, мне нужно что-то, что или предотвращает Num Lock "прочь" вообще, или альтернативно (возможно, легче?) контролирует, Num Lock указывают, и включает его, как только это замечает, что это "выключено".
Вот ответ Unix, который, кажется, обращается к этому, но для LXDE. Что я должен был бы сделать, чтобы заставить эту идею работать в Ubuntu 15.04 и Единице?
Я не знаю, как контролировать или запросить состояние Num Lock, или как программно изменить состояние Num Lock, но здесь являюсь решением, которое использует простой сценарий, который работает все время. Это кажется, что работало бы, но я не уверен, что умно иметь то выполнение все время?
Самое чистое должно было бы, конечно, исправить ошибку, но как обходное решение, фоновый сценарий ниже сделает задание:
#!/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
Если все хорошо работает, добавьте его для Запущения Приложений: Тире> Приложения Запуска> Добавляют, добавляют команду:
/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'
, при необходимости, с командой:
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
кажется, более "легок".
Конечно, если у Вас нет причины запустить фоновый скрипт, затем не делайте. В то же время, если фоновый сценарий правильно написан, полностью протестированный, процедуры энергично оптимизированы, и если бы он не добавляет значимого эффекта на размещение процессора, было бы глупо не использовать в качестве обходного решения, если он добавляет важную функциональность или экономит Вам время.
У меня постоянно есть, по крайней мере, фоновое выполнение сценариев 4-8. Большинство из них в течение многих недель без перезапуска. Никогда не замечал эффекта, в моей пожилой системе (системах). Следует иметь в виду, что Ваша система выполняет многочисленные циклы так или иначе.