GNOME Bugzilla – Bug 532938
second layout gets mixed up with third-level of first layout
Last modified: 2008-07-08 16:54:13 UTC
Please describe the problem: I'm having a very weird bug in how keyboard layouts are handled: I have two keyboard layouts selected in my keyboard preferences. The first is a custom Dvorak layout, the second is the standard French layout (which is the physical layout of the keyboard). Both use AltGr as a third-level chooser to type some extra characters. When I login, the first layout is selected by default. I use the keyboard indicator applet and a shortcut key to switch between the two when needed. Here's the weird part: The first layout works perfectly. All keys behave as they should, and when I keep AltGr pressed the third level is selected correctly. When I switch to the second (Fr) layout, however, the keyboard indicator correctly shows "Fr", but the characters typed are those of the third level of the first layout. (I.e., switching to Fr is functionally equivalent to holding AltGr pressed.) If I enter keyboard properties, remove the French layout, and add it again, everything works correctly until I restart. I'm not sure what causes this issue. I've tentatively assigned it to gnome-settings-daemon, because I've seen other previous bugs that happened after login but stopped after cycling (unsetting&resetting) the relevant keyboard option, which have been solved in g-s-d. Steps to reproduce: 1. Enable two keyboard layouts, both having some third level keys. Enable the keyboard indicator applet on the panel, too. 2. Reboot & log-in. 3. Run gedit and type something using the default layout; use the third level too. 4. Change the layout using the keyboard indicator applet. 5. Try typing in gedit again. Actual results: The character typed in step 5 are those from the third level of layout 1. Expected results: I should type characters from the first level of layout 2. Does this happen every time? Yes. Other information: First reported on Ubuntu Hardy: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/206281
1. Does it happen the same way if you activate layout using setxkbmap utility (without GNOME). If so, it is NOTGNOME 2. Would you do xkbcomp :0 -xkb out.xkb and attach the file here?
1) I'm not sure how comparison with setxkbmap would help. The keyboard layouts work correctly after I set them in the keyboard properties; it is after the first reboot that the bug manifests itself, which is why I assigned this to gnome-settings-daemon. I think there's a problem with restoring settings, not with setting keyboard properties specifically. Again, for clarity: the applet sets keyboard settings correctly. It is after a reboot that things fail (thus a failure of the automatic set-up, not the manual one). 2) Heh, what do you know. This is what I get if I run that line: $ xkbcomp :0 -xkb out.xkb Warning: Could not load keyboard geometry for :0 BadAlloc (insufficient resources for operation) Resulting keymap file will not describe geometry However, if I open gnome-keyboard-properties, delete both layouts, then add them again, it worked. (I'll attach the file right away.) This confirms my suspicion that the config applet works, but the saved settings are not restored correctly on reboot.
Created attachment 110923 [details] the output demanded, _after_ the keyboard layouts were removed&re-added manually Note that this is the keyboard state _after_ I used gnome-settings-daemon to remove and re-add the keyboard layouts I use. Thus this is the “working” state. In the state after a reboot, the command given (xkbcomp) doesn't work. Also note that this “working” state also has some problems (e.g., ctrl+c and ctrl+d don't work as expected), but that's probably another bug.
Wouldy you please attach xorg.conf as well?
Created attachment 110946 [details] as requested, xorg.conf Sure, here it is. In case you'll be wondering, layout “bb” is a custom layout I wrote for myself, I'll attach it too in case it's needed.
Created attachment 110947 [details] My primary layout In case the bug is related to something in this layout.
Hmm, I just noticed something interesting. I tried to replace my bb/fr configuration with a us:dvorak/fr layout pair. (Just in case some thing is wrong with my layout.) I did that change in gnome-keyboard-properties. It worked OK when I changed it. But when I re-started the computer, and what do you know, the bug happens again. Guess what? After the reboot&login, the layout that was active was the one in xorg.conf (i.e., bb, attached above), and it behaved exactly as above. Something tells me that (1) X can't load my layout for some reason and (2) gnome-keyboard-properties forgets to load it at login. For some reason.
Oh, another funny thing. After running "setxkbmap", with no arguments, the layouts I selected in gnome-keyboard-properties are installed correctly. I.e. $ setxkbmap -print xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us(dvorak-intl)+fr(oss):2+group(sclk_toggle)+level3(ralt_switch)+ctrl(swapcaps)" }; xkb_geometry { include "pc(pc105)" }; }; I'll try to see if that happens for my layout, too.
This is what is shown after I setup my layout correctly in gnome-keyboard-properties: $ setxkbmap -print xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+bb+inet(latitude)+fr(oss):2+group(sclk_toggle)+level3(ralt_switch)+ctrl(swapcaps)" }; xkb_geometry { include "pc(latitude)" }; }; Typing the first five letters of my home-row, (a) with my first layout, (b) with my first layout and AltGr pressed, (c) with my second layout without AltGr: aoeui âșțăî qsdfg After a reboot: $ setxkbmap -print xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+bb+inet(latitude)+fr(oss):2+group(sclk_toggle)+level3(ralt_switch)+ctrl(swapcaps)" }; xkb_geometry { include "pc(latitude)" }; }; aoeui âșțăî âșțăî After running once setxkbmap: $ setxkbmap $ setxkbmap -print xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+bb+inet(latitude)+fr(oss):2+group(sclk_toggle)+level3(ralt_switch)+ctrl(swapcaps)" }; xkb_geometry { include "pc(latitude)" }; }; aoeui âșțăî qsdfg So it would seem that setxkbmap always sees the layouts I've chosen, but it's not run at start-up.
Ok, I am slightly lost here. First, if you use standard layouts only (in both xorg.conf and GNOME) - does it work or not? The last thing I would waste my time on is debugging broken xkb layouts in GNOME bugzilla (there is freedesktop.org and other places for it).
If by standard layout you mean only those in the standard distribution, yes, it happens even if I use only those. For example, I set-up the keyboard with us:intl in xorg.conf and us:altgr-intl & fr in Gnome. (I put a slightly different layout in xorg.conf to allow us to make the difference between who sets up each configuration.) After making that config, before rebooting, I get the first four keys of the home row (as before, using us, us with altgr pressed, and fr respectively): asdf áßðf qsdf Also, the apostrophe in US mode (set using the keyboard panel applet) is a dead key only with AltGr pressed (which is the behavior of us:altgr-intl). After a reboot, I get: asdf áßðf áßðf apostrophe is dead key (behavior of us:intl) After running "setxkbmap": asdf áßðf qsdf apostrophe is dead key if altgr is pressed (us:altgr-intl) Which has the same diagnostics, i.e. gnome-keyboard-applet sets up the layouts correctly, but after a reboot only the xorg.conf layout is active, and it's spread onto the third level, too. (Though the description of the bug is slightly inaccurate, in retrospect; I didn't notice it was the xorg layout that was interfering when I filed this bug.) For completeness: $ setxkbmap -print xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us(altgr-intl)+fr:2+group(sclk_toggle)+level3(ralt_switch)+ctrl(swapcaps)" }; xkb_geometry { include "pc(pc105)" }; }; I also noticed this happening with keyboards that don't have a third level (i.e. they don't use AltGr, but the effects are less interesting in that case, as the second line is empty.) That said, I think it'd be a valid gnome bug even if it only happened with a custom layout, since it _does_ work partially, so there's a bug at least in error handling (which is always slightly dangerous since it might conceivably be exploitable if it's caused by a buffer overrun or the like, and this one deals with the X server).
Sorry for delay. Do you use autologin in gdm or startx?
I'm coming to this bug report from Ubuntu (https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/206281). I've a fresh Ubuntu 8.04 installation, up to date, and I've got the same problem. I do not have any custom configs or keyboard layouts. These are my steps to reproduce the problem: - Add the Keyboard Indicator (2.22.2) to the top panel. - Right click -> Keyboard Preferences -> Layouts. - Add a new layout -- my case: one default, Spanish, one secondary, French. Close. - Open gedit and type "antonio" with the Spanish layout, you get "antonio" as expected. - Click in the keyboard indicator and switch to French. You type "antonio" and you get "ænŧøn→ø". Ops. - Switch back to Spanish, it works well again. To "fix" it: - Right click -> Keyboard Preferences -> Layouts. - Remove French, add it again, and close. - Now you switch again to French and type "antonio", you get "qntonio", as expected.
Again, same question: do you use gdm autologin or startx? Also, would you try another experiment. Instead of using Keyboard Preferences, just type "setxkbmap" in command line. Would it fix the problem?
Yes, I use the gdm autologin. If I switch the layout with setxkbmap it works well: $ setxkbmap fr [qntonio] $ setxkbmap es [antonio]
That's well known issue with Xorg. NOTGNOME. For a final confirmation - would you switch (temporarily) autologin off and try to login "normally"? It should fix the issue for you. What about you, bogdanb@... ?
Confirmed, the issue is "fixed" if the autologin is disabled. Could you provide the link to the Xorg bug report? Thanks.
https://bugs.freedesktop.org/show_bug.cgi?id=16105
Confirming that disabling autologin removes the bug. Thanks for tracking the issue, you can probably mark it NOTGNOME now (I'm not sure if I should be doing that myself). Sorry for the delay, Sergey, I've been away from my laptop for a while.
No problem.