Bug 2354295

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.