second layout gets mixed up with third-level of first layout

[Bogdan Butnaru]

Binary package hint: gnome-settings-daemon

(Hardy, up-to-date.) I'm having a very weird bug in how keyboard layouts are handled. This didn't happen until some recent point in Hardy.

I have two keyboard layouts selected in my keyboard preferences. The first is a Dvorak layout that uses AltGr as a third-level chooser to type some extra characters in my native language. The second is the standard French layout (which is the physical layout of the keys); I only use it when other people need to use my computer, which is why I don't know exactly when the problem started. When I login, the first layout is selected by default. I use the keyboard indicator 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 a previous bug (different) that happened after login but stopped after cycling (unsetting&resetting) the relevant keyboard option.

[Sebastien Bacher (seb128)]

Thank you for your bug report. Do you still have the issue on hardy? Maybe you could open the bug directly on bugzilla.gnome.org, upstream know how to debug such keyboard issues better usually

[Tristan Schmelcher (tschmelcher)]

This looks like a dupe of bug 196277.

[Bogdan Butnaru (bogdanb)]

@Sebastien: Yes, it still happens unfortunately. I'll try to send this upstream.

@Tristan: It looks like the same behavior in Yomamem's post, but it seems that what the original poster of that bug described was different.

[Bogdan Butnaru (bogdanb)]

Not sure how to link it directly, here's the bugzilla link: http://bugzilla.gnome.org/show_bug.cgi?id=532938

[Pedro Villavicencio (pedro)]

linking the report, thanks you.

[Vincent Untz (vuntz)]

With some configuration, a login in GNOME can result in a broken keymap. Note that it only happens when there's no "interaction" with X before gnome-settings-daemon starts to play with XKB (where interaction means keyboard or mouse button usage).

Long discussion happening here: https://bugzilla.novell.com/show_bug.cgi?id=369263

[Vincent Untz (vuntz)]

Created an attachment (id=16737)
"xkbcomp -xkb :0 -" output before g-s-d starts

[Vincent Untz (vuntz)]

Created an attachment (id=16738)
"xkbcomp -xkb :0 -" output after g-s-d is started

[Vincent Untz (vuntz)]

To easily reproduce the bug:
 + apply the gconf dump from https://bugzilla.novell.com/attachment.cgi?id=212640 (with gconftool-2 --load)
 + enable GDM or KDM autologin (or timed login)

The latter is important since if you don't do that, then you will use your keyboard to enter the login/password and the bug does not occur anymore.

I can help debugging this, of course.

[Vincent Untz (vuntz)]

Created an attachment (id=16739)
"xkbcomp -xkb :0 -" output with autologin

Ok, forget about attachment 16738. Don't know why, but it looks broken. Here's the real broken version :-)

[Vincent Untz (vuntz)]

Created an attachment (id=16740)
"xkbcomp -xkb :0 -" output with normal login

And here's the xkbcomp dump when I don't use autologin.

[Vincent Untz (vuntz)]

All the previous dumps were done with the default group being 1. If I make the default group 0, then I get the same dumps, it seems.

(also note that I'm not using the exact same gconf config as in the novell bug -- I'm having 4 groups)

[Antonio Zugaldia (antonio-zugaldia)]

Related: http://bugzilla.gnome.org/show_bug.cgi?id=532938

Any information you need?

[Pedro Villavicencio (pedro)]

according to the upstream report, this is more like a xorg issue, re assigning, thanks.

[Peter Hutterer (peter-hutterer)]

Vincent:

can I have a look at your xorg.conf and log file please? At the moment it
looks like gnome sets azerty, but your keyboard inits with querty. We need to
find out why that is so.

[LKRaider (paul-eipper)]

Happens here, but there is no workaround as the OP mentions, it never works for me.

I have a laptop configured with Portuguese ABNT2 model/layout and installed an external usb US keyboard.

I go to keybord properties, add a new layout (US intl with dead-keys), add the layout switching panel, change the layout through the panel, and all typing is in third-level (as with altgr pressed).

Even removing and adding again the layout does not fix it.

Only way to get a new layout working is with "setxkbmap us intl", which loads the correct layout for the usb keyboard.

Also, I'm not using autologin, as reported on other bugs.

[Vincent Untz (vuntz)]

(In reply to comment #8)
> Vincent:
>
> can I have a look at your xorg.conf and log file please? At the moment it
> looks like gnome sets azerty, but your keyboard inits with querty. We need to
> find out why that is so.

So my system changed quite a lot since last time. Anyway, I will attach the files. Note that my X was probably never configured to be qwerty by default.

[Vincent Untz (vuntz)]

Created an attachment (id=17886)
xorg.conf

[Vincent Untz (vuntz)]

Created an attachment (id=17887)
Xorg.0.log (compressed because too big, sorry)

[Peter Hutterer (peter-hutterer)]

Probably the same reason as 16364, don't have a solution yet though.

[Peter Hutterer (peter-hutterer)]

Could have been fixed with the commits leading up to c06e27b2f6fd9f7b9f827623a48876a225264132. We saw similar issues in Fedora and they are all fixed now (by the above commits).

And the hack as proposed in Bug 16364 of course.

[Bryce Harrington (bryce)]

According to the upstream bug report, this was fixed some time ago. If it still occurs on precise, please reopen the bug and run the command 'apport-collect 206281'