Input (mouse and keyboard) stops responding with gnome-shell hitting 100% CPU usage on a core on a multi-display setup
Affected version
Fedora 37 GNOME Shell 43.2 Wayland and X Only enabled extension: background-logo@fedorahosted.org
Bug summary
Input (mouse and keyboard) for the computer stops responding when pushing against the shared corner in a 4 monitor setup. Connecting via SSH to the machine is still possible and reveals that gnome-shell is using 100% CPU on a core. Killing the gnome-shell process will restore the ability to use input devices.
Steps to reproduce
- Create a monitor orientation with a 4-way intersection, as shown in the screenshot below.
- Prepare any application which causes the mouse to be "sticky" in the corner, games that lock the mouse to the screen are the most reliable applications providing this behavior; however, the activities bar built into GNOME Shell can also provide the "stickiness" needed to create this behavior, just make the primary display the lower right one and slowly drag the mouse against the shared corner until the activities bar catches the mouse.
- Drag the mouse against the shared corner.
- Input will lock up, but the computer remains responsive. An SSH connection must then be used to kill the shell to regain control.
What happened
The keyboard and mouse stop functioning, but the display continues updating (videos will play, frames of a game will render, etc.), sound will continue playing as expected, all background processes (such as servers) remain reachable and responsive. You cannot ctrl+alt+Fn to another terminal, you cannot ctrl+alt+del to regain control, you cannot alt+F2 and 'r' to reset the shell; all input is blocked.
What did you expect to happen
The keyboard and mouse to continue functioning as normal.
Relevant logs, screenshots, screencasts etc.
No relevant logs are produced, because nothing crashes or fails in any way until it is manually killed by the user to regain control of the system. Attached is a perf report for the gnome-shell process (using 100% of a CPU core) captured via dwarf format call graph recording. I have filtered it to only items with self time, to remove some of the noise with generating call graphs on optimized software. Debug symbols are loaded for gnome-shell, mutter, and glib; which covers almost all of them.
gnome-shell-perf-report-edited.txt
This issue seems to be an infinite loop in mutter's relative_motion_across_outputs code, here: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/native/meta-seat-impl.c#L1163 However, I will let someone who is familiar with the code figure that out for sure, hence the report against gnome-shell instead of mutter.
Here is a screenshot of a display orientation that will produce the behavior.
Here is a screenshot of a display orientation that will not produce the behavior, and can be seen as a workaround to the issue.