gnome-terminal – Fixing Strange Control Characters on Alt Key in gnome-terminal

control-charactersgnome-terminalkeyboard

I probably misconfigured something, but I don't know what. (see UPDATE 1 and 2 below) In gnome-terminal, when I hit Alt (without any other key), it immediately sends ^[< to the terminal (I tested by hitting Ctrl+V before Alt). Since I use Alt+Tab a lot, this is very unfortunate, because the control sequence will, for example, move to the beginning of history or do strange stuff in vim
The Alt+Tab, however,
does still work and cycles through the windows as wanted.

What might be the reason and how can I restore the default behavior in gnome-terminal?

  • OS: Linux Mint 19.3 Tricia x86_64
  • Kernel: 5.3.0-24-generic
  • Shell: bash 4.4.20
  • GNOME Terminal 3.28.1 using VTE 0.52.2 +GNUTLS -PCRE2

UPDATE 1

I found out that this happens only on the laptops keyboard itself, but not using an external attached usb keyboard. While the external keyboard is attached both Alt-keys behave differently.

The laptop is a Lenovo P53.

I still don't know how to fix it for the laptops keyboard but at least I am closer to the origins of the issue.

UPDATE 2
Running xev I shortly hit (pressed and immediately released) Alt a single time; first on the laptops keyboard and then on the external USB keyboard:

# LAPTOP KEYBOARD ALT-KEY

MappingNotify event, serial 39, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

KeyPress event, serial 39, synthetic NO, window 0x6a00001,
    root 0x2b6, subw 0x0, time 9398319, (162,-8), root:(903,449),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 39, synthetic NO, window 0x6a00001,
    root 0x2b6, subw 0x0, time 9398319, (162,-8), root:(903,449),
    state 0x18, keycode 94 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XmbLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x6a00001,
    root 0x2b6, subw 0x0, time 9398360, (162,-8), root:(903,449),
    state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x6a00001,
    root 0x2b6, subw 0x0, time 9398360, (162,-8), root:(903,449),
    state 0x10, keycode 94 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

# EXTERNAL USB KEYBOARD ALT-KEY

MappingNotify event, serial 40, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

KeyPress event, serial 40, synthetic NO, window 0x6a00001,
    root 0x2b6, subw 0x0, time 9402608, (162,-8), root:(903,449),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x6a00001,
    root 0x2b6, subw 0x0, time 9402704, (162,-8), root:(903,449),
    state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

UPDATE 3

It's probably a hardware defect (see comments and answer). I will get a new keyboard from the manufacturer.

Best Answer

It is a hardware defect and was confirmed by the manufacturer. Replacing the keyboard solved the issue. Thanks for helping to investigate!

Related Question