4

I've seen several other posts similar to this issue, but I've not had luck implementing a solution. If someone can find an existing post that resolves this issue, I will gladly mark this as a duplicate.

I'm not exactly sure on the timing, but perhaps within the past week or so, the equal key no longer types the equal sign (=). I have to copy and paste it to write this post.

The same symptoms extend to the onboard keyboard as well (not to be confused with the virtual keyboard which doesn't seem to have an equal key), so it's certainly not a hardware problem.

Shift + equal key still types the plus sign (+), but no key combination on the physical keyboard results in the equal sign (=) in web browsers and most other applications. The two exceptions with the physical keyboard I've found so far is with the GNOME Terminal. In the terminal, the combination of Ctrl or Windows key and equal key results in the equal sign. In addition, the Windows key and equal key types an equal sign in most text editors (LibreOffice Writer, Visual Studio Code, Xed text editor).

I can also use the equal key normally without a modifier key when in tty (Ctrl + Alt + F2). It's only within Cinnamon that I have the issue.

I only have one keyboard layout - English (US).

System Specs:

System:
  Host:       {HostName}
  Kernel:     5.3.0-28-generic x86_64
    bits:     64
    compiler: gcc
    v:        7.4.0 
  Desktop:    Cinnamon 4.4.8
    wm:       muffin
    dm:       LightDM
  Distro:     Linux Mint 19.3 Tricia 
    base:     Ubuntu 18.04 bionic 
Machine:
  Type:       Laptop
  System:     Acer
    product:  Aspire A717-72G
    v:        V1.19
    serial:   <filter> 
  Mobo:       CFL
    model:    Charizard_CFS
    v:        V1.19
    serial:   <filter>
  UEFI:       Insyde
    v:        1.19 
    date:     07/13/2018

There was a kernel update in the past few weeks. I have avoided rolling back the kernel to the previous version because I didn't want to start grasping at straws and getting myself into worse trouble, so I thought I'd post this first.

Updates:

This is exactly the issue I'm having, but this issue is in Windows.

I have rebooted several times and I have checked multiple modifiers multiple times for stuck keys, but to no avail. I messed with this for days before finally deciding to post the issue. If it was as simple as a reboot or stuck key, I would expect to have seen that resolve by now.

Using xev the following is revealed (I'm new to xev and still learning what this means):

Equal Key:

KeymapNotify event, serial 28, synthetic NO, window 0x0,
keys:  66  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
       0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

Example of All Other Keypresses I tried (i.e. Shift + equal key):

KeyPress event, serial 28, synthetic NO, window 0x7800001,
root 0x242, subw 0x0, time 11019227, (-650,-317), root:(211,139),
state 0x10, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
XLookupString gives 0 bytes: 
XmbLookupString gives 0 bytes: 
XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x7800001,
root 0x242, subw 0x0, time 11019779, (-650,-317), root:(211,139),
state 0x11, keycode 21 (keysym 0x2b, plus), same_screen YES,
XLookupString gives 1 bytes: (2b) "+"
XmbLookupString gives 1 bytes: (2b) "+"
XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x7800001,
root 0x242, subw 0x0, time 11019879, (-650,-317), root:(211,139),
state 0x11, keycode 21 (keysym 0x2b, plus), same_screen YES,
XLookupString gives 1 bytes: (2b) "+"
XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x7800001,
root 0x242, subw 0x0, time 11020216, (-650,-317), root:(211,139),
state 0x11, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
XLookupString gives 0 bytes: 
XFilterEvent returns: False

The equal keypress registers as a KeymapNotify event rather than a KeyPress event. When specifying xev -event keyboard, the equal keypress (KeymapNotify event) results in the same output as when my mouse cursor crosses the xed window.

Interestingly, using a modifier other than Shift (e.g. Windows/Super, Ctrl, or Alt) + equal key results in an xev response indicating the equal sign:

KeyPress event, serial 28, synthetic NO, window 0x7800001,
root 0x242, subw 0x0, time 11051562, (-650,-317), root:(211,139),
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 28, synthetic NO, window 0x7800001,
root 0x242, subw 0x0, time 11051836, (-650,-317), root:(211,139),
state 0x18, keycode 21 (keysym 0x3d, equal), same_screen YES,
XLookupString gives 1 bytes: (3d) "="
XmbLookupString gives 1 bytes: (3d) "="
XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x7800001,
root 0x242, subw 0x0, time 11051930, (-650,-317), root:(211,139),
state 0x18, keycode 21 (keysym 0x3d, equal), same_screen YES,
XLookupString gives 1 bytes: (3d) "="
XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x7800001,
root 0x242, subw 0x0, time 11052111, (-650,-317), root:(211,139),
state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes: 
XFilterEvent returns: False

Using xev | gawk '/keycode/{if($0!=l)print;l=$0;}' to filter out excess data, each keypress results in a line returned except for the equal key (thought Shift + equal key does - see lines 3 and 4).

state 0x10, keycode 36 (keysym 0xff0d, Return), same_screen YES,
state 0x10, keycode 20 (keysym 0x2d, minus), same_screen YES,
state 0x10, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
state 0x11, keycode 21 (keysym 0x2b, plus), same_screen YES,
state 0x11, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,

It would seem that the X server isn't seeing this keypress, though the keycode is mapped:

xmodmap -pke | grep equal results in keycode 21 = equal plus equal plus.

Additional info:

$ setxkbmap -query
  rules:      evdev
  model:      pc105
  layout:     us
  options:    terminate:ctrl_alt_bksp`
WutDuk
  • 43
  • 1
    Have you tried with a different keyboard to make sure the issue is not hardware related? – GMaster Feb 05 '20 at 00:14
  • It's been a long time since I've seen it, but long ago sometimes modifier keys used to get stuck in X, which could make all kinds of weirdness. This sounds like some similar state corruption... so as Windows as it sounds, I'd personally just try rebooting :-( – derobert Feb 05 '20 at 01:15
  • just punching each modifier key a few times sometimes helps. – Jasen Feb 05 '20 at 09:15
  • 1
    @GMaster No, I haven't tried a different keyboard, but the facts that the onboard (software) keyboard is affected the same way and that the key does consistently work in some instances tells me that the hardware isn't the problem. Rather, this seems to be an issue of how the key-press is translated. – WutDuk Feb 05 '20 at 12:18
  • @Quasímodo Whoa... that's cool :)

    Something certainly does seem off because the output I get is different than all other keyboard events:

    KeymapNotify event, serial 28, synthetic NO, window 0x0, keys: 66 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

     – WutDuk Feb 05 '20 at 12:19
  • @Quasímodo (comment continued)

    Other Keypresses:

    KeyPress event, serial 28, synthetic NO, window 0x4000001, root 0x242, subw 0x0, time 1144533, (1058,65), root:(1919,521), state 0x10, keycode 39 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (73) "s" XmbLookupString gives 1 bytes: (73) "s" XFilterEvent returns: False

    Every other keyboard event resembled the above example.

    I'm not yet sure how to read these results, but there appears to be no Window associated with the equal key (window 0x0) compared to the other example (window 0x4000001)

     – WutDuk Feb 05 '20 at 12:29
  • @Quasímodo

    xmodmap -pke|grep equal results in keycode 21 = equal plus equal plus

     – WutDuk Feb 05 '20 at 13:28

2 Answers2

3

I had the same problem in PuppyLinux where I could type ) but not the 0. I then tried another Linux distro to find it was working.

Here is how I made the mistake: I had recently added a new keybinding and mistakingly entered an invalid code (I don't remember which) but that's what interfered with the 0 character.

(Sidenote: my window manager is jwm or Joe's window manager, but actually, it does not matter which distro or window manager you use.)

Conclusion: check any new keybinding added since the trouble showed up, either from a new program setting its own keybindings or keybinding you added by yourself.

AdminBee
  • 22,803
fran
  • 46
  • Thanks @fran. Between the what I uncovered after Quasimodo's suggestion and what I read in this post, I had already suspected an errant keybinding. Using dconf, I checked every keybinding I could find and none of them were responsible. I had started to give up when I saw your answer; in particular when you said, "from a new program setting its own keybindings". I thought about applications I've installed in the past few weeks and sure enough, there it was; an unintentional keybinding I never knew I set! – WutDuk Feb 05 '20 at 19:23
1

I had the exact same problem as you: = sign wouldn't work on both real keyboard and virtual keyboard, but + sign would.

I'll just leave this message here in case it helps at least one person: I managed to fix this problem by pressing Alt+Z and setting the keyboard shortcuts back to default.

Turns out my = sign was a Windows keyboard shortcut... A shortcut to what? I don't know, but it sure was a pain copy-pasting all of those = signs.

AdminBee
  • 22,803
Jack Effiat
  • 11