Bug 43541 - X server cannot handle fr(bepo) layout
Summary: X server cannot handle fr(bepo) layout
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Daniel Stone
QA Contact: Xorg Project Team
URL:
Whiteboard: 2011BRB_Reviewed
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-05 17:49 UTC by Sergey V. Udaltsov
Modified: 2012-07-17 21:05 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
0001-symbols-ossmath-is-CTRL-ALT-not-FOUR_LEVEL-43541.patch (1.77 KB, patch)
2012-06-20 17:41 UTC, Peter Hutterer
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey V. Udaltsov 2011-12-05 17:49:05 UTC
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.
Comment 1 Sergey V. Udaltsov 2011-12-05 17:51:16 UTC
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...
Comment 2 Sergey V. Udaltsov 2011-12-11 14:26:39 UTC
bisecting, the issue started from http://cgit.freedesktop.org/xkeyboard-config/commit/?id=062b5bfcc59f9f6e4e11ba394bbe459af2a07b7e

The questions is what's wrong with that code?
Comment 3 Peter Hutterer 2011-12-11 15:23:52 UTC
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.
Comment 4 Sergey V. Udaltsov 2011-12-12 16:20:25 UTC
For the record, globally changing CTRL+ALT to CTRL+ALT5 (to avoid any hardcoded type behavior) did not fix the issue
Comment 5 lsof 2012-04-04 09:50:53 UTC
> 2011BRB_Reviewed

Any news on this?
Comment 6 Peter Hutterer 2012-04-15 23:41:56 UTC
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.
Comment 7 Jean-Alexandre Anglès d'Auriac 2012-06-18 09:44:56 UTC
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.
Comment 8 Peter Hutterer 2012-06-19 17:31:08 UTC
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
Comment 9 Sergey V. Udaltsov 2012-06-20 00:03:45 UTC
Peters, so what would you advise? What is wrong about that keymap?
Comment 10 Peter Hutterer 2012-06-20 03:48:35 UTC
tbh, I don't think this is a keymap issue, I think this is somewhere inside xkbcomp or the xkm parsing.
Comment 11 Sergey V. Udaltsov 2012-06-20 03:50:58 UTC
> 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...
Comment 12 Peter Hutterer 2012-06-20 17:41:42 UTC
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.
Comment 13 Sebastien Bacher 2012-06-25 07:26:51 UTC
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!
Comment 14 Sergey V. Udaltsov 2012-06-26 13:26:36 UTC
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...
Comment 15 Peter Hutterer 2012-06-26 15:00:15 UTC
thanks. as I said in comment #12, this will affect any ctrl+alt key with < 5 symbols. these should all be fixed up now.
Comment 16 Sergey V. Udaltsov 2012-06-27 16:27:22 UTC
I checked, could not find any CTRL+ALT keys with < 5 levels.
Comment 17 Peter Hutterer 2012-06-28 16:21:12 UTC
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.
Comment 18 Sergey V. Udaltsov 2012-07-17 21:05:00 UTC
> 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.