Encountered this again clicking a youtube link without thinking. I got the same hanging, but on a second attempt afterwards it did not hang.

The pattern is:
- When rtkit-daemon gives firefox higher priority thread as requested for youtube video playback, the system freezes up. When it unfreezes we see the kwin_wayland_drm message that the main thread was hanging. Kind of seems like the firefox thread becomes so high priority it completely blocks the compositor??
- the 2nd attempt shows the same RT priority messages, but for whatever reason it didn't freeze so no messages about kwin_wayland hanging

Log messages of first encounter:

Mar 05 16:11:54 rtkit-daemon[6414]: Supervising 10 threads of 6 processes of 2 users.
Mar 05 16:11:54 rtkit-daemon[6414]: Supervising 10 threads of 6 processes of 2 users.
Mar 05 16:12:22 rtkit-daemon[6414]: Supervising 10 threads of 6 processes of 2 users.
Mar 05 16:12:22 rtkit-daemon[6414]: Supervising 10 threads of 6 processes of 2 users.
Mar 05 16:12:22 rtkit-daemon[6414]: Successfully made thread 1523890 of process 1518008 owned by '1000' RT at priority 10.
Mar 05 16:12:22 rtkit-daemon[6414]: Supervising 11 threads of 7 processes of 2 users.
Mar 05 16:12:22 rtkit-daemon[6414]: Supervising 11 threads of 7 processes of 2 users.
Mar 05 16:12:22 rtkit-daemon[6414]: Supervising 11 threads of 7 processes of 2 users.
Mar 05 16:12:25 rtkit-daemon[6414]: Supervising 11 threads of 7 processes of 2 users.
Mar 05 16:12:25 rtkit-daemon[6414]: Supervising 11 threads of 7 processes of 2 users.
Mar 05 16:12:47 kwin_wayland[6386]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 05 16:12:47 kwin_wayland[6386]: kwin_core: Cannot grant a token to KWin::ClientConnection(0x61b5fce7ca10)
Mar 05 16:12:58 kwin_wayland[6386]: kwin_core: Cannot grant a token to KWin::ClientConnection(0x61b5fca9d700)

Then I tried clicking the back button, but after about a minute when animation came back I found a different window focused (must have clicked another window by accident). Going back to firefox the youtube video was playing normally.

So I tried navigating back, then forward again. Now the youtube video playing normally without the big minute freeze up. The journal shows:

Mar 05 16:21:01 rtkit-daemon[6414]: Supervising 10 threads of 6 processes of 2 users.
Mar 05 16:21:01 rtkit-daemon[6414]: Supervising 10 threads of 6 processes of 2 users.
Mar 05 16:21:01 rtkit-daemon[6414]: Successfully made thread 1528303 of process 1526394 owned by '1000' RT at priority 10.
Mar 05 16:21:01 rtkit-daemon[6414]: Supervising 11 threads of 7 processes of 2 users.
Mar 05 16:21:01 rtkit-daemon[6414]: Supervising 11 threads of 7 processes of 2 users.
Mar 05 16:21:01 rtkit-daemon[6414]: Supervising 11 threads of 7 processes of 2 users.
Mar 05 16:21:02 rtkit-daemon[6414]: Supervising 11 threads of 7 processes of 2 users.
Mar 05 16:21:02 rtkit-daemon[6414]: Supervising 11 threads of 7 processes of 2 users.
Mar 05 16:21:06 kwin_wayland[6386]: kwin_core: Cannot grant a token to KWin::ClientConnection(0x61b5fca9d700)

We still see the same RT thread priority messages, but just no "kwin_wayland_drm: The main thread was hanging temporarily!" because it didn't hang.

https://discuss.kde.org/t/6-2-3-monitor-screen-freeze-when-playing-video/25796

Similar looking issue but
 `kwin_wayland_drm: Pageflip timed out! This is a kernel bug` 

instead of my
 `kwin_wayland_drm: The main thread was hanging temporarily!`

I have the same issue:

SOFTWARE/OS VERSIONS

Operating System: EndeavourOS
KDE Plasma Version: 6.3.3
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
Kernel Version: 6.13.5-zen1-1-zen (64-bit) / 6.12.18-1-lts (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 5700 XT

Happens both on Firefox and Chrome

Journal file /var/log/journal/907f7623cf4741839043c6438cd51947/system@00062feca649d238-1b4953d3c132f608.journal~ is truncated, ignoring file.
Mar 12 14:03:25 h500i plasmashell[1715500]: org.kde.plasma.notificationmanager: Trying to replace notification with id 1310 which doesn't exist, creating a new one. This is an application bug!
Mar 12 14:03:25 h500i plasmashell[1715500]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/delegates/DelegatePopup.qml:136:17: QML Body: Binding loop detected for property "width"
Mar 12 14:03:25 h500i plasmashell[1715500]: The cached device pixel ratio value was stale on window update.  Please file a QTBUG which explains how to reproduce.
Mar 12 14:03:25 h500i plasmashell[1715500]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/delegates/DelegatePopup.qml:136:17: QML Body: Binding loop detected for property "width"
Mar 12 14:03:41 h500i rtkit-daemon[2746]: Supervising 8 threads of 5 processes of 1 users.
Mar 12 14:03:41 h500i rtkit-daemon[2746]: Supervising 8 threads of 5 processes of 1 users.
Mar 12 14:03:42 h500i rtkit-daemon[2746]: Supervising 8 threads of 5 processes of 1 users.
Mar 12 14:03:42 h500i rtkit-daemon[2746]: Supervising 8 threads of 5 processes of 1 users.
Mar 12 14:03:42 h500i plasmashell[1715500]: org.kde.plasma.notificationmanager: Trying to replace notification with id 1311 which doesn't exist, creating a new one. This is an application bug!
Mar 12 14:03:42 h500i plasmashell[1715500]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/delegates/DelegatePopup.qml:136:17: QML Body: Binding loop detected for property "width"
Mar 12 14:03:42 h500i plasmashell[1715500]: The cached device pixel ratio value was stale on window update.  Please file a QTBUG which explains how to reproduce.
Mar 12 14:03:42 h500i plasmashell[1715500]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/delegates/DelegatePopup.qml:136:17: QML Body: Binding loop detected for property "width"
Mar 12 14:03:44 h500i firefox[1986321]: Failed to create /home for shader cache (Permission denied)---disabling.
Mar 12 14:03:44 h500i firefox[1986321]: Failed to create /home for shader cache (Permission denied)---disabling.
Mar 12 14:03:44 h500i rtkit-daemon[2746]: Supervising 8 threads of 5 processes of 1 users.
Mar 12 14:03:44 h500i rtkit-daemon[2746]: Supervising 8 threads of 5 processes of 1 users.
Mar 12 14:03:44 h500i rtkit-daemon[2746]: Successfully made thread 2132499 of process 2110358 owned by '1000' RT at priority 10.
Mar 12 14:03:44 h500i rtkit-daemon[2746]: Supervising 9 threads of 6 processes of 1 users.
Mar 12 14:03:44 h500i firefox[1986321]: Failed to create /home for shader cache (Permission denied)---disabling.
Mar 12 14:03:44 h500i firefox[1986321]: Failed to create /home for shader cache (Permission denied)---disabling.
Mar 12 14:03:44 h500i firefox[1986321]: Failed to create /home for shader cache (Permission denied)---disabling.
Mar 12 14:03:44 h500i firefox[1986321]: Failed to create /home for shader cache (Permission denied)---disabling.
Mar 12 14:03:44 h500i firefox[1986321]: Failed to create /home for shader cache (Permission denied)---disabling.
Mar 12 14:03:44 h500i firefox[1986321]: Failed to create /home for shader cache (Permission denied)---disabling.
Mar 12 14:04:00 h500i krunner[2093635]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkRequested(QString)
Mar 12 14:04:00 h500i krunner[2093635]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkDone(Solid::ErrorType, QVariant, QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkRequested(QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkDone(Solid::ErrorType, QVariant, QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkRequested(QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkDone(Solid::ErrorType, QVariant, QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkRequested(QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkDone(Solid::ErrorType, QVariant, QString)
Mar 12 14:04:00 h500i krunner[2093635]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkRequested(QString)
Mar 12 14:04:00 h500i krunner[2093635]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkDone(Solid::ErrorType, QVariant, QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkRequested(QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkDone(Solid::ErrorType, QVariant, QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkRequested(QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkDone(Solid::ErrorType, QVariant, QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkRequested(QString)
Mar 12 14:04:00 h500i plasmashell[1715500]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkDone(Solid::ErrorType, QVariant, QString)
Mar 12 14:04:09 h500i kwin_wayland[1715215]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 12 14:04:09 h500i kwin_wayland[1715215]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 12 14:04:34 h500i kwin_wayland[1715215]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 12 14:04:34 h500i kwin_wayland[1715215]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 12 14:04:34 h500i kwin_wayland[1715215]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 12 14:04:34 h500i kwin_wayland[1715215]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 12 14:04:59 h500i kwin_wayland[1715215]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 12 14:04:59 h500i kwin_wayland[1715215]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 12 14:04:59 h500i kwin_wayland[1715215]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 12 14:04:59 h500i kwin_wayland[1715215]: kwin_wayland_drm: The main thread was hanging temporarily!
Mar 12 14:05:24 h500i kwin_wayland[1715215]: kf.windowsystem: static bool KX11Extras::mapViewport() may only be used on X11

Switching to Kernel Version: 6.6.82-1-lts66 (64-bit) seems to have fixed my issue.

Great!

Wait, Nate how is this solved? I'm using 6.12.17-1-lts in my report which is newer than AB's suggestion

Apologies I spoke too fast. My issue manifests again after some time, just not immediately after reboot. Happens on 6.6.82 and 6.12.18 from my testing.

I can note this has occurred to me on some other websites with media as well. 

I mentioned one time after everything unfroze the video played normally. But that seems less common and if I was unable to click the back button I have to find a way to kill the tab with the whole desktop and user input lagging to 1 frame every ~60 seconds.

A lifesaver workaround is to disable autoplay in firefox. Testing this I can navigate to a youtube page fine, but if I click play get the whole everything freezes situation. Clicking play and immediately clicking the back button takes like a solid minute of being frozen until it registers the click and unfreezes.

Having the same issue with stable and mainline kernels, haven't seen it on lts.

Sapphire NITRO+ RX 7800 XT 16GB

Sounds like similar issue here https://www.reddit.com/r/archlinux/comments/1j9o4aw/freeze_after_starting_video_on_youtube_or/

> freeze after starting video on Youtube or whenever an animated banner/background starts in the steam client
SUPPORT
> Happens on a freshly installed system with all AMD hardware - journalctl -f shows "kwin_wayland_drm: The main thread was hanging temporarily!" whenver this happens.

> Same here. Haven't rebooted for several days. Can reproduce a ca. 30 seconds freeze by hitting play on a Youtube video in Vivaldi (chromium).
> In the log I see "kwin_wayland_drm: The main thread was hanging temporarily!" and a
> Edit: Restarting powerdevil heals it.

suggestion it relates to powerdevil

Here's another example from the last week: https://discuss.kde.org/t/some-issues-with-screen-lock-sleep-and-freezing-desktop/31210/6

When I created this bug there were almost no google search results for "kwin_wayland_drm: The main thread was hanging temporarily!" but now there seems to be more in multiple forums

the suggestion to restart powerdevil might be a good workaround

I noticed in System Settings if I clicked Power Management, the System Settings app would hang.

Then I did `systemctl --user restart plasma-powerdevil.service` and I could now view the Power Management settings.
From here tried viewing a youtube video in firefox and it did not lock up my system like before.
TBD if that remains so.

I have a similar problem and had "fixed" it by restarting powerdevil, but it came back after resuming from sleep.

This time I attached a debugger to powerdevil. Its main thread was hanging in an infinite loop in ddcutil, which is at least partially caused by this bug: https://github.com/rockowitz/ddcutil/issues/511

I also found these errors in the log from, as I believe, just before when powerdevil entered the infinite loop.

org_kde_powerdevil[53700]: Error queiscing libdducitl API. 1 active API calls outstanding.
org_kde_powerdevil[53700]: [ 53700] Error queiscing libdducitl API. 1 active API calls outstanding.
org_kde_powerdevil[53700]: org.kde.powerdevil: [DDCutilDisplay]: ddca_close_display -3032
org_kde_powerdevil[53700]: [ 53700] Display redetection starting.
org_kde_powerdevil[53700]: library quiesced, ddca_close_display temporarily unavailable
org_kde_powerdevil[53700]: [148754] recheck thread terminating because watch thread terminated
org_kde_powerdevil[53700]: [ 53700] Watch thread terminated.
org_kde_powerdevil[53700]: [ 53700] Attempting to unlock display lock owned by different thread
org_kde_powerdevil[53700]: [ 53700] Unexpected error DDCRC_LOCKED from unlock_display_by_dpath(Display_Path[/dev/i2c-1])

Maybe some of you also have this in your log?

I also can see at the time of the freeze (triggered by hitting play on a Youtube video), the browser tries to talk to powerdevil, but gets no answer:

vivaldi-stable[141460]: [141456:141481:0317/211350.243515:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.PowerManagement.Inhibit.Inhibit: object_path= /org/freedesktop/PowerManagement/Inhibit: org.freedesktop.DBus.Error.NoReply: Did not receive a reply (...)

I don't understand why this should delay the pageflip, but it doesn't seem to be a coincidence either.

Adding some of my experiences.

As some have mentioned before this seems to be related to plasma-powerdevil.  A systemctl --user restart plasma-powerdevil seems to be a good workaround.

I have noticed the issue occurs after the system has set idle, specifically after any power management i.e. turning off monitors, sleep, etc.

So my steps to reproduce vary slightly:

Lock system, walk away until power management turns off monitors/goes to sleep(sleep is more consistent)
Log back into system
Load *any* video content.  This can be Firefox, Discord, VLC Media Player, doesn't matter.
Hard lock for anywhere between 30 and 45 seconds
Regain control.

Some caveats - Firefox on Youtube will repetitively lock the system.

I'm working on getting some clean logs but wanted to at least provide some direction.  My specs:

OS: CachyOS x86_64
Kernel: Linux 6.13.7-2-cachyos
DE: KDE Plasma 6.3.3
WM: KWin (Wayland)
CPU: AMD Ryzen 7 5800X (16) @ 4.85 GHz
GPU: AMD Radeon RX 7900 XTX

(In reply to dakkoth from comment #16)
> Adding some of my experiences.
> 
> As some have mentioned before this seems to be related to plasma-powerdevil.
> A systemctl --user restart plasma-powerdevil seems to be a good workaround.
> 
> I have noticed the issue occurs after the system has set idle, specifically
> after any power management i.e. turning off monitors, sleep, etc.
> 
> So my steps to reproduce vary slightly:
> 
> Lock system, walk away until power management turns off monitors/goes to
> sleep(sleep is more consistent)
> Log back into system
> Load *any* video content.  This can be Firefox, Discord, VLC Media Player,
> doesn't matter.
> Hard lock for anywhere between 30 and 45 seconds
> Regain control.
> 
> Some caveats - Firefox on Youtube will repetitively lock the system.
> 
> I'm working on getting some clean logs but wanted to at least provide some
> direction.  My specs:
> 
> OS: CachyOS x86_64
> Kernel: Linux 6.13.7-2-cachyos
> DE: KDE Plasma 6.3.3
> WM: KWin (Wayland)
> CPU: AMD Ryzen 7 5800X (16) @ 4.85 GHz
> GPU: AMD Radeon RX 7900 XTX

Adding to this my log:

Mar 21 17:23:49 computer-name kwin_wayland[1491]: kwin_core: KWin::LayerShellV1Window doesn't support setting maximized state
Mar 21 17:23:49 computer-name kwin_wayland[1491]: kwin_core: KWin::LayerShellV1Window doesn't support setting fullscreen state
Mar 21 17:23:49 computer-name kwin_wayland[1491]: kwin_core: KWin::LayerShellV1Window doesn't support setting maximized state
Mar 21 17:23:49 computer-name kwin_wayland[1491]: kwin_core: KWin::LayerShellV1Window doesn't support setting fullscreen state
Mar 21 17:23:50 computer-name kwin_wayland[1491]: kwin_core: KWin::LayerShellV1Window doesn't support setting maximized state
Mar 21 17:23:50 computer-name kwin_wayland[1491]: kwin_core: KWin::LayerShellV1Window doesn't support setting fullscreen state
Mar 21 17:23:50 computer-name kwin_wayland[1491]: kwin_core: KWin::LayerShellV1Window doesn't support setting maximized state
Mar 21 17:23:50 computer-name kwin_wayland[1491]: kwin_core: KWin::LayerShellV1Window doesn't support setting fullscreen state
Mar 21 17:23:52 computer-name kwin_wayland[1491]: kwin_wayland_drm: atomic commit failed: Invalid argument
Mar 21 17:24:01 computer-name kscreenlocker_greet[76187]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000)
Mar 21 17:24:01 computer-name kscreenlocker_greet[76187]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000)
Mar 21 17:24:01 computer-name kscreenlocker_greet[76187]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000)
Mar 21 17:24:01 computer-name kscreenlocker_greet[76187]: Failed to write to the pipe: Bad file descriptor.
Mar 21 17:25:08 computer-name kwin_wayland[1491]: kwin_wayland_drm: The main thread was hanging temporarily!

if the video stops playing, the session stops hanging, so, using a shortcut to quit the application playing video has been an effective workaround. Interestingly, only some types of video seem to cause a problem for me. I don't have issues with Youtube or Netflix in firefox (flatpak), but watching a discord screen share (flatpak), I'm getting the same message being logged to journalctl accompanied with my desktop freezing.

This issue appeared after a very recent system update on Arch Linux with an AMD GPU with a multimonitor configuration (2 DP, 1 HDMI).

I should be more specific.
A am getting the issue in Firefox, but it's happening somewhat inconsistently or rarely.

I've just masked powerdevil as a service as i'm using a desktop, hopefully i will have no more lockups.

Can confirm that restarting powerdevil does seem to address the issue! (only was an issue in librewolf for me, not mozilla firefox)

```sh
systemctl --user restart plasma-powerdevil.service
```

masking powerdevil (ymmv) i haven't had any issues.  🫰🏻

unironically after posting my last message the desktop locked up, powerdevil was masked so where are we now!?

Hey,

I'm experiencing the exact same bug. It should noted that youtube might trigger it but it can also be triggered by just using KDE. 

My setup : Kernel 6.13.8-arch1-1, KDE 6.3.3, Wayland, AMD Ryzen 9 9900X, AMD Radean RX 7600 XT amdgpu drivers.

An observation I did : when the bug is triggered at least one time, KDE is crashing whenever I tried to access "Power management" panel.

I disable ALL power management things(suspend session ->  do nothing etc..) and the bug is gone for now.

Regards,

Chiming in that I've also experienced this. No useful feedback in journalctl aside from `kwin_wayland_drm: The main thread was hanging temporarily!`. I also had one freeze which was not reported in journalctl, but instead, `kwin_wayland_wrapper[1368]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!` was written 621 times over 25 seconds (the length of the freeze). It might have been related to Opera trying to play a Twitch video in the background, but I'm not certain. 

> I disable ALL power management things(suspend session ->  do nothing etc..) and the bug is gone for now.

My Power Management settings are all set to "do nothing," though it did seem to trigger the bug after I turned my monitors back on. One of my monitors is a DisplayPort monitor and the other is on HDMI, which can cause some unusual interactions, since DisplayPort monitors are completely removed when turned off, and HDMI monitors are not. Perhaps something going on there?

Ah, yes, reading a little more closely, I'm also getting DDCUtil errors in my log as per #15. This already seems to have been reported (and fixed) here: https://bugs.kde.org/show_bug.cgi?id=500951

This happens to me even when just middle clicking in a Firefox window o.o

In fact, that's seems to be the main thing that causes it for me

I'm having the same issue, but also happens when trying to play videos in discord or starting new games with dolphin emulator. Restarting powerdevil does fix it for me though

i could have been hasty of saying masking powerdevil made no difference, a reboot later i haven't had any lockups (fingers crossed).

I'm seeing this too. Multi-monitor setup with AMD CPU and Nvidia GPU on EndeavourOS with a 6.13.8 kernel and Plasma 6.3.3. It seems to always correlated with coming back from some sort of power save state (sleeping, screens turned off etc.).

The easiest way to see if the issue has occurred is to open up YouTube and hover over any video thumbnail which should plays a preview of the video - this will now lock the system for 5-10 seconds instead. It also causes games launched through the Dolphin emulator to freeze the system for a similar amount of time before they start, so it does not seem to be a Firefox specific issue.

FWIW I can't reproduce this on Plasma 6.3.3 or git-master, Wayland, multimonitor using the original steps
Firefox was just updated on two test systems today to 137.0, I tested with profile that has no addons

i did have another lockup erlier despite powerdevil being masked.

Apr 02 18:00:33 Plasma kwin_wayland_wrapper[1769]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!
Apr 02 18:00:33 Plasma kwin_wayland_wrapper[1769]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!
Apr 02 18:00:33 Plasma kwin_wayland[1660]: kwin_wayland_drm: The main thread was hanging temporarily!
Apr 02 18:00:33 Plasma kwin_wayland[1660]: kwin_wayland_drm: The main thread was hanging temporarily!
Apr 02 18:00:33 Plasma plasmashell[1867]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/delegates/DelegatePopup.qml:136:17: QML Body: Binding loop detected for property "width"
Apr 02 18:00:33 Plasma plasmashell[1867]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/delegates/DelegatePopup.qml:136:17: QML Body: Binding loop detected for property "width"

(In reply to TraceyC from comment #31)
> FWIW I can't reproduce this on Plasma 6.3.3 or git-master, Wayland,
> multimonitor using the original steps
> Firefox was just updated on two test systems today to 137.0, I tested with
> profile that has no addons

It's not only a Firefox thing, others have reported Dolphin causing this freeze, and I have experienced it when trying to launch DOSBox from Lutris for example. It's 100% a powerdevil issue like mentioned above

After being able to test again this morning It does seem to be related to powerdevil. I clicked on the youtube link in the bugs description and everything froze. After it unfroze (after maybe 1m) i restarted powerdevil  ``` systemctl --user restart plasma-powerdevil.service``` and tried again and it worked. My system specs are as follows

GPU: Nvidia 4070
CPU: AMD 7700X
MOBO: B650 GAMING X AX V2 (rev. 1.x) 
Kernel: 6.13.8-arch1-1
KDE: 6.3.4
Graphics Platform:  Wayland

Some interesting behavior I'd like to share.

Like mentioned by others earlier, my system video signal was freezing as soon as I started to play a video (not just firefox and youtube, but also vivaldi and any website). So I tried to launch a local video with different players. Freezing also occurred with SMPlayer and VLC but interestingly not with mpv. There must be something to dig on that path (common library, similar system call, etc.) that triggers the bug with most web browser integrated video players and dedicated video players that mpv is not using. What's even more surprising, is that my SMPlayer is configured to used system mpv as video backend.

It's not just the first time the video is launched that the bug is happening but also frequently while the video is still playing.

systemctl --user restart plasma-powerdevil workaround prevents freeze from happening.

I'm not sure that "kwin_wayland[1000]: kwin_wayland_drm: The main thread was hanging temporarily!" error is related to the cause of the issue but rather is a consequence. Because I don't see this error happening at each freeze.

When I was playing a video in Vivaldi, for example, I also saw this error, which seems related to the powerdevil workaround:
avril 10 20:17:34 archpowa vivaldi-stable[2414]: [2410:2435:0410/201734.673470:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.PowerManagement.Inhibit.Inhibit: object_path= /org/freedesktop/Powe
rManagement/Inhibit: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.

It doesn't seems to be related to a computer having been running for a long time because it arrived to me soon after booting up.

This should not be related to a specific kernel version because it's happening on a kernel I haven't updated for months and the bug was not present before. So it suggests it must rather be related to a library that was recently updated.

Operating System: Arch Linux 
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.9.0
Kernel Version: 6.6.77-1-lts66 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 1600X Six-Core Processor
Memory: 31.3 Gio of RAM
Graphics Processor: AMD Radeon RX 480 Graphics
Motherboard Name: AB350 Pro4

I can confirm the problems everyone else mentions in the thread. What I can add is that I notice it only happens once the PC goes idle. When the screen locks and the monitors turn off. Logging back in and playing a video triggers the freeze and the only way to fix it is restarting plasma-powerdevil. I don't have hibernation or sleep enabled.

This looks the same as https://bugs.kde.org/show_bug.cgi?id=500951, but why KWin hangs isn't quite clear - I suspected a blocking dbus call related to idle inhibition, but I don't see one in the code.
Can anyone that has the problem please ssh in from another device and get the backtrace of where kwin hangs exactly? While it hangs, you can get it like this:
> sudo gdb -p $(pidof kwin_wayland)
> bt
> q

(In reply to Zamundaaa from comment #37)
> This looks the same as https://bugs.kde.org/show_bug.cgi?id=500951, but why
> KWin hangs isn't quite clear - I suspected a blocking dbus call related to
> idle inhibition, but I don't see one in the code.
> Can anyone that has the problem please ssh in from another device and get
> the backtrace of where kwin hangs exactly? While it hangs, you can get it
> like this:
> > sudo gdb -p $(pidof kwin_wayland)
> > bt
> > q

I managed to switch to a console while this was happening and this is what I got out of it:

> #0  0x000077bde18abbe2 in ??? () at /usr/lib/libc.so.6
> #1  0x000077bde189fe33 in ??? () at /usr/lib/libc.so.6
> #2  0x000077bde189fe74 in ??? () at /usr/lib/libc.so.6
> #3  0x000077bde191aa06 in ppoll () at /usr/lib/libc.so.6
> #4  0x000077bde20d2fcb in qt_safe_poll(pollfd*, unsigned long, QDeadlineTimer) () at /usr/lib/libQt6Core.so.6
> #5  0x000077bde20e2ebb in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt6Core.so.6
> #6  0x000077bde2c72943 in QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt6Gui.so.6
> #7  0x000077bde1f65376 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt6Core.so.6
> #8  0x000077bde1f5d159 in QCoreApplication::exec() () at /usr/lib/libQt6Core.so.6
> #9  0x00006010068000a1 in ??? ()
> #10 0x000077bde1835488 in ??? () at /usr/lib/libc.so.6
> #11 0x000077bde183554c in __libc_start_main () at /usr/lib/libc.so.6
> #12 0x0000601006806415 in ??? ()
> Detaching from program: /usr/bin/kwin_wayland, process 2186
> [Inferior 1 (process 2186) detached]

Pitching in to say that I'm having this exact issue and have been for some time. Suddenly today I've put together several things that explain weirdness I've been experiencing in recent weeks:

- Just like hazelnot said, when this bug triggers, the main way it manifests is by middle-clicking on any Firefox page. It also happens on Steam after it successfully starts up, but this is less consistent. I haven't noticed this when I play audio files, but I use mpv which someone else said elides the freezes somehow.

- It also happens for me after my system has gone to sleep and powerdevil does *not* restart (I use two monitors).

- I say "when powerdevil does not restart" because the majority of the time, when my system comes back awake, if I don't login very quickly then both my screens have their brightness set to 0. I always thought this was just a weird quirk not worth considering, but after manually restarting the `plasma-powerdevil` systemd service I noticed the screens immediately set their brightness to 0, and the issue was fixed.

- My conclusion is thus that I would experience this issue a lot more if powerdevil didn't seemingly restart for some reason whenever my system comes back awake and I don't input my password right away. I now wonder why powerdevil behaves this way when waking up from sleep.

I'm seeing the same `kwin_wayland_drm: The main thread was hanging temporarily!` message in journalctl that others have mentioned whenever my system freezes.

I've managed to clock the freezes at exactly 25 seconds apiece every time they happen.

SOFTWARE/OS VERSIONS

Operating System: Arch Linux
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.9.0
Kernel Version: 6.14.2.arch1-1
Graphics Platform: Wayland
Processors: AMD Ryzen 7 5800X
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 6800 XT

I can reproduce this freeze if I put my laptop to sleep, wake it up and then click on the "Manually block" button in power management

Apr 22 00:50:44 Think-Machinery kwin_wayland[958]: kwin_wayland_drm: The main thread was hanging temporarily!
Apr 22 00:51:09 Think-Machinery electron[1477]: [1477:0422/005109.050369:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.PowerManagement.Inhibit.Inhibit: object_path= /org/freedesktop/PowerManagement/Inhibit: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Apr 22 00:51:09 Think-Machinery electron[1477]: [1477:0422/005109.050392:ERROR:power_save_blocker_linux.cc(344)] No response to Inhibit() request!

I have the same issue as described in the initial post, obviously with different timestamps. My SOFTWARE/OS VERSIONS are all different and listed later.

The only differences are that I do not have "KWIN_DRM_DEVICES" set, I have 1 dedicated GPU an integrated one and I do not have anything installed that uses chromium.
--
Like Comment #12, I get the same symptoms except it's reddit and youtube. Have not tested anything with powerdevil yet.
--
Like Comment #15, I have seen the same journal entries as shown sans timestamps. They stand out because I recall I searched a dictionary for quiesced and quiescing, trying to understand the context and the results gave me a recipe for quiché. This probably has nothing to do with quiché. I can post my logs if needed but I have another unrelated issue spamming my logs a lot.
--
Regarding Comment #25 my lockups happen for 25 seconds. 

After the lockup is over, if I bring up my Yakuake terminal, there sometimes is 621 empty prompts, as if I had hit Enter/Return 621 times, without entering any command. That seems like it is not a coincidence. I never have seen "kwin_wayland_wrapper[1368]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!".

I am using 2 Displayport and 1 HDMI ports currently. Another Displayport and the iGPU HDMI are unused. One of the Displayport cables is a Displayport to HDMI cable.

Mentioning the previous, since I saw ddcutil in a journal entry in a comment, which is for monitor control and it interacts with powerdevil. Reading about it leads me to believe the issue might be with code that interacts with powerdevil, specifically with monitors, like vdu_controls or ddcutil-service.
--
Comment #27 I'm partially experiencing, middle clicking works fine on some pages, including this one as I started typing this.

If I middle click on links, images or videos it opens them as expected without freezing. I can middle click tabs which close as expected without any freezing. Middle clicking non-link text or empty space always causes the lag/freeze to happen.
--
Comment #30 If I hover over a youtube thumbnail, it plays the preview as expected, no freezing. If I do that, then hover over another thumbnail, I get the freeze.
--
Thoughts/additional info:

I have not tried the Powerdevil workaround yet. My power saving settings are to power off monitors after 90 minutes, then go to sleep 90 minutes after that (180 minutes no activity) and the freezes occur without the computer going to sleep.

I started my computer after having it shut off for hours to clean the case. I checked Firefox immediately after logging in and connecting to my neighbors wifi (with permission) and the freezing issue occurred with a middle click. So it occurs regardless of whether the power savings/sleep/hibernate/suspend settings activate or not, for my system.

Maybe it has to do with the monitors themselves? Perhaps a brand/model has weird/bad EDID settings or other irregularities? 

I have a lot of monitors and I switch them around occasionally, most (but not all) are 10-20 years old. In particular, an Asus monitor (VP249) has given me problems. In kinfocenter I see that particular ASUS monitor has a failure:

"Display Range Limits: GTF is supported, but the display does not support continuous frequencies.
EDID conformity: FAIL"

I have no idea what that means and I only posted what looked relevant. I'm going to retire that monitor and see if anything changes but I'm guessing that's not the issue as I saw there were laptops having the same problem but maybe it's an ASUS thing? Just a thought.

I use MPV. The only other video player that is installed (that I am aware of) is VLC which I don't use.

I have 2 desktops, a laptop and a Raspberry Pi 4. I've only had the issue on my main system but haven't checked the others yet. The rest are a couple months behind in updates from lack of use and the laptop is old enough that it could buy cigarettes where I live, if it were a person.

I'm going to try to setup a LAN over the next few days and attempt the suggestion in Comment #37. I've never used ssh successfully, only have internet via tethering or (with permission) my neighbors wifi and I have a disability that effects memory (carbon, not silicon) significantly, so I would not rely on me.

SOFTWARE/OS versions for main system:
Operating System: Manjaro Linux
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.9.0
Kernel Version: 6.12.21-4-MANJARO (64-bit)
Firefox 137.0

I set the Platform back to what it had been (Arch). Please don't change this. See the field descriptions here for an explanation
https://bugs.kde.org/page.cgi?id=fields.html

Anyone have a workaround? I heard comments that masking the service doesn't work?

I'm gonna try 
    systemctl --user edit plasma-powerdevil.service

and add
    [Service]
    RuntimeMaxSec=600

Cause as much as I keep restarting the service, it only lasts so long before I'm yelling again at my frozen computer and finding another system I can ssh from to kill whatever program triggered it. This is a pretty rough bug to keep running into.

@andy:
The error originates in libddcutil, which is used by powerdevil to control the brightness of external monitors. Are you using this feature? If not, you could also edit the service to start it with POWERDEVIL_NO_DDCUTIL=1, as described here: https://invent.kde.org/plasma/powerdevil/-/blob/master/README.md?ref_type=heads#troubleshooting-ddcci-monitor-brightness-controls

(In reply to andy from comment #43)
> Anyone have a workaround? I heard comments that masking the service doesn't
> work?

i did a have a couple of hangs when it was masked but so far its been much better, not a single hang all week.

Created attachment 180704 [details]
backtrace of kwin_wayland during the freeze

(In reply to Zamundaaa from comment #37)

I finally ran into it again and managed to get a backtrace. It seems the problem is already being solved here: https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/280

Cool, then this should be fixed in 6.4!