Layout xkb options are not cleared during propagation

[ya-solnyshko]

Qubes OS release

4.1.2 (R4.1)

Brief summary

Keyboard switching pollutes setxbmap options, eventually messing up the key mappings.

Steps to reproduce

1. Configure multiple keyboard layouts in dom0, e.g., I use the following settings in /etc/X11/xorg.conf.d/00-keyboard.conf:

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "us,ru"
        Option "XkbVariant" "altgr-intl,winkeys"
        Option "XkbOptions" "nodeadkeys,grp:alt_shift_toggle"
EndSection

2. Start any VM. The state of setxkbmap -print -query is:

user@disp1372:~$ setxkbmap -print -query
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(evdev)+group(alt_shift_toggle)"	};
	xkb_geometry  { include "pc(pc105)"	};
};
rules:      evdev
model:      pc105
layout:     us
options:    nodeadkeys,,grp:alt_shift_toggle

3. Switch keyboard layout with Alt+Shift:

user@disp1372:~$ setxkbmap -print -query
....
rules:      evdev
model:      pc105
layout:     ru,us
variant:    ,
options:    nodeadkeys,,grp:alt_shift_toggle,nodeadkeys,,grp:alt_shift_toggle,nodeadkeys,,grp:alt_shift_toggle

4. Switch a couple of times more:

user@disp1372:~$ setxkbmap -print -query
...
rules:      evdev
model:      pc105
layout:     us
options:    nodeadkeys,,grp:alt_shift_toggle,nodeadkeys,,grp:alt_shift_toggle,nodeadkeys,,grp:alt_shift_toggle,nodeadkeys,,grp:alt_shift_toggle,nodeadkeys,,grp:alt_shift_toggle

Expected behavior

Normal layout switching.

Actual behavior

1. First, options get more and more polluted after each layout switch.
2. Second, after many layout switches, the keycode mapping breaks (perhaps some overflow of options?): the arrow buttons, delete button, and some others get remapped to something random. For example, according to xev, the key Up turns into Print: keycode 111 (keysym 0xff61, Print), same_screen YES
3. Fixing the layout with xmodmap -e "keycode 111 = Up" fixes the mapping until the next Alt+Shift, then it is messed up again. Resetting the options with setxkbmap -option doesn't help.

It seems that there is some competition between dom0 and the vm itself for handling the keycodes

[jamke]

The keyboard layout switching is broken since R4.1. It is not working properly for me too.
But I do not see the same behavior that you have with options getting longer and polluted.

1. What do you have in xfce: Settings Manager -> Keyboard -> Layout tab?
   You probably should see Use system defaults being checked and other controls disabled, is it your case?

2. Can you try the same without nodeadkeys option in the first place?

[ya-solnyshko]

Hi,

1. Yes, it is set to Use system defaults.
2. It indeed helps, Alt+Shift now toggles between

user@private:~$ setxkbmap -print -query
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+ru(winkeys)+us:2+inet(evdev)+group(alt_shift_toggle)"	};
	xkb_geometry  { include "pc(pc105)"	};
};
rules:      evdev
model:      pc105
layout:     ru,us
variant:    winkeys,
options:    grp:alt_shift_toggle

and

user@private:~$ setxkbmap -print -query
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us(altgr-intl)+inet(evdev)+group(alt_shift_toggle)"	};
	xkb_geometry  { include "pc(pc105)"	};
};
rules:      evdev
model:      pc105
layout:     us
variant:    altgr-intl
options:    grp:alt_shift_toggle

Even "variant" is set correctly now. I am still wondering though, why it toggles between "ru,us" and "us", this doesn't happen in dom0

[jamke]

It indeed helps, Alt+Shift now toggles between

Glad it helped.
It's probably a bug in the script that parses options, that's why uncommon nodeadkeys breaks it, real bug.

About your question of layout toggling: starting from at least R4.1 the toogle works in dom0 as is (not changing xkb options) while on any change the event of changing is caught and the current layout is passed (propagated) to the qubes (VMs) manually by script. So, I think, it does not matter much what layout list is set, only the current layout should be correct, because on each toggle xkb settings will be changed any way. Something like that.

More info on this topic:
#8035
#6517
#8035 (comment)

[solardiz]

options get more and more polluted after each layout switch.

This was happening for me too, when the options on dom0 include more than one option (comma-separated). The below appears to fix it. More testing is needed, but at least this change is correct per the man page and it shouldn't hurt.

+++ /usr/lib/qubes/qubes-keymap.sh	2023-07-09 15:00:38.085000000 +0200
@@ -21,7 +21,7 @@
     fi
 
     if [ -n "$KEYMAP_OPTIONS" ]; then
-        KEYMAP_OPTIONS="-option $KEYMAP_OPTIONS"
+        KEYMAP_OPTIONS="-option -option $KEYMAP_OPTIONS"
     fi
 
     # Set layout on all DISPLAY

       -option name
               Specifies the name of an option  to  determine  the  components
               which  make  up the keyboard description;  multiple options may
               be specified, one per -option flag. Note  that  setxkbmap  adds
               options  specified in the command line to the options that were
               set before (as saved in root window properties). If you want to
               replace  all previously specified options, use the -option flag
               with an empty argument first.

[solardiz]

I am still wondering though, why it toggles between "ru,us" and "us", this doesn't happen in dom0

This is explained in QubesOS/qubes-gui-agent-linux#139 - it doesn't appear to hurt in your case, does it?

[marmarek]

Thanks @solardiz ! So, together with #8035 (comment), I think now we know how to fix layout switching finally :)

[solardiz]

together with #8035 (comment), I think now we know how to fix layout switching finally :)

That other discussion looks like an alternative way to fix the issue. In this script, we can try simply omitting KEYMAP_OPTIONS.

[marmarek]

That other discussion looks like an alternative way to fix the issue. In this script, we can try simply omitting KEYMAP_OPTIONS.

Omitting completely is a bad idea, since some options do remap keys (things like compose key for example).