After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 375112 - ctrl-key combinations yielding just key
ctrl-key combinations yielding just key
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.14.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-11-14 14:25 UTC by samo
Modified: 2009-03-14 15:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch proposed by the submitter (1.49 KB, patch)
2007-05-16 20:22 UTC, Loïc Minier
committed Details | Review

Description samo 2006-11-14 14:25:32 UTC
this happens if one types ctrl-a in, say, cyrrilic keyboard layout.

it comes as cyrrilic 'a'. Same for all other keys.

it happens in ver9 (as of ubuntu-edgy-latest), as well as in a just compiled v14.1.
i am on locale:CP1251; xkb: bg-phonetic.

here a debug output, pressing ctrl+ Cyrillic_ya, then plain Cyrillic_ya:
$ export VTE_DEBUG_FLAGS=KEYBOARD,EVENTS

Keypress, modifiers=0x2000, keyval=0xffe3, raw string=`'.
Keypress, modifiers=0x2004, keyval=0x6d1, raw string=`я'.
Mapping Control+GDK_Cyrillic_ya (ignoring, no map for key).
Keypress, modifiers=0x2004, keyval=0x6d1, cooked string=`СЏ'.
Sending <ffffffff> to child.
Keypress, modifiers=0x2000, keyval=0x6d1, raw string=`я'.
Input method committed `СЏ'.
Sending <ffffffff> to child.
Keypress taken by IM.
Keypress, modifiers=0x2000, keyval=0xffe9, raw string=`'.


============
in both cases, ffffffff is sent (Cyrillic_ya code in cp1251) 
note Control+GDK_Cyrillic_ya is recognised as such, but plain Cyrillic_ya is not recognised as GDK_Cyrillic_ya (!). 

Control+GDK_Cyrillic_ya should be ctrl-Q, as Cyrillic_ya is on Q key.

At X level all is fine. xterm is ok; all other gtk-graphicals are ok.
seems The mapping of ctrl+ (non-latine-key) into ctrl+(latine-key) is gone, or never made.
it's same case on several machines using gtk/vte; and happens ONLY in vte-related terminals/windows - gnome-term, xfce-term, synaptics-internal-term, and also gvim. Any other gtk editors work ok.

IMO these key-presses should not go up to GDK-level, as mapping them back to whatever ctrl+key can be a pain.

or is it some xkb/im /gdk/gtk setting?

-------------

another thing, using libvte, i cannot in any way get ctrl-home and ctrl-end through to the shell inside (and have them different from plain home/end). 
any idea apart of hack-the-source? gtk-mapping? X-mapping? 
i can do it in xterm via *xterm xrdb entries...
Comment 1 samo 2006-11-15 12:14:58 UTC
eventual patch: may or may not be completely valid in all cases; 
it's re-translating the key, reseting the group to 0

/usr/src$ diff -w -u  z/vte-0.14.1/src/vte.c vte-0.14.1/src/vte.c
--- org/vte-0.14.1/src/vte.c      2006-10-02 23:41:11.000000000 +0300
+++ vte-0.14.1/src/vte.c        2006-11-15 14:10:59.000000000 +0200
@@ -4056,6 +4057,33 @@
                /* If we didn't manage to do anything, try to salvage a
                 * printable string. */
                if (!handled && (normal == NULL) && (special == NULL)) {
+
+                       if (event->group &&
+                           (terminal->pvt->modifiers & GDK_CONTROL_MASK)) //maybe ALT too?
+                       {
+                           guint akeyval;
+                           gint aeffective_group;
+                           gint alevel;
+                           GdkModifierType aconsumed_modifiers;
+                           gdk_keymap_translate_keyboard_state( 0,
+                                   event->hardware_keycode, event->state,
+                                   0, //ignore group
+                                   &akeyval,
+                                   &aeffective_group,
+                                   &alevel,
+                                   &aconsumed_modifiers );
+#ifdef VTE_DEBUG
+                           if (normal && _vte_debug_on(VTE_DEBUG_EVENTS))
+                               fprintf(stderr, "ctrl+Key, group=%d de-grouped into keyval=0x%x\n",
+                                   event->group, akeyval );
+#endif
+                           keyval = akeyval;
+                       }
+
                        /* Convert the keyval to a gunichar. */
                        keychar = gdk_keyval_to_unicode(keyval);
                        normal_length = 0;
Comment 2 Loïc Minier 2007-05-16 20:22:15 UTC
Created attachment 88309 [details] [review]
Patch proposed by the submitter
Comment 3 Loïc Minier 2007-05-16 20:23:40 UTC
I'm attaching a patch I received privately based on patch proposed by the submitter.

I'm not confident enough in my understanding of the internals to add the patch directly to the Debian packages; would someone be so kind to review the proposed change?
Comment 4 Chris Wilson 2007-05-22 08:45:53 UTC
After staring at the patch and bug report, a glimmer of understanding dawned.
The remaining doubt is what other modifiers do we need to take into account? (Marking as resolved until proven otherwise ;-)

r1893: 2007-05-22  Chris Wilson  <chris@chris-wilson.co.uk>

	Bug 375112 – ctrl-key combinations yielding just key
	Original patch by <samo@altern.org> and refactored by Loïc Minier.

	* src/vte.c (vte_translate_national_ctrlkeys),
	(vte_terminal_key_press):
	    When cooking a string to pass through to the client obtain the
	    "raw" keyval.

Comment 5 Péter Szabó 2009-03-14 14:24:06 UTC
Is it possible to make this feature (i.e. calling vte_translate_national_ctrlkeys()) configurable? I have a dual Hungarian--US English keyboard layout with Hungarian being the default. In the Hungarian layout the keys Y and Z are switched with respect to the US English layout. So when I have the Hungarian layout active, one of the keys yields the string "z", but when I press that key with Ctrl, I get "^Y", instead of what I expect ("^Z"). All other applications (e.g. GIMP, Firefox, xterm) work as expected, except for those using VTE, because VTE has the vte_translate_national_ctrlkeys() function, which converts my Ctrl-Z event to a Ctrl-Y.

Please make this feature configurable. Thanks.
Comment 6 Péter Szabó 2009-03-14 14:26:20 UTC
I've verified it that If I remove the call

  keyval = vte_translate_national_ctrlkeys(event)

from vte.c, the problem is solved.
Comment 7 Christian Persch 2009-03-14 15:30:20 UTC
Please don't add comments to closed bugs; they'll simply get lost. Instead, just open a new bug and refer to the old bug in it.