The following configuration cannot be loaded to XKB: xkb_keymap { xkb_keycodes { include "evdev+aliases(azerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+fr(bepo)" }; xkb_geometry { include "pc(pc105)" }; }; Trying to run "xkbcomp bepo.map :0", getting some odd error: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 146 (XKEYBOARD) Minor opcode of failed request: 9 (XkbSetMap) Value in failed request: 0x163f0005 Serial number of failed request: 115 Current serial number in output stream: 121 At the same time, loading "setxkbmap -layout fr -variant bepo" works fine. Similarly, compiling map file to .xkb first, then loading to X server - works fine as well.
It seems the issue is with FOUR_LEVEL_X type: commenting it from symbols/keypad(ossmath) out helps. But I do not see anything wrong...
bisecting, the issue started from http://cgit.freedesktop.org/xkeyboard-config/commit/?id=062b5bfcc59f9f6e4e11ba394bbe459af2a07b7e The questions is what's wrong with that code?
just for the archives, I had a quick run through gdb on this, the failure point is xkb/xkb.c:1697. It fails because the wire width of the key (5) is different to the map width of the type (4). Why this is the case I cannot say at this point but since it does work when the whole keymap is submitted I suspect it's either xkbcomp encoding it badly or the server being out of sync somewhere.
For the record, globally changing CTRL+ALT to CTRL+ALT5 (to avoid any hardcoded type behavior) did not fix the issue
> 2011BRB_Reviewed Any news on this?
No, sorry. This is a nasty bug that will require some time to fix. It is not very high on the priority list and keeps getting pre-empted.
Sergey V. Udaltsov, can you please try editing /usr/share/X11/xkb/symbols/keypad ? Go to the section describing "ossmath", comment line saying : “ key.type[Group1]="FOUR_LEVEL_X" ;” and tell us if the bug still appears ? I have absolutely no idea how xkb files are working or what this line is supposed to do, but I managed to find out that it was what was causing me a very similar bug with “French(Alternative)” layout, and this section is included in both Bepo and “French(Alternative)” layout. Also note that removing this line does not prevent this section from taking effect, it seems. AltGr + * still does some nice ×, by example.
Problem is in the xkm format or conversion. Using the keymap in comment #0: $> xkbcomp -xkb /tmp/keymap keymap.xkb $> xkbcomp keymap.xkb $DISPLAY # Success $> xkbcomp -xkm /tmp/keymap keymap.xkm $> xkbcomp keymap.xkm $DISPLAY # BadValue Server tested: xorg-server-1.12.0-209-g4c68f5d
Peters, so what would you advise? What is wrong about that keymap?
tbh, I don't think this is a keymap issue, I think this is somewhere inside xkbcomp or the xkm parsing.
> tbh, I don't think this is a keymap issue, I think this is somewhere inside > xkbcomp or the xkm parsing. Agree. Not the first time xkm format causes troubles...
Created attachment 63276 [details] [review] 0001-symbols-ossmath-is-CTRL-ALT-not-FOUR_LEVEL-43541.patch Tested this again, and Jean-Alexandre was right, this is the fix. Must have had my keymaps confused yesterday. error triggered is: _XkbErrCode3(0x16, i + req->firstKeySym, wire->width); in CheckKeySyms(), with a firstKeySym of 63 <KPMU>, and wire->width of 5. The type currently assigned is FOUR_LEVEL, hence the error. This patch forces this section to use CTRL+ALT and thus a 5 level type, I've added VoidSymbols for the created hole. IMO it's better to spell out the type so it's more obvious than implying the type from the default symbols/keymap/x11 section. VoidSymbols need to be added to remain the special functions on CTRL+ALT instead of Shift+Alt (level4). As for why git bisect points to: 062b5bfcc59f9f6e4e11ba394bbe459af2a07b7e. The CTRL+ALT type was expanded from 3 to 5 levels in that commit and it's pulled in by the default section "x11". So before the default was 3 levels, ossmath did override it to 4. Now it's 5 levels by default and ossmath is missing symbols for that default. Why it's not forcing FOUR_LEVEL instead I don't know, maybe you can only grow from the default type? The downside of this: 062b5bfcc59f9f6e4e11ba394bbe459af2a07b7e affects any CTRL+ALT key with less than 5 symbols, so we're likely to see more bug reports on exotic layouts. This patch only fixes the ossmath section, but there are a bunch of other keymaps in there that need to be updated too. I'd like to see some fr(bepo) testing from the reporter first before we consider this.
I've tested that patch on Ubuntu precise, it fixes https://bugs.freedesktop.org/show_bug.cgi?id=48905 (impossible to change layouts in Unity or GNOME when "fr oss" is in use), great work!
pushed that fix, thank you! Let's see if more bug reports appear. Still, interesting question "Why it's not forcing FOUR_LEVEL instead I don't know, maybe you can only grow from the default type?" but that requires deep diving in x server xkb code, I'm afraid...
thanks. as I said in comment #12, this will affect any ctrl+alt key with < 5 symbols. these should all be fixed up now.
I checked, could not find any CTRL+ALT keys with < 5 levels.
AIUI, futuremath and ossmath_latin9 will have that issue since the keys are already assigned CTRL+ALT in the default section, the FOUR_LEVEL is ignored. hex may have the same problems too for KPMU/KPDV/KPSU. haven't tested this though.
> since the keys are > already assigned CTRL+ALT in the default section, the FOUR_LEVEL is ignored. Why aren't types overriden? Is that a bug?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.