Commit 15baf341 authored by Bastien Nocera's avatar Bastien Nocera
Browse files

keyboard: Prevent potential infinite loop

XKB would notify us in the same way if the lockedMods
changed because of a programmatic, or a physical/human change.

This causes us changing the Num-Lock state generating another
event on top of the one we just processed, and might cause
infinite loops and 100% CPU usage.

Instead, we now only apply the settings:
- on startup
- when remember-num-lock is changed to true

https://bugzilla.gnome.org/show_bug.cgi?id=679151
parent 882d41ae
......@@ -1233,10 +1233,11 @@ settings_changed (GSettings *settings,
g_strcmp0 (key, KEY_BELL_MODE) == 0) {
g_debug ("Bell setting '%s' changed, applying bell settings", key);
apply_bell (manager);
} else if (g_strcmp0 (key, KEY_REMEMBER_NUMLOCK_STATE) == 0 ||
g_strcmp0 (key, KEY_NUMLOCK_STATE) == 0) {
g_debug ("Num-Lock state '%s' changed, applying num-lock state settings", key);
} else if (g_strcmp0 (key, KEY_REMEMBER_NUMLOCK_STATE) == 0) {
g_debug ("Remember Num-Lock state '%s' changed, applying num-lock settings", key);
apply_numlock (manager);
} else if (g_strcmp0 (key, KEY_NUMLOCK_STATE) == 0) {
g_debug ("Num-Lock state '%s' changed, will apply at next startup", key);
} else if (g_strcmp0 (key, KEY_REPEAT) == 0 ||
g_strcmp0 (key, KEY_INTERVAL) == 0 ||
g_strcmp0 (key, KEY_DELAY) == 0) {
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment