GNOME Bugzilla – Bug 126956
Ctrl-[A-Z] doesn't generate proper escape in non-latin keyboard layouts
Last modified: 2008-01-31 22:15:43 UTC
I have two xkb layouts loaded -- the standard US layout, and a Russian layout. When I'm in the US layout, everything is fine. However, in the Russian layout, pressing Ctrl-A (say) will produce the same result as just pressing the A key. This is bad, since it impairs usability (I have to switch layouts just to Ctrl-C an app...); this behavior isn't exhibited by any other terminal I've tested (rxvt, xterm, eterm). I cannot currently check it in 2.4/0.11, but I've examined the source, and found no notable changes. Nor have I found any bugs to this effect. So, I believe this is still most likely an issue. It looks like the attached (soon) patch should apply without major issues to vte 0.11.10. It is a bit of a hack, in that it has to go through GTK's abstraction of keyboard groups, whereas native X terminal apps get the real key much more naturally. However, I didn't find a better way, and this works fine for me.
Created attachment 21439 [details] gzipped proposed patch
Hello! Nalin, could you please take a look at the patch? The bug is still present in vte 0.11.11/gt 2.6.1, and the patch still squashes it well. I'm attaching one with the line numbers readjusted, so that it applies cleanly. In case the problem isn't clear, please do the following: 1) pull up a vte widget (gt or vte) IMPORTANT: If you are using an xkb set-up other than the standard US keyboard layout (which I show how to restore below), be sure you know how to get back to your keyboard settings. The command line should be similar. 2) Set a 2-keyboard layout with Caps lock switching between US QWERTY and Russian typewriter: shell$ setxkbmap -print us,ru -option grp:caps_toggle | xkbcomp - $DISPLAY 2) Test a Ctrl-Letter keystroke. For instance, run: shell$ cat ^C shell$ 3) Do the same in xterm. It works. 4) Hit Caps Lock to switch to Russian. 5) In vte, repeat the Ctrl-Letter test. You should find that you get a Russian letter instead (or nothing, if your system is not configured for Russian or Unicode). In particular, you don't get a Ctrl-C sent. 6) Do the same in xterm. It _still_ works. CONCLUSION: vte has a problem. 7) Apply the patch. Observe that vte now behaves correctly. 8) To go back to US layout, run: shell$ setxkbmap -print us | xkbcomp - $DISPLAY
Created attachment 28528 [details] [review] Patch for generating proper Ctrl-[A-Z] codes in non-latin kerboard layouts.
corrections in title, os, version, etc; sorry for spam.
*** Bug 132833 has been marked as a duplicate of this bug. ***
The proposed patch is ugly for a number of reasons. 1) It fixes one particular case, leaving the deeper problem unsolved. Russian users will probably be OK, but what about others? 2) It tries-and-picks translation, voodoo style, in four groups (who guarantees there's always no more than four?), ignoring event->group altogether. 3) It uses default display to get the keymap, ignoring the effective display. Actually, the problem seems to be that the received GdkEventKey contains non- or mistranslated keyval. Here's what the documentation on gdk_keymap_translate_keyboard_state() says: For convenience, GdkEventKey already contains the translated keyval, so this function isn't as useful as you might think. Anyone care to enlighten me why it could go wrong?
I agree that the patch is ugly. Four groups are guaranteed by the standards behind this: gdk/windows has at most 2 groups, gdk/x (limited by X) has at most 4. I think the deeper problem is that VTE does too much of the OS's job in handling keyboard input. I mean, there's already an ugly hack for *producing* the Ctrl-characters in the regular case. As far as the display goes, I think I must have been lazy or unaware of how to get the effective display. This should be changed, and I'll do it if the patch is mergeable in spite of the other problems. If someone could fix this properly, it would be wonderful. I've been quite happy using my patch for the past year, so I will have trouble bringing myself to look at it right away. However, I will be happy to test whatever ideas you code up.
Incidentally, I did run a number of tests with different XKB configurations, and my patch matched xterm's behavior in all of them. Can you find a bad case? I'm mostly worried about CJK, and other complex scripts that may rely on XIM stuff. But, I have no easy means of testing that.
Any news on this? Is it "ugly-but-we-can-live-with-it" or "ugly-enough-to-need-reworking"?
It's ugly in that it doesn't solve the problem. It does provide a kludge for the Russian layout to work, probably at the expense of others. The proper solution, as it seems to be, is to fix the incoming GdkEventKey in the first place.
First of all, the patch does fix all XKB layouts I've tested, not just Russian (and I tried quite a few combinations) So, as long as the keycode -> character conversion was done via XKB, we should be fine. However, you're right in that it doesn't fix the underlying problem. For instance, the input code right now has a kludge to produce Ctrl-[A-Z] keycodes even in the English case. This is bad, because we're duplicating X functionality: all normal programs don't worry about this conversion. I personally think the input code needs refactoring. Odds are that I won't be able to work on it anytime soon, though. Any takers?
Marking patch as needs-work since it's a workaround and probably not suited for inclusion in it's current form.
Any progress with this bug? The upstream version of GTK has been retaining it for the last trhee years.
Second the "any progress?" question. This bug also affects people who want to use Dvorak or other non-broken ;-) keyboard layouts. xev reports those correctly. Why should gnome-terminal muck about with the key bindings in the first place, anyway? If control mappings are wrong, that's a keymap problem which should be fixed *there*.
My expertise around layouts is quite limited. CC'ing a couple experts.
This particular bug seems to be a duplicate of bug 162726, so I'm marking it as such. *** This bug has been marked as a duplicate of 162726 ***