7

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.

  • 3
    it would help if you tried to run xev and see what happens exactly when you press Alt on the laptop's keyboard (both mouse and keyboard events) – mosvy Jan 8 at 20:31
  • @mosvy: thanks, I added the output to the question as UPDATE 2 – Stuck Jan 8 at 20:54
  • 3
    looks like depressing the Alt key (64) really also pulls the < key (94) after it. FWIW, this is not a gnome-terminal, xkb or terminfo/curses problem. Try switching to a virtual terminal (Ctrl-Alt-F3, etc) or running a root shell and check (with showkey) if pressing the Alt key also generates another unrelated keycode event. – mosvy Jan 8 at 21:23
  • 3
    Since I have a dual boot, I also tested in windows 10 and it's also the same behavior. A friend of mine thinks it could be a short circuit in the keyboard hardware. – Stuck Jan 8 at 21:40
  • 1
    @mosvy you should post an answer summarizing this (for the bounty) – intika Jan 9 at 12:26
2

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

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.