Description of problem: System response to keyboard / mouse actions is close to none. There are about 50 records per second in /var/log/messages when the freeze happens: localhost kwin_wayland_wrapper[17692]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough! Mouse moves after about 10 to 20 seconds a couple of centimeters. To open a tty takes about the same time. Login and typing in tty is ok. top (in tty) does not indicate a problem. pipewire is at 100%. Killing the process does not fix the problem. Version-Release number of selected component (if applicable): Linux TP15 6.13.7-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Mar 13 17:46:13 UTC 2025 x86_64 GNU/Linux How reproducible: Intermittend Steps to Reproduce: 1. 2. 3. Actual results: Reboot is faster than waiting for an unfreeze. Expected results: No freeze. Additional info: Most likely to happen in an editor. In emacs the input just stops working. Recently more often (more than once a day) . emacs-lucid GNU Emacs 29.4 (build 1, x86_64-redhat-linux-gnu, X toolkit, cairo version 1.18.2, Xaw3d scroll bars) of 2025-03-13 emacs-gtk+x11 ( GNU Emacs 29.4 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2) of 2025-03-13) In slick edit previously the cursor just continued moving upwards. Felt like a stuck key - but was n't. And if it was a stuck key then input in the tty should not be possible either. nvidia driver de-installed: still the freeze did happen. So there is no strict indications for a specific cause.
Looks like I'm getting a step closer to the root cause: When executing in konsole emacs-lucid --geometry=200x50+0+0 M-x shell apl the freeze happens more than once an hour!!! Entering a tty terminal (Hitting Ctrl+Alt+F3 and wait some time until the terminal opens.): journalctl -b gets the message flood from the graphic session during the freeze: "kwin_wayland_wrapper[12674]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!" The following is the output from the tty terminal session during the freeze of the graphic session from ps -Al 1| grep wyland: ------------------> 4 S 0 4979 2823 0 80 0 - 75831 do_pol ? 0:00 /usr/libexec/sddm-helper --socket /tmp/sddm-auth-8f817c07-f77f-4f20-966e-7c77ead5d4b7 --id 1 --start /usr/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland --user joy 4 S 1000 5076 4979 0 80 0 - 132223 do_pol tty5 0:00 /usr/bin/startplasma-wayland 0 S 1000 5157 4986 0 80 0 - 94738 do_pol ? 0:00 /usr/bin/kwin_wayland_wrapper --xwayland 4 S 1000 5170 5157 0 58 - - 751507 futex_ ? 1:37 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 --xwayland-xauthority /run/user/1000/xauth_OzYaah --xwayland 0 S 1000 5278 5170 0 80 0 - 104497 ep_pol ? 0:10 /usr/bin/Xwayland :0 -auth /run/user/1000/xauth_OzYaah -listenfd 8 -listenfd 9 -displayfd 108 -wm 110 -rootless -enable-ei-portal 0 S 1000 5662 4986 0 80 0 - 285766 do_pol ? 0:00 /usr/bin/xwaylandvideobridge 4 S 0 12593 12356 0 80 0 - 57591 pipe_r tty3 0:00 grep --color=auto wayland <----------------- killing process 5278, /usr/bin/Xwayland (the last in the chain) stops the message flood. May be there is an item that is somewhat related to the problem. ("somewhat related" as I did not observe a direct cause between typing -> freezing. Freezing happens rather randomly.) -1- I have an GNU-APL keyboard layout selected. The layout uses UTF-8 APL characters. It does not use a specific APL character set/font. -2- What is OK: Having an APL-session in /usr/bin/konsole apl # command to start a GNU-APL session any 'heavy' input/output does not cause freezes. -3- Using slick edit to edit APL-functions via file exchange. No editor call from within apl. In rare cases (weeks apart) the "cursor up" freeze happens. -3- Having the APL-session in /usr/bin/konsole .. emacs-lucid --geometry=200x50+0+0 # command to start emacs and M-x shell # the command to start the shell apl # the command to start apl from within the emacs shell the freeze happens 'quite a lot' -4- What I noted and related to -1-, -2-: Some APL characters get displayed in two positions in konsole: Type the char ⍝ - the first half of the character gets displayed in the fist char position hit space bar - the second half of the character gets displayed in second position. As code, both positions are being interpreted correctly as "⍝<SPACE>" You might note that even here in this Comment-snippet the character "⍝" occupies two 'positions'!! Char ⍝ is U235D ⍝ -- Up Shoe Jot / AFS - APL Functional Symbol -4.1- emacs behaves differently in this respect: The ⍝ character is being displayed 'in full' though rather tiny compared to the other regular characters. Hit space bar and the character changes - that is, it moves a some pixels down wards. However, as said before, the observation (in -4.1-) is not directly related to a freeze like (Type, ENTER, freeze). BUT - having all the likely involved abouts written down - and reflecting more on the point in time, when a freeze happens, a got a strong suspicion - hitting the CURSOR-UP-KEY starts the big freeze. Supposedly: Moving the cursor down, left, right is cheap in respect of code involved. Moving the cursor up requires a least to scan the output buffer (M-x shell)!! and adjust the output according to the cursor position. There is much more code involved which could to lead to a race condition between Wayland and emacs.
YES! - FINALLY. How to reproduce. konsole emacs-lucid --geometry=200x50+0+0 # --geometry=... might not be relevant / not checked M-x shell python # you do not need GNU-APL Right at the python prompt press the cursor up key. When the cursor hits the top of the session - big freeze.
One more Item: The freeze happens with commands/versions emacs-gtk+x11 and emacs-lucid not with emacs! Despite the fact that the pop up warning from emacs tells me to use either emacs-gtk+x11 or emacs-lucid. Just start emacs-gtk+x11 or emacs-lucid and move the cursor to the top.
I submitted a bug that sounds related. I found that pipewire went into an infinite loop. I had to kill all pipewire and wireplumber processes to gain control of the system back. I did it remotely. Will have to try from a tty. https://bugzilla.redhat.com/show_bug.cgi?id=2350976
On reddit Spielwurfel reported: Did anyone noticed Fedora 42 getting kind of slower after the latest update .... ? Ref: https://www.reddit.com/r/Fedora/comments/1jw5y23/fedora_42_is_a_go_release_date_april_15th/ The tip was to have a look at the power save mode. My power mode was set to "Leave Unchanged". I set the power mode to "Performance" and the interface is lightning fast now. emacs/Wayland do not hang any more. I have no idea who/what caused the change. I set the severity not lower than high - as even in power save mode the (non blocking) responsiveness of the interface has to be guaranteed. Where to place a feature request? Changes, that effect "important" settings like HW, security, communication, etc. , should be annotated with User and Date.
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15. Fedora Linux 41 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.