Skip to content

Layouts relying on symbols/pc do not work correctly when used in a multi-layout keymap

If a layout relies on symbols/pc for some of its keys and it is combined with a layout that overrides those symbols, the missing keys won't get defined. symbols/pc is only applied to Group1, so Group2 layouts have missing keys.

Testcase

The easy test case is LSGT when combining us(intl) (defines LSGT) and latam (relies on pc for the default mapping):

$ setxkbmap -print -layout "latam,us,us(intl)" | xkbcomp -xkb - - | grep -A4 LSGT
    key <LSGT> {
        type= "FOUR_LEVEL",
        symbols[Group1]= [            less,         greater,             bar,       brokenbar ],
        symbols[Group2]= [            less,         greater,             bar,       brokenbar ],
        symbols[Group3]= [       backslash,             bar,       backslash,             bar ]

latam and us rely on the symbols/pc mapping for LSGT, us(intl) defines its own. Now the same layout set but in different order:

$ setxkbmap -print -layout "us(intl),latam,us" | xkbcomp -xkb - - | grep -A4 LSGT
    key <LSGT> {
        type= "FOUR_LEVEL",
        symbols[Group1]= [       backslash,             bar,       backslash,             bar ]
    };

Only Group1 is defined, the others disappear resulting in the key no longer working.

Source of the issue

If we look at the components to be included:

$ setxkbmap -print -layout "latam,us,us(intl)"
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+latam+us:2+us(intl):3+inet(evdev)+level3(ralt_switch)+compose(caps)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

The bug here appears to be that pc is only ever used on the first group, if I change the xkb_symbols to the snippet below and cat that to xkbcomp, the layout looks correct again.

xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us(intl)+pc:2+latam:2+pc:3+us:3+inet(evdev)+level3(ralt_switch)+compose(caps)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

Note the pc:2+latam here - we force pc to be the default for group2 as well.

This appears to be an upstream bug with the rules handling:

! model         layout                  =       symbols
  ...
  *             *                       =       pc+%l%(v)

! model         layout[1]              =       symbols
 ...
 *             *                       =       pc+%l[1]%(v[1])

! model         layout[2]       =       symbol
  ...
  *             *               =       +%l[2]%(v[2]):2

Groups 3 and 4 have effectively the same line as Group 2.

Analysis

I think this is a bug in the rules rather than a parser, because even with just us,latam, we only get Group1 defined, so the key would not work while on Group2. cc @bluetech anyway for another opinion. I reckon adding pc:2 to the rules should fix this issue, will be interesting to see side-effects.

External links