Forwarding this bug from Ubuntu reporter Michael Terry: http://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/985065 [Problem] In Ubuntu, using the GUI capplet to add a new default layout does not actually change the key mappings. A libxklavier error from X is seen. [Original Description] This is a break-out bug from bug 960096. When you have fr/oss "French (alternative)" layout as your first layout, you end up with "us" instead. If you enable libxklavier debugging output, you'll see the following in your logs: "Unexpected by libxklavier X ERROR: 0x8351fb8, 163f0005, 2 [], X11 request: 145, minor code: 9" xkl_debug(200, "Unexpected by libxklavier X ERROR: %p, " WINID_FORMAT ", %d [%s], " "X11 request: %d, minor code: %d\n", dpy, (unsigned long) evt->resourceid, (int) evt->error_code, buf, (int) evt->request_code, (int) evt->minor_code); That 2 in there is the X error code, which means _XkbErrMissingTypes for xkbfile extension. I assume 145 is the major op code that got assigned for the XKBFile extension. If so, 9 is the X_kbSetMap request. Which all fits with an error trying to set the new layout map. DistroRelease: Ubuntu 12.04 Package: xorg 1:7.6+12ubuntu1 ProcVersionSignature: Ubuntu 3.2.0-23.36-generic-pae 3.2.14 Uname: Linux 3.2.0-23-generic-pae i686 .tmp.unity.support.test.0: ApportVersion: 2.0.1-0ubuntu4 Architecture: i386 CheckboxSubmission: 9a284f3f6b4f7829abbe27ad9573a709 CheckboxSystem: 3935143777c965daaa64b51f0134f712 CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell] CompositorRunning: compiz Date: Wed Apr 18 12:31:05 2012 DistUpgraded: 2011-11-05 19:49:52,977 DEBUG enabling apt cron job DistroCodename: precise DistroVariant: ubuntu DkmsStatus: virtualbox, 4.1.12, 3.2.0-23-generic-pae, i686: installed EcryptfsInUse: Yes ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu GraphicsCard: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 18) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device [1558:3100] InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release i386 (20110422) Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub MachineType: System76, Inc. Lemur UltraThin ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic-pae root=UUID=0e585e80-16f1-404c-80cc-7d9805fcc3b0 ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: Upgraded to precise on 2011-11-05 (164 days ago) dmi.bios.date: 11/11/2010 dmi.bios.vendor: Phoenix Technologies LTD dmi.bios.version: CALPELLACRB.86C.0000.X.0000000000 dmi.board.asset.tag: Tag 12345 dmi.board.name: Lemur UltraThin dmi.board.vendor: System76, Inc. dmi.board.version: lemu2 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: System76, Inc. dmi.chassis.version: lemu2 dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrCALPELLACRB.86C.0000.X.0000000000:bd11/11/2010:svnSystem76,Inc.:pnLemurUltraThin:pvrlemu2:rvnSystem76,Inc.:rnLemurUltraThin:rvrlemu2:cvnSystem76,Inc.:ct10:cvrlemu2: dmi.product.name: Lemur UltraThin dmi.product.version: lemu2 dmi.sys.vendor: System76, Inc. version.compiz: compiz 1:0.9.7.6-0ubuntu1 version.libdrm2: libdrm2 2.4.32-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu3 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu3 version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu10 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2
Let me see if I'm reproducing everything properly. I've added the French (alternative) layout as first listed before US. After rebooting, the indicator menu shows French (alternative) selected. setxkbmap looks correct: xkb_keymap { xkb_keycodes { include "evdev+aliases(azerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+fr(oss)+us:2+inet(evdev)" }; xkb_geometry { include "pc(pc105)" }; }; xprop -root | grep XKB looks ok _XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "fr", "oss", "" _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "fr,us", "oss,", "" And gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd shows fr oss: options = [terminate terminate:ctrl_alt_bksp] layouts = [fr oss,us] not sure why there's a double-space between 'fr' and 'oss' there. Might be relevant? Anyway, despite all this the layout behavior is still US-style. For instance, the 'm' key prints an 'm' whereas with fr oss I gather it should be printing an ','. Then I run sudo dpkg-reconfigure keyboard-configuration. I select "Generic 105-key (Intl) PC", "French", "French - French (alternative)", "The default for the keyboard layout", and "Right Alt (AltGR)" for compose key. After this, the keyboard seems to be working in fr oss mode. 'm' prints ',' and other keys seem remapped differently. However I notice the indicator menu icon shows 'en' (but clicking on it shows 'French (alternative)' - so that's inconsistent.) Logging out, the login screen's indicator shows fr/French (alternative). Logging in still shows fr/French (alternative), however checking on a gnome terminal window, 'm' is back to printing 'm' instead of ',' Aside from running dpkg-reconfigure, hand editing /etc/default/keyboard and then running `sudo udevadm trigger --subsystem-match=input --action=change` also works around the problem. `setxkbmap fr oss` works around it for the session. Attached is a script that summarizes some keyboard configuration details.
Created attachment 60291 [details] kbd-debug
See the LP bug for two runs of the above tool. It appears that the difference between doing the change using setxkbmap and the GUI tool is: @@ -18,7 +20,7 @@ xkb_types { include "complete" }; xkb_compat { include "complete" }; - xkb_symbols { include "pc+us+inet(evdev)+compose(ralt)" }; -+ xkb_symbols { include "pc+fr(oss)+inet(evdev)+compose(ralt)" }; ++ xkb_symbols { include "pc+fr(oss)+us:2+inet(evdev)" }; xkb_geometry { include "pc(pc105)" }; }; @@ -29,6 +31,6 @@ xkb_types "complete" { xkb_compatibility "complete" { -xkb_symbols "pc+us+inet(evdev)+compose(ralt)" { -+xkb_symbols "pc+fr(oss)+inet(evdev)+compose(ralt)" { ++xkb_symbols "pc+fr(oss)+us:2+inet(evdev)" { xkb_geometry "pc(pc105)" { However, I'm not certain of the significance of these values.
Note that we're carrying a few patches in Ubuntu which may (or may not) be relevant: To xklavier: * we're reverting one change via revert-default-group-change.patch (See https://bugs.freedesktop.org/show_bug.cgi?id=47671) * Carrying one upstream patch, backport of commit 28cb7b7e (See https://bugs.freedesktop.org/show_bug.cgi?id=46416) To gnome-settings-daemon: * Complete list: http://paste.ubuntu.com/936362/ * ... * 61_unity_use_application_indicator.patch * revert_git_stop_using_gconf.patch * revert_git_use_gsetting_keybindings.patch
Note that while this can be reproduced using fr oss, it seems other keyboard layouts are affected. I haven't exhaustively tested all of them, but enough to see it's a larger issue than just a bug with fr oss.
> not sure why there's a double-space between 'fr' and 'oss' there. Might be relevant? It is not a double space, it is a tab char IIRC. > ++ xkb_symbols { include "pc+fr(oss)+us:2+inet(evdev)" }; g-s-d always adds "system" layout - from gdm. So if your gdm has 'us' layout, it is added as a 2nd one. I just wonder where you lost the compose(ralt) option... Could you please attach 2 results: 1. Configure fr(oss) in normal gnome way, add 'us' as a 2nd layout (all through GUI). Then, do xkbcomp :0 -xkb out_gnome.xkb 2. Just do "setxkbmap -layout fr,us -variant oss, -option Then, do xkbcomp :0 -xkb out_manual.xkb I want to compare the files
Created attachment 60403 [details] out_gnome.xkb
Created attachment 60404 [details] out_manual.xkb
Thank you! They are amazing! The out_gnome.xkb shows something unbelievable: > xkb_symbols "pc+fr(oss)+us:2+inet(evdev)" { So, I would expect 1st group being fr(oss) and 2nd group us. But in reality that is the other way aroung... :( Could you please set XKL_DEBUG=200, restart g-s-d and then capture stdout of g-s-d. It should should the keymap file it produces (somewhere in /tmp) and keep that file. After that, I would be interested in getting that keymap file.
Created attachment 60506 [details] stdout Not sure I did this correctly, as I didn't find any files created in /tmp after restarting gsd, however here is the stdout from killing it and then running /usr/lib/gnome-settings-daemon/gnome-settings-daemon
I guess, you rerun g-s-d in the same session, right? In that case g-s-d did not have to configure the keyboard - because it was already tuned to the same config. Would you be able to run g-s-d at the session startup with XKL_DEBUG=200 - so it would actually have to change XKB configuration? In that case, something should appear in /tmp
Created attachment 60914 [details] Xorg.0.log Forcing recompilation of the xkb keymaps...
Created attachment 60915 [details] server-3B1E7EC017335DF19FF0A1742B988209FD2FAB9E.xkm
Created attachment 60916 [details] server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm
Looking at the code, no intermediate .xkb file is created to disk; it's passed directly from memory to xkbcomp. Btw, if you want to experiment more directly, you can snag ubuntu-12.04-dvd-i386.iso.torrent (or ubuntu-12.04-dvd-i386.iso) from http://cdimage.ubuntu.com/releases/12.04/release/ and burn to a USB stick using USB disk creator).
Unfortunately both xkm files are useless - they contain single us group ("xkbcomp foobar.xkm -xkb out.xkb"). Regarding the keymap file, in libxklavier: if (xkl_debug_level < 500) { /* don't remove on high debug levels! */ if (remove(xkm_fn) So I was wrong - the file stays with debug level > 500. But it really looks like a bug in Xorg server - it is against any rules, to switch the groups. out_gnome.xkb IMNSHO clearly indicates that.
Not sure if I got it right but I got 2 files in /tmp here * one text file with "xkb_keymap { xkb_keycodes { include "evdev+aliases(azerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+fr(oss)+gb:2+inet(evdev)+group(shift_caps_toggle)" }; xkb_geometry { include "pc(pc105)" }; };" and one binary which I'm adding next
Created attachment 61755 [details] g-s-d generated file the layout configured at fr (oss) by default and english (uk)
let me know if you need extra details, that bug is really annoying since it means french users can't change their layout using keybindings or the applet,indicator, using setxkbmap works though
To me it looks like a bug in the server. Look at the file out_gnome.xkb provided by bryce: ... xkb_symbols "pc+fr(oss)+us:2+inet(evdev)" { ... key <AD01> { type[group1]= "ALPHABETIC", type[group2]= "FOUR_LEVEL_ALPHABETIC", symbols[Group1]= [ q, Q ], symbols[Group2]= [ a, A, ae, AE ] }; ... So, symbols are screwed, fr is supposed to be in the 1st group, but in reality they are in the second group (American Qwerty vs French A) At the same time, the xkm file attached by Sebastien, once converted to xkb ("xkbcomp in.xkm -xkb out.xkb") has: ... xkb_symbols "pc+fr(oss)+gb:2+inet(evdev)+group(shift_caps_toggle)" { ... key <AD01> { type[group1]= "FOUR_LEVEL_ALPHABETIC", type[group2]= "FOUR_LEVEL_SEMIALPHABETIC", symbols[Group1]= [ a, A, ae, AE ], symbols[Group2]= [ q, Q, at, Greek_OMEGA ] }; ... Which is correct! So, once that xkm file is fed into X server, it swaps the groups. At least that's the only explanation I can give, for now. If everyone agrees with that, I would forward that bug to xorg server, Input/XKB component. If someone has better ideas - please let me hear them!
Sergey, reassigning works for me, I don't know enough about X handling of keyboards layouts to have an opinion on whether the bug is in the server or in the lib
Created attachment 61788 [details] out_gnome.xkb Since I'm not sure I've the same config that Bryce I'm attaching the xkb output files from my config as well, they look different
Created attachment 61789 [details] the manual one
Created attachment 61793 [details] the same gb instead of us since that's the keymap configured here (fr oss, gb)
Downgrading libxklavier, libgnomekbd and gnome-settings-daemon to the oneiric version doesn't fix the bug which would confirm the issue is not coming from those but rather from xorg
Keyboard-related patches in Ubuntu's xserver: 13_debian_add_xkbpath_env_variable.diff http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=blob_plain;f=debian/patches/13_debian_add_xkbpath_env_variable.diff;hb=refs/heads/ubuntu 190_cache-xkbcomp_output_for_fast_start_up.patch http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=blob_plain;f=debian/patches/190_cache-xkbcomp_output_for_fast_start_up.patch;hb=refs/heads/ubuntu 208_switch_on_release.diff http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=blob_plain;f=debian/patches/208_switch_on_release.diff;hb=refs/heads/ubuntu On the theory that the bug is in the server, next step is probably to try with each of these patches disabled in turn. 190 directly affects xkbcomp loading so would be the one to test first.
Tested with 190 disabled, but still same fault. While patch 208 is a keyboard patch, it really has nothing to do with this. Patch 13 is from debian and is quite ancient (from 2006), so doubting that's going to be the cause of all this. So, if this is indeed an xserver bug, I think it may be reproducible in the upstream codebase. Guessing that's the next step...
Daniel, is there any chance you could look at that issue?
Ok, so as an additional piece of info the issue happens as well on a fedora 17 liveCD so it's not an Ubuntu patch or an issue specific to a distro
@seb, do you have a bug ref. for the fedora 17 issue?
@bryce: no, I tested the same steps on a f17 liveCD myself and commented there, do you think it warrants a new report?
This seems very similar to bug 43541 https://bugs.freedesktop.org/show_bug.cgi?id=43541 Is this not the same bug ? I had the exact same symptoms.
The patch from https://bugs.freedesktop.org/show_bug.cgi?id=43541#c12 fixes the issue indeed
closing, the patch from the other bug fixes the issue and got commited
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.