| Summary: | kxkb doesn't work with xfree-4.3 (uses wrong symbols dir) | ||
|---|---|---|---|
| Product: | [Unmaintained] kxkb | Reporter: | Lubos Lunak <l.lunak> |
| Component: | general | Assignee: | Andriy Rysin <arysin> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bzt, thiago |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
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. |
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.