GNOME Bugzilla – Bug 777693
Input event (e. g. typing on keyboard) is sent repeatedly during high load
Last modified: 2021-07-05 14:27:38 UTC
+++ This bug was initially created as a clone of Bug #757942 +++ > On Fedora 23 with gnome-shell-3.18.1-1.fc23.x86_64 under Wayland, when computer is under heavy load (for example, several VMs are running), if computer "freezes" because of that heavy load, input event is send repeatedly. > > E. g. when I had several VMs running and I was typing in Firefox, characters were appearing repeatedly (I was trying to type "properly", but I have instead typed "prrrrrrrrrrrrrrrrrrrrroperly"). On another occasion, I wanted to start Emacs from Overview, I have clicked its icon and it started five times. According to different comments of that Bug #757942, the issue is still present. It seems to affect both XWayland (e.g. Firefox, Texstudio) and pure wayland (e.g. Gedit) applications and is not limited to Gtk+ (Firefox, Gedit), but also affects Qt5 (Texstudio) applications. Also happens to gnome-shell activities overview search. Since nobody cares to reopen the bug, I'm cloning it. I changed the product to gnome-shell, because it is not limited to Gtk+ applications. Please note that I don't know where this bug comes from, it could e.g. be deep in the libwayland stack. Installed software versions: gnome-shell-3.22.2-2.fc25.x86_64 libwayland-client-1.12.0-1.fc25.x86_64 gtk3-3.22.7-1.fc25.x86_64 qt5-qtbase-5.7.1-10.fc25.x86_64 mutter-3.22.2-3.fc25.x86_64 libinput-1.6.0-1.fc25.x86_64 xorg-x11-server-Xwayland-1.19.1-2.fc25.x86_64
For the record I definitely see this with F25 on my laptop, primarily with the overview. Typically presenting as hitting the overview button registering multiple times causing to enter the overview and then immediately exist again. Also sometimes doubled keys when typing in the overview search field. Increasing the start of repeat delay from 500 to 750 or so has greatly reduced, but not completely eliminated, the frequency with which it occurs. It also makes certain other tasks like scrolling with the arrow keys much more annoying by making key repeat take longer to start though! I don't see it on a desktop running F25+Wayland but that is probably less likely to have maxed out CPUs as it's more powerful. I also never saw it with F24+X on the laptop.
Can you try the patch in https://bugzilla.gnome.org/show_bug.cgi?id=774989 ? Note that that patch is only relevant for key events on gnome-shell's chrome. If you still have this issue inside applications it's either a bug in the application's toolkit if it's a native wayland clients or on Xwayland if it's an X client.
Both patches together?
(In reply to Tom Hughes from comment #3) > Both patches together? yes. strictly just the 2nd (bigger) one is needed.
(In reply to Rui Matos from comment #2) > Note that that patch is only relevant for key events on gnome-shell's > chrome. If you still have this issue inside applications it's either a bug > in the application's toolkit if it's a native wayland clients or on Xwayland > if it's an X client. As I wrote in comment #0, this issue does also affect both Gtk+ and Qt as both XWayland and wayland clients. Are you sure this is a toolkit bug, not a compositor bug?
(In reply to Christian Stadelmann from comment #5) > As I wrote in comment #0, this issue does also affect both Gtk+ and Qt as > both XWayland and wayland clients. Are you sure this is a toolkit bug, not a > compositor bug? Well, not sure, no. I commented here because Tom Hughes apparently is affected only by repeating key events on shell chrome. But, let's try to gather some debugging info for your report. Can you attach the output of running a native wayland client with WAYLAND_DEBUG=1 in its environment and reproducing the bug?
I've tried those patches now - had to mangle them a bit because they don't apply to the current code as clutter-seat-evdev.c doesn't exist but found the relevant code in another file. So far it seems (with the repeat delay set back to 500) to be much better. I did see it bounce straight out of the overview one or twice but it's certainly at least as good as with the longer delay before and probably better.
(In reply to Rui Matos from comment #6) > Can you attach the output of running a native wayland client with > WAYLAND_DEBUG=1 in its environment and reproducing the bug? I tried, but I am unable to reproduce the bug at will. It happens about once per 5 hours of usage, but I have no clue how to trigger it. And my desktop session and log file could not cope with running the whole desktop session under WAYLAND_DEBUG=1, I'm sorry.
Is it possible that bug 778498 is causing this misbehavior? I am getting warnings in syslog like > Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough! there. Also, this bug is often happening when gnome-shell is animating a notification fading in, e.g. from evolution when I receive new messages.
Yes, possibly. > Key repeat discarded, Wayland compositor doesn't seem to be processing events > fast enough! This message comes from Xwayland's patch to address this issue precisely: https://cgit.freedesktop.org/xorg/xserver/commit/?id=239705a In Wayland, the clients implement key repeats (unlikle X11 where the Xserver implements key repeats), but the actual key press/release come from the Wayland compositor that needs to process these first and notify the clients. What happens in this case is the Wayland compositor mutter/gnome-shell is busy playing an animation and doesn't process the key events fast enough, and the client (Xwayland) is not notified the key was released, and starts repeating the last known key press. To avoid this behavior, Xwayland will "ping" the Wayland compositor prior to repeating the key press, and if it doesn't get a reply from the compositor will assume it's too busy and will print this message instead of issuing the key repeat. The fact that this occurs when playing an animation was discusses here: https://bugzilla.gnome.org/show_bug.cgi?id=762618#c11 But the message from Xwayland shows that the mechanism is working (in Xwayland) and prevents the key repeat from occurring when the compositor is not processing events.
So it looks like the solution is making animations async to inputs, did I get this right? Otherwise, we'll need another workaround for the toolkits on wayland, similar to the one in XWayland. Btw: Why is this bug marked as NEEDINFO? The issue is still present with the patches from comment #2 applied to the latest releases of Gtk/GNOME/Freedesktop stack.
Created attachment 350493 [details] pacman upgrade log I'm sufferring from this isssue now. However my CPU usage of gnome-shell is not very high (17%), and it has nothing to do with animation effect AFAIK. I'm pretty sure this problem occured exactlly after upgrading my archlinux. Everything act OK before my login witth gdm, when i logged in to the gnome session, my keyboard started repeatting my input. The issue remains despite which session i choose(Gnome, Gnome-shell fallback, Gnome on Xorg). Sorry i cannot describe more for now because it is really hard to type :( The attachment is my pacman's upgrade log, hope it is helpful.
(In reply to Cherrot Luo from comment #12) > Created attachment 350493 [details] > pacman upgrade log > > I'm sufferring from this isssue now. However my CPU usage of gnome-shell > is not very high (17%), and it has nothing to do with animation effect > AFAIK. > > I'm pretty sure this problem occured exactlly after upgrading my > archlinux. Everything act OK before my login witth gdm, when i logged > in to the gnome session, my keyboard started repeatting my input. The issue > remains despite which session i choose(Gnome, Gnome-shell fallback, > Gnome on Xorg). > > Sorry i cannot describe more for now because it is really hard to > type :( > > The attachment is my pacman's upgrade log, hope it is helpful. I have located my problem: In my gnmoe settings > Universal Access > Typing > Repeat keys, I found the interval was set to 0. I have totally no idea why this could happen. Maybe it's the post upgrade script, maybe it's just my cat.. Meow :(
I reported a very similar bug to ibus-libpinyin, and finally I am directed here. https://github.com/libpinyin/ibus-libpinyin/issues/99 I still encounter this issue on Fedora 26 with most recent updates.
Any update on this bug ? Still happening quite often Ubuntu 17.10 (Gnome on Wayland). Gnome-shell 3.26
*** Bug 794300 has been marked as a duplicate of this bug. ***
Still happening in Gnome 3.28 Wayland on Arch Linux. I noticed that the problem occurs when Gnome-shell shows a notification while I'm typing something.
I often get into the same issue when CPU is heavily loaded.
It seems similar to downstream bug from openSUSE bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1117833 the behavior is quite different for wayland and XOrg session and dramatically going worse on 3.30 on Tumbleweed after upgrading from 3.28 to 3.30
This problem persists on Arch Linux running Gnome 3.32 Wayland. Sometimes I get something like 'gnooooome' when I type in Discord during high cpu usage.
Please remove NEEDINFO status. The request refers to a patch found in Gnome 3.32 in with Arch Linux. Yet, when running Wayland I can easily trigger this bug by rebuilding packages(high CPU) and typing in the GNOME apps, so the patch does not resolve this issue. Switching to x11 does makes the issue go away. When my CPU is idle, I also never see this bug.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.