(Beware, this might be a hardware issue with a spurious port) This was raised a year ago with Mutter, I'm just copying my most recent encounter with this issue today after an upgrade to Fedora 38. Original bug report: https://gitlab.gnome.org/GNOME/mutter/-/issues/1970 --- When i press Super key (Windows key on keyboard) the overview should show up. But this does not happen. I did test with other keyboard where it works just fine. I did confirm that the Windows key is actually mapped to Super key and that holding super and pressing arrows does maximize window and snaps it to sides so GNOME does register the key actually. Weirdly enough sometimes pressing the button quickly does rarely trigger the overview screen. --- I recently bought a Cherry G80-3000N keyboard and it started to exhibit this exact behavior after upgrading to Fedora 38. Now I installed a fresh Fedora 37 from iso (gnome-shell --version = GNOME Shell 43.6) thinking this would be related to the gnome update, still having the same issue. The pattern is exactly as mentioned above in the mutter bug: ``` -event7 KEYBOARD_KEY +10.410s KEY_UNKNOWN (240) released event7 KEYBOARD_KEY +10.410s KEY_UNKNOWN (240) pressed -event5 KEYBOARD_KEY +10.411s KEY_LEFTMETA (125) pressed -event7 KEYBOARD_KEY +10.523s KEY_UNKNOWN (240) released event7 KEYBOARD_KEY +10.523s KEY_UNKNOWN (240) pressed -event5 KEYBOARD_KEY +10.524s KEY_LEFTMETA (125) released ``` Two other interesting things are caused by this: * left/right arrow keys don't debounce properly, they just stop after two left/right steps * text selection and sometimes the right clicking is affected, eg in slack or goland The related device output prints: ``` Device: CHERRY CHERRY Keyboard Kernel: /dev/input/event5 Group: 7 Seat: seat0, default Capabilities: keyboard Tap-to-click: n/a Tap-and-drag: n/a Tap drag lock: n/a Left-handed: n/a Nat.scrolling: n/a Middle emulation: n/a Calibration: n/a Scroll methods: none Click methods: none Disable-w-typing: n/a Disable-w-trackpointing: n/a Accel profiles: n/a Rotation: n/a Device: CHERRY CHERRY Keyboard Kernel: /dev/input/event7 Group: 7 Seat: seat0, default Capabilities: keyboard pointer Tap-to-click: n/a Tap-and-drag: n/a Tap drag lock: n/a Left-handed: n/a Nat.scrolling: disabled Middle emulation: n/a Calibration: n/a Scroll methods: none Click methods: none Disable-w-typing: n/a Disable-w-trackpointing: n/a Accel profiles: n/a Rotation: n/a ``` Indeed, switching the USB port resolves it. The devices stay the same, but the device at /dev/input/event7 is certainly not sending the UNKNOWNS anymore. Going from Fedora 37 to Fedora 38 again does not reproduce this issue on the other port, hence it's likely more hardware related. Windows does not have any problem at all with this port, so not entirely sure if this could be handled differently in libinput. It seems the other device shouldn't be sending those unknown events, or at the very least they should be filtered. Reproducible: Couldn't Reproduce Steps to Reproduce: 1. Upgrade from F37 to F38 2. Observe the super key not properly triggering the overview anymore Actual Results: The overview was only sporadically opening, every nth keypress. Expected Results: I expect the overview to be triggered every time the button is pressed.
libinput doesn't really look at keycodes at all, we just forward them on to the next layer (with very few exceptions, none of which matter here and those don't change the keycodes anyway). Can you run `libinput record --show-keycodes` please when it doesn't work and attach the output here (attach, not copy please). I'd like to look at the HID descriptor, there's a niche chance that windows somehow configures that device on plug. That will show you the events coming from the kernel, so GNOME is not involved in that bit. *Could* be that there's a kernel bug or some new power saving feature that triggers this behaviour. One approach for a workaround is finding 60-keyboard.hwdb on your machine and following the instructions above - map the scancodes sent by the keyboard back to the right key. But from the above it looks like this sends `KEY_UNKNOWN` in addition to `LEFTMETA` so I'm not sure that would work...
Thanks Peter. I'm not able to repro this sadly, neither with my new keyboard nor with my old one on that port. Just did another clean F37 installation and an upgrade to F38, nothing. Regarding libinput record I'm getting this message: ``` Package libinput-1.23.0-2.fc38.x86_64 is already installed. [tjungblu ~]$ libinput record libinput: record is not installed ``` Not sure if there's a package dependency missing somewhere. Closing this in the meantime, will attach the required data if I see this again.