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.

intika
  • 13,920
  • 7
  • 41
  • 79
Stuck
  • 151
  • 7
  • 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) –  Jan 08 '20 at 20:31
  • @mosvy: thanks, I added the output to the question as UPDATE 2 – Stuck Jan 08 '20 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. –  Jan 08 '20 at 21:23
  • Same behavior in virtual terminal (ctrl-alt-f3) and in `sudo sh` – Stuck Jan 08 '20 at 21:30
  • 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 08 '20 at 21:40
  • 1
    @mosvy you should post an answer summarizing this (for the bounty) – intika Jan 09 '20 at 12:26
  • I had a call with the tech support of the manufacturer and they also think its a hardware defect because the external one is fine - fortunately it's in warranty-time and I will get a new keyboard and see if this works. – Stuck Jan 09 '20 at 19:41
  • @intika I'm really not sure if this is not a driver or firmware glitch instead -- maybe there's someone with similar or identical hardware out there who can confirm. I would suggest the OP to change the title to include the laptop model. –  Jan 12 '20 at 13:31
  • @mosvy such bug on the drivers should be fixed on the windows version... i don't think it's the case ;) (not impossible but very rare) what's most evident is a hardware issue as the op suggested... OR – intika Jan 12 '20 at 17:41
  • or @Stuck i already have a similar case when the keyboard wire is not well connected to the motherboard – intika Jan 12 '20 at 17:41

1 Answers1

2

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

intika
  • 13,920
  • 7
  • 41
  • 79
Stuck
  • 151
  • 7