Description of problem: As of updates yesterday or the day before, I'm experiencing an issue where I'm typing into a terminal window (ssh to a remote system that is connected to a screen session if it matters) and all of a sudden a key starts repeating and won't release. If I hit Ctrl-S, it freezes and Ctrl-Q unfreezes, but the key repeat then continues. If I open a new terminal window or use Alt-F2 to open the command launcher, no keyboard input is accepted at all. If I use Ctrl-Alt-F3 to switch to a Linux virtual console, they keyboard works normally. Switching back to the Wayland session on Alt-F1 doesn't restore the keyboard. At this point, I reboot the system from gnome shell (the mouse still works). I just had this happen 3 or 4 reboots in a row--each time the exact same symptoms. I think this is a kernel problem, because that is one of the packages updated yesterday. I rebooted to 4.20.4-200 and haven't had the issue happen again (but I haven't repeated the exact steps below). Version-Release number of selected component (if applicable): kernel-4.20.5-200.fc29.x86_64 gnome-session-wayland-session-3.30.1-2.fc29.x86_64 libwayland-client-1.16.0-1.fc29.x86_64 libwayland-server-1.16.0-1.fc29.x86_64 waylandpp-0.2.3-2.fc29.x86_64 xorg-x11-server-Xwayland-1.20.3-3.fc29.x86_64 How reproducible: always Steps to Reproduce: 1. Open a gnome-terminal 2. SSH to remote system, screen -r -d to reattach (may not be required) 3. Start typing an email in mutt. Actual results: Key gets stuck down an repeats. It is NOT always the same key. Eventually, the keyboard becomes non-responsive in Waylayd, but works in text Virtual Console. Expected results: No key repeat. Keyboard remains responsive in Wayland. Additional info: ASUS laptop hardware: a description: Notebook product: X202E (ASUS-NotebookSKU) vendor: ASUSTeK COMPUTER INC. version: 1.0 serial: <redacted> width: 64 bits capabilities: smbios-2.7 dmi-2.7 smp vsyscall32 configuration: boot=normal chassis=notebook family=X sku=ASUS-NotebookSKU uuid=<redacted> Recently updated packages: Tue Jan 29 10:38:22 2019 rdesktop-1.8.4-2.fc29.x86_64 Tue Jan 29 11:06:52 2019 systemd-libs-239-9.gite339eae.fc29.x86_64 Tue Jan 29 11:06:52 2019 systemd-pam-239-9.gite339eae.fc29.x86_64 Tue Jan 29 11:06:54 2019 systemd-239-9.gite339eae.fc29.x86_64 Tue Jan 29 11:06:55 2019 xdg-desktop-portal-1.2.0-1.fc29.x86_64 Tue Jan 29 11:06:55 2019 xdg-desktop-portal-gtk-1.2.0-1.fc29.x86_64 Tue Jan 29 11:06:57 2019 policycoreutils-2.8-17.fc29.x86_64 Tue Jan 29 11:06:58 2019 lua-5.3.5-3.fc29.x86_64 Tue Jan 29 11:06:58 2019 lua-libs-5.3.5-3.fc29.x86_64 Tue Jan 29 11:06:58 2019 policycoreutils-python-utils-2.8-17.fc29.noarch Tue Jan 29 11:06:58 2019 python3-policycoreutils-2.8-17.fc29.noarch Tue Jan 29 11:06:58 2019 radvd-2.17-17.fc29.x86_64 Tue Jan 29 11:06:58 2019 systemd-container-239-9.gite339eae.fc29.x86_64 Tue Jan 29 11:06:59 2019 systemd-udev-239-9.gite339eae.fc29.x86_64 Tue Jan 29 11:07:00 2019 libmodulemd1-1.8.2-1.fc29.x86_64 Tue Jan 29 11:07:00 2019 vim-minimal-8.1.818-1.fc29.x86_64 Tue Jan 29 11:07:01 2019 gtk2-2.24.32-4.fc29.x86_64 Wed Jan 30 17:08:23 2019 ibus-libs-1.5.19-13.fc29.x86_64 Wed Jan 30 17:08:28 2019 kernel-core-4.20.5-200.fc29.x86_64 Wed Jan 30 17:08:33 2019 kernel-modules-4.20.5-200.fc29.x86_64 Wed Jan 30 17:08:42 2019 ibus-gtk2-1.5.19-13.fc29.x86_64 Wed Jan 30 17:08:42 2019 ibus-gtk3-1.5.19-13.fc29.x86_64 Wed Jan 30 17:08:42 2019 ibus-setup-1.5.19-13.fc29.noarch Wed Jan 30 17:08:45 2019 ibus-1.5.19-13.fc29.x86_64 Wed Jan 30 17:08:45 2019 kernel-4.20.5-200.fc29.x86_64 Wed Jan 30 17:08:45 2019 kernel-modules-extra-4.20.5-200.fc29.x86_64 Wed Jan 30 17:08:55 2019 flatpak-libs-1.2.0-2.fc29.x86_64 Wed Jan 30 17:08:55 2019 libdrm-2.4.97-1.fc29.x86_64 Wed Jan 30 17:08:55 2019 rust-srpm-macros-6-3.fc29.noarch Wed Jan 30 17:08:56 2019 flatpak-1.2.0-2.fc29.x86_64
So far I have not been able to reproduce this issue on kernel-4.20.4-200.
Possible changes that may have caused this regression: https://bugzilla.redhat.com/show_bug.cgi?id=1663613 https://bugzilla.redhat.com/show_bug.cgi?id=1665505
Most likely this ibus releated problem https://bugzilla.redhat.com/show_bug.cgi?id=1671286
Hi, I think that those causing this is highly unlikely: (In reply to Charles R. Anderson from comment #2) > Possible changes that may have caused this regression: > > https://bugzilla.redhat.com/show_bug.cgi?id=1663613 The patch for this is in the nouveau driver and your laptop does not use the nouveau driver (try "lsmod | grep nouveau" the output will be empty) > https://bugzilla.redhat.com/show_bug.cgi?id=1665505 The patch for rthis is for the asus-hid driver and your laptop likely has a PS/2 keyboard and the hid-asus driver is for USB keyboards only. To check this run "sudo evemu-record" you will likely have a "AT Translated Set 2 keyboard" option there and if you select this and then press the 'A' key it will be printed by evemu-record, which means that you have a PS/2 keyboard. Regards, Hans
I've since reproduced this problem on 4.20.4 and 4.19 kernels as well. Changing component to ibus since that appears to be the cause based on bodhi comments. I downgraded to ibus-1.5.19-12 and cannot reproduce the problem. With ibus-1.5.19-13 holding down the down arrow key (in e.g. "less" viewing a large file) and then hitting the up arrow key (while still holding down the down arrow key) sometimes causes the down arrow to get stuck and repeat, then keyboard input stops working altogether.
*** This bug has been marked as a duplicate of bug 1671286 ***