GNOME Bugzilla – Bug 589557
Ctrl+<key> sends erroneous value when primary keyboard layout is not English
Last modified: 2011-01-11 08:58:11 UTC
If the primary XKB layout is not the standard US(English), Ctrl+<key> sends erroneous values when the active layout is set to US(English). Steps to reproduce: In GNOME Terminal: 1. Run setxkbmap -symbols "pc+in(ben_probhat)+us:2+inet(evdev)+group(shifts_toggle)" 2. Press both shift keys together to switch to secondary US layout 3. Press Ctrl+l Expected Results: Screen should get cleared Actual Results: The character ল appears on screen.
Created attachment 139124 [details] [review] Patch to fix the issue. The patch works for me. I am not sure why the group value was hardcoded to 0.
This patch also works for me. I'm using Fedora 13 with "USA Dvorak" as my first layout (group 0) and with "USA" as my second layout. With the attached patch all keys correctly match the selected layout regardless of modifiers for gnome-terminal just as it is for all applications other than gnome-terminal. I'd like to add my speculation as to why the "Force 0 group (English)" (before the attached patch) change was made. But I'd also like to argue in favor of the attached patch which undoes the "Force 0 group (English)" change. Although I can't find a good link now a few years ago I recall people arguing in forums that the muscle memory behind hotkey (with modifiers) was harder to relearn than ordinary keys (without modifiers). So when faced with a new layout people would learn to type "C" faster than they would learn Ctrl-C to copy text. So the argument was that people could have their primary layout as group 0. They could then switch to some new layout but still use the same old hotkeys. My objections to the above argument are: 1) It's confusing to people like me who have already invested time learning both layouts in their pure form. 2) Even if I liked the "Force 0 group (English)" change since I use dvorak for group 0 (the first layout) it makes it difficult for me to quickly modify my computer so that non-dvorak users can type on my computer. 3) It's different than the way layouts work in non-Linux operating systems such as Windows and OS/X. Those operating systems apply the layout regardless of modifiers. 4) It's confusing to have gnome-terminal behave differently than other Linux applications such as Firefox and gedit. So, I think the attached patch should be applied. It's a one line change that has been tested by at least two people. If something like "Force 0 group (English)" is to be done in should be done at the X-Server level for all applications at once and it should be made optional.
I applied Sayamindu's patch to vte-0.25.91 and it fixed the problem. Now we have 3 people who have confirmed the solution, so please accept this patch into upstream already!
The code comes from bug 375112; have you checked that the patch here doesn't regress that bug?
You are correct Christian. I tried the Ukraine layout and observed that this patch re-exposes bug 375112. I will try writing a new patch that checks the post-translation key: If the key is in the ASCII range, pass it through (as event->group). Otherwise, use the keycode of the actual key that was pressed (as 0).
While writing the new patch, I discovered that the solution for bug 375112 makes an invalid assumption: it assumes that group 0 is the standard USA English QWERTY layout. I can easily violate this assumption by setting my keyboard layouts in this order: 1. USA Dvorak 2. USA 3. Ukraine Now, when group 3 Ukraine is active, Ctrl-U in gnome-terminal does not work because when you press Ctrl-U on a QWERTY keyboard which is virtually in Dvorak mode (in the viewpoint of the group 0 keymap translation), you are actually pressing Ctrl-G. So I ask you: is the solution for bug 375112 even valid? If so, we should document that the user must ensure that their first group matches their keyboard hardware exactly. Otherwise control key combinations will be mistranslated.
Created attachment 171117 [details] [review] Uses translated key if it is English. Falls back to group 0 translation otherwise.
My patch would be even better if the native_keyval calculation did not depend on groups defined in the user's keyboard preferences. Instead, if there was some way to access the keyboard hardware's native layout, then my patch would work correctly even if group 0 did not match the keyboard hardware's native layout. Please advise. Thank you.
A workaround for this entire problem is to NOT set up multiple layouts in GNOME's keyboard preferences dialog. Instead, use the setxkbmap command to manually switch between your desired keyboard layouts. For example: setxkbmap dvorak # switch to Dvorak setxkbmap us # switch to QWERTY The downside is that you no longer get the nice GUI keyboard layout switcher in the notification area (system tray), but the upside is that your desired keyboard layout functions correctly in all applications, including gnome-terminal and compiz-fusion. Hope this helps.
If I understand correctly.... Confirming this under 0.23 (ubuntu lucid) from downstream at: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/204202 I for one run into this behavior without ever touching setxbmap. I just add two layouts (USA and USA Dvorak), a layout-switch key (Shift+Caps) under the layout options, and go. So, in gnome-terminal I can type the first 4 keys on the home row: $ aoeuaoeuaoeu<ctrl-C> $ then hit <shift+caps>: $ asdfasdfasdf<ctrl-C> No command 'asdf' found, did you mean: Command 'asdfg' from package 'aoeui' (universe) Command 'sadf' from package 'sysstat' (main) Command 'sdf' from package 'sdf' (universe) asdfasdfasdf: command not found This is the behavior that would happen if I hit <ctrl-J>, which is the 'C' key under a qwerty layout. So effectively, when I switch from Dvorak back to US (so that a co-worker can use my computer for a few moments), their Ctrl-keys are are mixed up and unusable in the terminal only, while they work correctly in all other Gnome/gtk/X applications. Do the patches available address this problem? Is there anything blocking this issue getting corrected?
Jeremy, I'm also a USA and USA Dvorak user. Since you mentioned "setxkmap" I thought I'd mention that it provides a workaround - use "setxkmap us" and "setxkmap dvorak" as an alternative to the GNOME utility. I think the attached patch named "Patch to fix the issue" fixes the issue. See my previous comment for my speculation about why it works the way it does, and why I think it should be fixed.
I vote for the patch named "Patch to fix the issue" as well.. Currently, I have to use this patch manually in all of my gentoo setups.
Should be fixed in master. Please test.
I wasn't able to test master, but I tested your changes against 0.26.2 and they fixed the problem. Thanks a lot!