Version: (using KDE Devel) Installed from: Compiled sources With XFree-4.3, kxkb offers incorrect variants for layouts. I don't actually understand exactly what's going on, but it's about like this: I have as a primary layout selected 'us' layout, with 'pc105' variant. Kxkb uses the following command to enable it : setxkbmap -rules xfree86 -model microsoftpro -layout us -variant pc105 The problem is, this command won't work, only after removal of the -variant option, or when using 'basic' as the variant. Adding -print to this setxkbmap command shows: xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc/pc(pc104)+pc/us(pc105)+inet(microsoftpro)" }; xkb_geometry { include "microsoft(natural)" }; }; The 'xkb_symbols' line AFAIK means that symbols are searched in /usr/X11R6/lib/X11/xkb/symbols/pc/ directory, while kxkb parses /usr/X11R6/lib/X11/xkb/symbols/ (i.e. not the pc/ subdir). The symbols file in symbols/pc/ has only one 'basic' variant, and the one from symbols/ dir has all variants that kxkb offers (and I've been told that files in symbols/* are obsolete). So kxkb should somehow find out it should parse symbols/pc/ files, not symbols/ . But I have no idea how.
The search path is correct. Note your xkb_symbols line contains pc/pc(pc104) and pc/us(pc105), which instruct xkb to read from /usr/X11R6/lib/X11/xkb/symbols/ subdirectory pc. Note even that the inet file that is mentioned is: /usr/X11R6/lib/X11/xkb/symbols/inet. I agree that there is a problem: if the pc105 variant will cause problems, kxkb should not offer it in the first place.
It seems to be a XFree86 4.3's configuration problem. Check this out: % setxkbmap 'us_intl' -print xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete+caps(internal)" }; xkb_compat { include "complete" }; xkb_symbols { include "us(pc104)+us_intl+group(switch)+ctrl(ctrl_aa)+altwin(left_meta_win)" }; xkb_geometry { include "pc(pc104)" }; }; % setxkbmap 'us_intl+inet(acpi)' -print xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete+caps(internal)" }; xkb_compat { include "complete" }; xkb_symbols { include "pc/pc(pc104)+pc/us_intl+inet(acpi)+group(switch)+ctrl(ctrl_aa)+altwin(left_meta_win)" }; xkb_geometry { include "pc(pc104)" }; }; Note that the second time, the pc/us_intl keyboard was tried, which doesn't even exist.
Maybe this is related to bug #55614?
Yes, it should be basically the same.
That's not a KDE bug, that's a new bug of XFree86-4.3 1) It exists under just X without KDE or any window manager. 2) If you substitute subtree /usr/X11R6/lib/X11/xkb/* in XFree 4.3 to that subtree from XFree 4.2 all works just fine (at least under FreeBSD). Yuri
Agreed, not a KDE bug per se (therefore maybe we should close the bug ticket). Thanks for the report. Anyways, I should mention that I did manage to find one more piece of information that might be of use: the xkb/rules/xfree86 file. XFree86 reads that file to find out what files exactly to read. For instance, now when doing a simple setxkbmap us_intl, it reads the pc/us_intl file because in the file I mentioned there's an entry more or less like this: * * pc/pc(pc104)+pc/%m(%l) thus it makes my keymap by concatenating pc/pc variant pc104 with pc/us_intl variant pc105.
this is due to new one-group layouts that are used in XFree86 4.3 if the layout is not defined in $oldlayouts in rules/xfree86 file then it's taken from symbols/pc/ directory rather than symbols/ This cuased wrong variants to be listed for some layouts (e.g. us) Now checking for layout in $oldlayouts list and behaving accodingly Please test and report if you still have problems.
*** Bug 55614 has been marked as a duplicate of this bug. ***
Works here. Thank you very much.