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 663779 - Alt/Meta/Mod1 broken again
Alt/Meta/Mod1 broken again
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
[fixed-next]
: 663917 665386 666055 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-11-10 15:43 UTC by Tobias Wolf
Modified: 2014-04-06 17:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (755 bytes, patch)
2011-11-15 08:16 UTC, Alexandre Rostovtsev
none Details | Review
proposed patch (second attempt) (2.43 KB, patch)
2011-11-18 08:40 UTC, Alexandre Rostovtsev
needs-work Details | Review
keymap: Treat ALT as META (1.60 KB, patch)
2012-05-12 16:53 UTC, Christian Persch
committed Details | Review
alt-meta.patch (2.43 KB, patch)
2013-04-25 18:14 UTC, Pacho Ramos
rejected Details | Review

Description Tobias Wolf 2011-11-10 15:43:01 UTC
Since commit ac943bf69a87c992cfde59c6720ef08fdd20e683 [1] to gtk+ I cannot use Alt+key combinations anymore.

This is reminiscnet of bug #601926 back in 2010.


[1] http://git.gnome.org/browse/gtk+/commit/?id=ac943bf69a87c992cfde59c6720ef08fdd20e683

author Michael Natterer <mitch@gimp.org>	2011-11-07 19:09:00 (GMT)
committer Michael Natterer <mitch@gimp.org>	2011-11-07 19:09:00 (GMT)
commit ac943bf69a87c992cfde59c6720ef08fdd20e683

gdk: exclude MOD1 from the virtual modifier mapping
which effectively nails down the MOD1 == ALT assumption that is valid
in all other parts of GTK+. After the modifier abstraction fixes for
OSX, the virtual mapping is now (correctly) used in more places, and
caused problems with the common default PC keyboard layout on X11 that
colocates ALT and META on the same key.
Comment 1 Michael Natterer 2011-11-10 15:53:45 UTC
You pasted me this commit in private mail:

http://git.gnome.org/browse/vte/commit/?id=b73782a28894e25ed146271f9d6c6775a6836199

This definitely can't work any longer for the common PC keyboard layout
that has MOD1 mapped to META. Pressing Alt will now always produce MOD1
and nothing else, because that's what all of GTK+ expects.

My commit from above essentially nails Alt == MOD1 and nothing else.

I don't think this can be fixed in GTK+. If you want Alt, use GDK_MOD1_MASK,
not META (which could also be mapped to whatever key).
Comment 2 Tobias Wolf 2011-11-10 22:43:58 UTC
I’ve tried the reverse of Behdad’s patch now (i.e., what was initially intended and then reverted) and it works now.

Maybe what Michael changed in GTK now is what was missing the last time?
Comment 3 Tobias Wolf 2011-11-10 22:50:32 UTC
I obviously don’t have a good grasp of what is going on and most of my last comment is wrong.

But it works when hardcoding Alt to Meta again, which is a truism. I’m not sure what the people with exotic layouts in the original bug say about that.
Comment 4 Behdad Esfahbod 2011-11-11 15:01:40 UTC
I'm in fact clueless as to what these should be.  Someone should check with the bug I was trying to fix.  There was legitimate reason for that change at the time.
Comment 5 Behdad Esfahbod 2011-11-11 15:02:01 UTC
And from the vte point of view, "whatever xterm does" is the right behavior.
Comment 6 Michael Natterer 2011-11-12 18:29:45 UTC
*** Bug 663917 has been marked as a duplicate of this bug. ***
Comment 7 Michael Natterer 2011-11-12 18:31:55 UTC
I am sure that if you want Alt, you use GDK_MOD1_MASK. GDK_META_MASK
is not going to work any longer.
Comment 8 Michael Natterer 2011-11-12 18:46:39 UTC
Essentially, they way VTE seems to map META to some key is totally broken.

META is not a key, it's a virtual modifier that can be on any of
MOD1..MOD4, and with the recent changes in GTK+ it can only work
if it is on one of MOD2..MOD4 because we now consistently treat
MOD1 as ALT, and took it out of the virtual modifier mapping.
Comment 9 Alexandre Rostovtsev 2011-11-15 08:16:31 UTC
Created attachment 201423 [details] [review]
proposed patch

This patch maps gdk's Meta and Alt both to vte's Meta. It should allow both people with standard PC keymaps and those who are using strange custom mappings (like in bug #601926) to use their favorite meta key in vte. In particular, it unbreaks vte Alt handling with gtk+-3.2.2.
Comment 10 Martin Pitt 2011-11-16 10:33:53 UTC
Confirmed that Alexandre's patch works for me, too. Thanks!
Comment 11 Rafał Mużyło 2011-11-18 02:37:39 UTC
There seems to be a little catch though.

While I'm not completely sure it's caused by this change, I have following problem:

in midnight commander (how many of you (still) use it ?), while i.e. alt-h works, alt-? (so alt-shift-/) doesn't.

I'm not sure (yet) if it's the -shift- part that matters.

I'm on Gentoo and already using patch from comment 9.
Comment 12 Alexandre Rostovtsev 2011-11-18 04:47:42 UTC
(In reply to comment #11)
> There seems to be a little catch though.
> 
> While I'm not completely sure it's caused by this change, I have following
> problem:
> 
> in midnight commander (how many of you (still) use it ?), while i.e. alt-h
> works, alt-? (so alt-shift-/) doesn't.

Observations:

1. With my vte patch and gtk+-3.2.2, alt-! (i.e. alt-shift-1) works correctly in mc.
2. With my vte patch and gtk+-3.2.1, alt-/ and alt-? (i.e. alt-shift-/) both work correctly in mc.
3. With my vte patch and gtk+-3.2.2, alt-/ and alt-? both fail in mc.
Comment 13 Alexandre Rostovtsev 2011-11-18 08:40:42 UTC
Created attachment 201649 [details] [review]
proposed patch (second attempt)

The problem with my first patch is that two functions in keymap.c (_vte_keymap_map and _vte_keymap_key_add_key_modifiers) in effect compared VTE_META_MASK to gdk key modifier by numerical equality, but since my patch made VTE_META_MASK into a compound mask, such comparison was no longer guaranteed to work.

The possible solutions were to either (1) rewrite parts of keymap.c to treat GDK_META_MASK separately fro GDK_MOD1_MASK; or (2) to introduce a new function to fix up gdk modifiers by ensuring that if any VTE_META_MASK bits are set, then all are set, which in effect again results in VTE_META_MASK being treated an indivisible mask.

I chose option (2) because it seemed simpler and much less likely to introduce errors.

With this patch, all shortcuts in midnight commander work correctly :)
Comment 14 Michael Natterer 2011-11-18 08:47:54 UTC
Again, if you really want META, then you cannot define it as constant,
because it isn't.

If you want ALT, use MOD1 mask.

If you *really* want META, take GDK_META_MASK and run it through
gdk_keymap_map_virtual_modifiers(), then check what bit was added,
the added bit will be in the range of MOD2...MOD5, but with latest
GTK+ it will *never* be MOD1.

Also, latest GTK+ will *never* give you GDK_META_MASK if META is colocated
with ALT and used to be triggered by MOD1.
Comment 15 Alexandre Rostovtsev 2011-11-18 09:53:29 UTC
(In reply to comment #14)
> Again, if you really want META, then you cannot define it as constant,
> because it isn't.
> 
> If you want ALT, use MOD1 mask.
> 
> If you *really* want META, take GDK_META_MASK and run it through
> gdk_keymap_map_virtual_modifiers(), then check what bit was added,
> the added bit will be in the range of MOD2...MOD5, but with latest
> GTK+ it will *never* be MOD1.
> 
> Also, latest GTK+ will *never* give you GDK_META_MASK if META is colocated
> with ALT and used to be triggered by MOD1.

Michael, the issue is that gtk's and a terminal's concepts of Meta do not match.

The gtk world is oriented towards modern PC hardware. "Normal" gtk applications are just expected to use MOD1, better known as Alt. And Meta is an alias for something weird in the MOD2..MOD5 range (formerly MOD1..MOD5), reserved for people with unusual tastes in keyboards.

By contrast, the terminal world is oriented towards old Unix machines. "Normal" terminal applications don't know about this new-fangled thing called "Alt". They know about "Meta", which they assume is a physical key like on the old Sun keyboards. Users of lesser keyboards are expected to assign a key (or maybe several keys) to output the Meta modifier.

And vte lives on the boundary between the gtk world and the terminal world. It needs to take keyboard input from gtk and transform it into terminal codes. And it must deal with users, some of whom expect Alt on their keyboard to correspond to Meta in their terminal, and others who expect the Windows key on their keyboard to correspond to Meta in the terminal.

tl;dr version: VTE_META_MASK != GDK_META_MASK, and for a good reason.
Comment 16 Yves-Alexis Perez 2011-11-18 09:55:01 UTC
Ok, so I'm an end-user, I'm using a vte based GTK (2) terminal, and I can't use my Alt key anymore. Aiui same thing will (or already does) happen to people using vte3 based terminals.

I'm not sure if the problem lies in GTK+ or in vte (and I don't really care), but could we have the previous behavior back?
Comment 17 Michael Natterer 2011-11-18 11:12:10 UTC
Alexandre, I understand completely. I'm just saying is that if you
want META to work, you have to use the right GTK+ API to figure where
it is. You would have to do exactly the same, only much more complicated,
with plain X11.

This has nothing to do with GTK+ having a different focus than good old
terminals where users expect Meta. Even if there is a Mata key on your
keyboard, you have to map MODn using the right API in order to figure
if Meta is pressed or not.

Users don't expect Alt to be Meta, they expect the terminal to do the right
thing whether or not they have Meta on Alt, or mapped it around to e.g.
the Windows key on purpose.

You can't hardcode it. And with latest GTK+ you need to special case
Alt == Meta *if* gdk_keymap_map_virtual_modifiers() fails to map
it to any of MOD2..MOD4.

I can't see from the attached patch if any part of vte calls the opposite
function gdk_keymap_add_virtual_modifiers(), but if it does, you are
probably fine with (MOD1 | META), otherwise you aren't.
Comment 18 Alexandre Rostovtsev 2011-11-18 17:48:58 UTC
(In reply to comment #17)

Thanks for the explanation!

> I can't see from the attached patch if any part of vte calls the opposite
> function gdk_keymap_add_virtual_modifiers(), but if it does, you are
> probably fine with (MOD1 | META), otherwise you aren't.

Vte calls gdk_keymap_add_virtual_modifiers() in vte_terminal_read_modifiers(), which is the function that extracts key modifiers from a GdkEvent. So using MOD1|META should be fine.
Comment 19 Aron Griffis 2011-11-28 03:32:06 UTC
This bug is affecting Fedora 16 users in both vte3 (for gnome-terminal) and vte (for roxterm and XFCE Terminal, possibly others). I think Alexandre's comment #18 means that the proposed patch should be applied. Is that right?
Comment 20 Mukund Sivaraman 2011-12-01 19:42:24 UTC
I'm on fully updated Fedora 16 with the following package versions:

vte-0.28.1-1.fc16.x86_64
gtk2-2.24.8-2.fc16.x86_64
Terminal-0.4.8-1.fc16.x86_64

This is the XFCE terminal in gtk2 land.

Noticed that with the recent gtk2 update, Emacs (-nw, i.e, console mode) meta key was not working, and alt was generally broken when using it to switch tabs in irssi. Upon searching and following a Debian bug, I arrived here.

I confirm that with the vte patch in comment #13, things work as normal again.
Comment 21 Tim Cuthbertson 2011-12-03 01:00:59 UTC
*** Bug 665386 has been marked as a duplicate of this bug. ***
Comment 22 Aron Griffis 2011-12-03 16:31:02 UTC
I'm finding there's still a problem with the vte patch in comment #13. I'm testing using the rpms from http://thm.fedorapeople.org/vte/ which include this patch. The Alt key works as expected now in XFCE Terminal and roxterm.

However the Windows key isn't working as it did prior to the gtk change. Attempting to bind win-t to open a new tab in XFCE Terminal results in the binding "<Mod4><Super>t" but it doesn't actually work. Instead "t" appears in the current terminal window.  I've tried various other incantations of "<Mod4>t" and "<Super>t" by editing the config file directly to no avail. Do we need another vte patch for this, or does something else need to change?
Comment 23 Alexandre Rostovtsev 2011-12-03 19:39:21 UTC
(In reply to comment #22)
> However the Windows key isn't working as it did prior to the gtk change.
> Attempting to bind win-t to open a new tab in XFCE Terminal results in the
> binding "<Mod4><Super>t" but it doesn't actually work. Instead "t" appears in
> the current terminal window.  I've tried various other incantations of
> "<Mod4>t" and "<Super>t" by editing the config file directly to no avail. Do we
> need another vte patch for this, or does something else need to change?

In Gentoo, I can reproduce this behavior with xfce terminal 0.4.8 both "prior to the change" (i.e. with gtk+-2.24.7 and unpatched gtk2-based vte-0.28.2) and "after the change" (i.e. with gtk+-2.24.8 and patched gtk2-based vte-0.28.2).

In other words, as far as I can tell, the vte terminal shortcuts Windows key handling quirk is not related to the gtk's Alt key handling change or to the vte patch in comment #13.
Comment 24 Alexandre Rostovtsev 2011-12-03 19:41:55 UTC
(In reply to comment #23)
> In other words, as far as I can tell, the vte terminal shortcuts handling

Typo: s/vte terminal/xfce terminal/
Comment 25 Matthias Clasen 2011-12-07 13:19:49 UTC
(In reply to comment #22)
> I'm finding there's still a problem with the vte patch in comment #13. I'm
> testing using the rpms from http://thm.fedorapeople.org/vte/ which include this
> patch. The Alt key works as expected now in XFCE Terminal and roxterm.
> 
> However the Windows key isn't working as it did prior to the gtk change.
> Attempting to bind win-t to open a new tab in XFCE Terminal results in the
> binding "<Mod4><Super>t" but it doesn't actually work. Instead "t" appears in
> the current terminal window.  I've tried various other incantations of
> "<Mod4>t" and "<Super>t" by editing the config file directly to no avail. Do we
> need another vte patch for this, or does something else need to change?

Can you show the output of xmodmap ?
Comment 26 Aron Griffis 2011-12-07 15:13:39 UTC
(In reply to comment #25)
> Can you show the output of xmodmap ?

Hi Matthias, thanks for taking an interest. Here's the output of xmodmap:

 xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):
 
 shift       Shift_L (0x32),  Shift_R (0x3e)
 lock        Caps_Lock (0x42)
 control     Control_L (0x25),  Control_R (0x69)
 mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
 mod2        Num_Lock (0x4d)
 mod3      
 mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
 mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

For a specific keybinding example, I have Super+t bound to create a new tab. This works in Fedora 15 in all of XFCE Terminal, roxterm and gnome-terminal. So it works for both gtk2 and gtk3. But it doesn't work in Fedora 16.

However I've done more experimentation, and here's what I've found:

 F15 twm + gnome-terminal WORKS
 F15 kwin + gnome-terminal WORKS
 F15 GNOME + gnome-terminal WORKS
 F15 KDE + gnome-terminal WORKS

 F16 twm + gnome-terminal WORKS
 F16 kwin + gnome-terminal WORKS
 F16 GNOME + gnome-terminal DOESN'T WORK
 F16 KDE + gnome-terminal DOESN'T WORK

In other words, the only time it doesn't work is when I have a full desktop environment running, either GNOME or KDE. However the xmodmap output never changes. It's always exactly what I pasted above, in all of the environments.

I realize this is now completely separate from the issue in this ticket. Please follow up to me personally (agriffis@n01se.net) if you have suggestions or let me know if I should open a new ticket. Thanks!
Comment 27 Matthias Clasen 2011-12-07 17:48:09 UTC
And just to clarify: 'WORKS/DOESN'T WORK' here refers to <Super>t triggering the configured action, or to editing the keybinding working as intended, or a combination or both ?
Comment 28 Aron Griffis 2011-12-07 20:52:10 UTC
(In reply to comment #27)
> And just to clarify: 'WORKS/DOESN'T WORK' here refers to <Super>t triggering
> the configured action, or to editing the keybinding working as intended, or a
> combination or both ?

I was referring to the triggering of the configured action. However attempting to edit the keybinding in gnome-terminal reveals something:

 F16 GNOME gnome-terminal keybinding attempt yields "Super+Hyper+T"
 ("<Hyper><Super>t" in gconf). The action doesn't work, instead I get
 "t" in the terminal window. Changing it in gconf to either "<Super>t"
 or "<Hyper>t" doesn't change the behavior.

 F16 twm gnome-terminal keybinding attempt yields the same
 "Super+Hyper+T" ("<Hyper><Super>t" in gconf). Just like running
 GNOME, the action doesn't work, instead I get "t" in the terminal
 window. HOWEVER in this case, changing it in gconf to "<Super>t" or
 "<Hyper>t" (either one) results in a working keybinding!

So in other words, the keybinding dialog doesn't result in a working binding in either GNOME or bare twm. However it is possible to manually get a working binding in twm, whereas it is impossible to get a working binding in GNOME.

Matthias, does any of this make sense to you? It's a frustrating mystery to me, especially since xmodmap doesn't show any differences between running with/without the GNOME environment.
Comment 29 Aron Griffis 2011-12-07 20:55:08 UTC
I should add that on F15, the Keyboard Shortcuts dialog yields "Super+T" (instead of "Super+Hyper+T" which seems broken on F16).  Additionally, as mentioned previously, the actions work on F15 in both GNOME and KDE.
Comment 30 Matthias Clasen 2011-12-07 21:05:55 UTC
(In reply to comment #28)

> Matthias, does any of this make sense to you? It's a frustrating mystery to me,
> especially since xmodmap doesn't show any differences between running
> with/without the GNOME environment.

Yes, thanks. I think we have a pretty good idea whats going wrong here.
Comment 31 Aron Griffis 2011-12-10 14:00:00 UTC
(In reply to comment #30)
> (In reply to comment #28)
> 
> > Matthias, does any of this make sense to you? It's a frustrating mystery to me,
> > especially since xmodmap doesn't show any differences between running
> > with/without the GNOME environment.
> 
> Yes, thanks. I think we have a pretty good idea whats going wrong here.

That sounds encouraging. :-)  Can you explain in a nutshell?
Comment 32 Christian Persch 2011-12-13 11:43:42 UTC
*** Bug 666055 has been marked as a duplicate of this bug. ***
Comment 33 Matthias Clasen 2011-12-15 13:08:04 UTC
(In reply to comment #31)

> That sounds encouraging. :-)  Can you explain in a nutshell?

http://git.gnome.org/browse/gtk+/commit/?id=9bf17a95e57dd0d223cf45e5e7332b7ef04134b7
Comment 34 Christian Persch 2011-12-19 13:46:17 UTC
Does that gtk commit fix vte, or is there any vte patch still required?
Comment 35 Matthias Clasen 2011-12-19 13:56:53 UTC
the vte patch is still required

the gtk commit fixes the accel cell renderer, ie accel editing in gnome-terminal
Comment 36 Ionut Biru 2012-03-19 18:46:41 UTC
(In reply to comment #34)
> Does that gtk commit fix vte, or is there any vte patch still required?

any news about including this fix into 0.32.1? since you just released 0.32 without including this fix.
Comment 37 Christian Persch 2012-03-27 12:42:39 UTC
Comment on attachment 201649 [details] [review]
proposed patch (second attempt)

I don't like this approach. The keymap handling should be left alone.

Instead, the modifiers should be mangled as they come out of the GdkEvent, ie. in vte_terminal_read_modifiers(). There, map to VTE_META_MASK whatever modifiers should map to it; perhaps as simple as testing GDK_META_MASK | GD_MOD1_MASK, or possibly as sophisticated as comment 14 suggests.
Comment 38 Christian Persch 2012-05-12 16:53:24 UTC
Created attachment 213924 [details] [review]
keymap: Treat ALT as META
Comment 39 Christian Persch 2012-05-29 20:17:00 UTC
Comment on attachment 213924 [details] [review]
keymap: Treat ALT as META

Pushed to vte-0-32 and vte-next.

Keeping this bug open because I'm not sure yet that this is in fact the best fix possible.
Comment 40 André Klapper 2012-08-20 11:49:33 UTC
[Patch committed, removing GNOME target.]
Comment 41 Pacho Ramos 2013-04-25 18:14:49 UTC
Created attachment 242449 [details] [review]
alt-meta.patch

We are still carrying this patch downstream on Gentoo, not sure if it could be reviewed for inclusion :/