SUMMARY I'm using Nobara 37 KDE, and after a gaming session one of the panels in my dual monitor setup freezes the icons seem working but not refreshing. I search this problem and I found it supposed to be fix on plasma 5.24, is this a problem with my distro... Drivers... Is the gpu? STEPS TO REPRODUCE 1. Huge impact GPU or CPU task Also happens when opening Firefox, sometimes it doesn't happen, sometimes it does. Changing the panel size or location and going back makes it work again. Have been happening for a while now but I couldn't find anything about this issue. OBSERVED RESULT Clock, icons, panel, animations, etc, freeze out. EXPECTED RESULT Not freeze out. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Nobara Linux 37 KDE Plasma Version: 5.26.5 ADDITIONAL INFORMATION There is a reddit about this https://www.reddit.com/r/kde/comments/10i1s81/plasma_526_panel_freezing_with_wayland_nvidia/
Thank you for the bug report! Please note that Plasma 5.26.5 will not be supported for much longer by KDE; supported versions are 5.27, and 5.27 or newer. Please upgrade to the latest version as soon as your distribution makes it available to you. Plasma is a fast-moving project, and bugs in one version are often fixed in the next one.
Indeed, Plasma 5.26 is almost out of support and undeveloped; are you able to upgrade to Plasma 5.27 (perhaps by upgrading to a newer version of Nobara) and try again?
*** Bug 469175 has been marked as a duplicate of this bug. ***
Getting reports from people using 5.27.4.
Can confirm the issue with this setup: Operating System: Fedora Linux 38 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.2.13-300.fc38.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 I can click on kickoff and other panel bits and actions take place but the panel does not visually update. Time stays frozen when it happens, some applets continue to update like CPU/RAM/DISK monitor. Applications on task manager don't update when they're started or closed.
Created attachment 158669 [details] Screenshot bug plasma 5.27.4 I give a second shot, and it's still in plasma 5.27.4 Operating System: Nobara Linux 37 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.9 Kernel Version: 6.2.12-200.fsync.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 6 × Intel® Core™ i5-9400F CPU @ 2.90GHz Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4070 Ti/PCIe/SSE2
I don't think it's limited to nvidia GPUs (assuming it's the same bug), since I'm also seeing this in a Intel laptop. Replying this comment from #469175: SOFTWARE/OS VERSIONS Operating System: openSUSE tumbleweed KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.2.12-1-default (64 bits) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz Memory: 15,4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics
Indeed. I have also experienced this on an AMD GPU (6800XT).
*** Bug 469544 has been marked as a duplicate of this bug. ***
Just to confirm, I've had this one happen on Kubuntu (hadn't seen it mentioned in this thread on an Ubuntu-based distribution yet) 23.04 running Plasma 5.27.4, both on an AMD/Nvidia hybrid laptop, and on an Nvidia desktop.
Can confirm that this has been happening when I hover back and forth between applications (until the tooltip shows) in icon-only task manager or when I open the pinned Firefox from task manager and place the cursor on the icon until Firefox opens. `plasmashell --replace` fixes this.
A similar situation. I can't keep track of what is happening, it can happen in an hour or 10 hours. I only noticed that this is on the wayland session, I have not seen this on x11. i have nvidia graphics card. Now I've moved to gnome and I can't investigate it further, but I'm thinking of going back again. Maybe besides journalctl, the kde panel or window manager has its own logs?
*** Bug 469872 has been marked as a duplicate of this bug. ***
Experiencing this same issue with the following specs: Operating System: Arch Linux x86_64 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105..0 Qt Version: 5.15.9 Kernel Version: 6.3.1-arch1-1 Graphics Platform: Wayland Processors: AMD Ryzen 7 2700X (16) @ 3.700GHz Memory: 32028MiB Graphics Processor: NVIDIA GeForce RTX 3060 Ti Lite Hash Rate GPU Driver: 3.1.0 NVIDIA 530.41.03 Information of note: This issue only ever appears on the secondary window of my multi-monitor setup. The primary window has never timed out.
Confirming that this also happens to me on nvidia/wayland and while playing games is sometimes involved it's not always clear what causes it honestly
*** Bug 470445 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #16) > *** Bug 470445 has been marked as a duplicate of this bug. *** Is NOT a duplicate!!! My panels freezed are showed up when I move mouse over edges (I had them auto-hidding) but are not interactive (as I told in subject). They don't react to mouse clicks or icons are highlighted. When mouse is over a icon, it shows modal information and thumbnails, but it's the only reaction to mouse over them.
(In reply to Rafael Linux User from comment #17) > (In reply to Nate Graham from comment #16) > > *** Bug 470445 has been marked as a duplicate of this bug. *** > > Is NOT a duplicate!!! My panels freezed are showed up when I move mouse > over edges (I had them auto-hidding) but are not interactive (as I told in > subject). They don't react to mouse clicks or icons are highlighted. When > mouse is over a icon, it shows modal information and thumbnails, but it's > the only reaction to mouse over them. Mate, that's the problem we're *all* having. The panels still emerge from auto-hide on mouseover, but they don't actually update. Clock remains fixed at the previous time, 'Task Manager' widget shows old windows, etc.
Maybe I misunderstood, but this thread subject says "but not functionally" .... so this user case, I understand that if he click on a "freezed" icon, it will react and launch application .... :/
Knock on wood for myself, but...has anyone experienced this problem when running Plasma 5.27.5? (I see that's the version tagged in the bug metadata, but in the description it looks like it was actually on 5.26.5) I ask only because I switched one of my two devices to openSUSE Tumbleweed about a week ago, and have been running 5.27.5 (AFAIK) since then, and haven't had this issue show up since. There were a ton of bugfixes going into 5.27.5, so I just wonder if anyone can replicate the issue on that version, and if perhaps a happy side effect of one of those bugfixes was this issue being resolved? (And Rafael, my understanding of this bug - at least as I experienced it before - was not that the frozen interface was still functional as displayed, but that clicking in the places where the buttons should show up will still sort of "work", although since you can't see what's "there" it's very hard to know if it's working as intended)
(In reply to John Kizer from comment #20) > Knock on wood for myself, but...has anyone experienced this problem when > running Plasma 5.27.5? (I see that's the version tagged in the bug metadata, > but in the description it looks like it was actually on 5.26.5) > > I ask only because I switched one of my two devices to openSUSE Tumbleweed > about a week ago, and have been running 5.27.5 (AFAIK) since then, and > haven't had this issue show up since. > > There were a ton of bugfixes going into 5.27.5, so I just wonder if anyone > can replicate the issue on that version, and if perhaps a happy side effect > of one of those bugfixes was this issue being resolved? > > (And Rafael, my understanding of this bug - at least as I experienced it > before - was not that the frozen interface was still functional as > displayed, but that clicking in the places where the buttons should show up > will still sort of "work", although since you can't see what's "there" it's > very hard to know if it's working as intended) Unfortunately yes, I am currently running 5.27.5 and regularly encountering the bug multiple times per day.
> There were a ton of bugfixes going into 5.27.5, so I just wonder if anyone > can replicate the issue on that version, and if perhaps a happy side effect > of one of those bugfixes was this issue being resolved? It's reported since 5.26 but some people recently update to 5.27 same bug, I can confirm that the bug persist
(In reply to riemarukarurosu from comment #22) > > There were a ton of bugfixes going into 5.27.5, so I just wonder if anyone > > can replicate the issue on that version, and if perhaps a happy side effect > > of one of those bugfixes was this issue being resolved? > It's reported since 5.26 but some people recently update to 5.27 same bug, I > can confirm that the bug persist #MeToo
To work around the randomly freezing taskbar panel issue, what worked for me was enabling the "Show seconds" option in the Digital Clock widget on the taskbar. Fedora 38, KDE 5.27 on Wayland, Nvidia proprietary drivers
(In reply to rushmash from comment #24) > To work around the randomly freezing taskbar panel issue, what worked for me > was enabling the "Show seconds" option in the Digital Clock widget on the > taskbar. > > Fedora 38, KDE 5.27 on Wayland, Nvidia proprietary drivers Your workaround seems to "work"!!! ;) and that should give programmers a clue as to the causes of the failure. openSUSE Tumbleweed, Nvidia propietary drivers, Plasma 5.27.5
(In reply to Rafael Linux User from comment #25) > (In reply to rushmash from comment #24) > Your workaround seems to "work"!!! There is also another method to workaround this issue: Click on show desktop button to hide all open windows > Right click on panel > Edit panel > Move the panel from horizontal edge to vertical edge of screen (or vice-versa) > Move back to original position Now panel starts working again. Changing the panel alignment seems to make the problem go away for some reason.
(In reply to Rafael Linux User from comment #25) > > > Your workaround seems to "work"!!! > Unfortunately as soon as the system gets under heavy load the bug reoccurs. (In reply to Samuel from comment #26) > > There is also another method to workaround this issue: > Click on show desktop button to hide all open windows > Right click on panel > > Edit panel > Move the panel from horizontal edge to vertical edge of > screen (or vice-versa) > Move back to original position > > Now panel starts working again. Changing the panel alignment seems to make > the problem go away for some reason. > There is also another slightly faster workaround. Just change the height of the taskbar by 2px and then back. _________ SysInfo: OS: Arch Linux KDE/Plasma: 5.27.6 Nvidia: 535.54.03
(In reply to Chris.R from comment #27) > There is also another slightly faster workaround. Just change the height of > the taskbar by 2px and then back. I assume you mean doing it when the panels freeze.
(In reply to Rafael Linux User from comment #28) > > I assume you mean doing it when the panels freeze. Yes. :)
The clock with seconds workaround only seems to improve the situation slightly for me, not completely fix the issue. But changing the taskbar size seems to always restore the functionality for a while again.
And just as I wrote that, I tried to do the resize taskbar trick. But as soon as I clicked the up arrow, the screen turned gray and everything hung, so I had to open a second tty and reboot.
I'm also experiencing this issue. I'm on Ubuntu 23.04 with wayland, alienware R14 with NVIDIA GeForce RTX 3070, plasma 5.27.4. Sometimes the taskbar "unfreezes" after a while. Let me know if I can test stuff.
To restore the functionality: plasmashell --replace
(In reply to riemarukarurosu from comment #33) > To restore the functionality: > plasmashell --replace For me, it begin a loop (launching from Konsole) that shows a lot of lines and an error about 3 minutes. Then a Plasma (DrKonqui) shows an error and finally desktop panels are restored. Process never ends and is unstoppable (doesn't react to "Ctrl+C"). In fact, it keeps as a background task showing from time to time output to Konsole till I close terminal.
This bug only happens when you enable the "show small window previews when hovering over tabs" option. Untick that box and your taskbar will never freeze and you won't have to do any of the post-failure workarounds like resizing or moving the taskbar mentioned above. Watching the connections being created and destroyed in qpwmanager shows a significant lag between hovering and showing the preview (by creating a capture of the window and a new window and linking them), and eventually it lags far enough that it fails to destroy the preview and the taskbar freezes up. As a random guess I'd say it's freezing up because it's trying to create a connection that already exists. journalctl shows a stack dozens of of pipewire errors wthin a single second, at the time of failure. plasmashell[5753]: kpipewire_logging: Window not available PipeWireSourceItem_QML_1355(0x556db42d99d0, parent=0x556db8368490, geometry=0,0 524x254) Hope this info helps some of you. Sucks to not have window previews but sucks slightly less than the entire panel freezing unpredictably. Still happening on 5.27.6 BTW
I am also experiencing this issue. Operating System: Arch Linux KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.4.2-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × Intel® Core™ i9-9900K CPU @ 3.60GHz Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1080/PCIe/SSE2 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7B12 System Version: 1.0 Much like Logan, I have a secondary monitor with a Panel along the bottom of the screen. Every so often, and especially during intense activity (such as gaming) the panel on the secondary monitor will visually freeze (clock stops ticking, hover animations stop working, etc) but the panel will still be usable (can still launch applications from it, minimize apps, enter edit mode, etc.) Moving the panel to the side of the screen, and then back to the bottom, seems to fix this temporary freeze. Much like everyone else here (especially pallaswept and Rafael), running something like `journalctl --user -u plasma-plasmashell -f` shows a significant number of the error "kpipewire_logging: Window not available PipeWireSourceItem_QML_1029(0x55bde08896d0, parent=0x55bddd2981f0, geometry=0,0 300x140)" which seems to be spammed whenever navigating anywhere around the desktop. I have now disabled "show small window previews when hovering over tabs" and will see if it crops up again, though so far so good.
To clarify, the error message is still spammed by plasmashell, whether the "show small window previews when hovering over tabs" is disabled or not.
(In reply to Nick Gaulke from comment #37) > To clarify, the error message is still spammed by plasmashell, whether the > "show small window previews when hovering over tabs" is disabled or not. This message will stop when it stops trying to create the pipewire connection, which it does when you disable that option. Maybe give it a restart to be sure it's actually taken effect.
(In reply to pallaswept from comment #38) > (In reply to Nick Gaulke from comment #37) > > To clarify, the error message is still spammed by plasmashell, whether the > > "show small window previews when hovering over tabs" is disabled or not. > > This message will stop when it stops trying to create the pipewire > connection, which it does when you disable that option. Maybe give it a > restart to be sure it's actually taken effect. Good call. It visually had taken effect but still continued the messages. Now, having just restart plashmashell via `systemctl --user restart plasma-plasmashell` with that option unchecked on the panel, that message no longer appears to be spammed in the logs.
(In reply to pallaswept from comment #35) > This bug only happens when you enable the "show small window previews when > hovering over tabs" > ... EXCELLENT explication and thanks for workaround. Maybe you can know about this error "kwin_wayland: This plugin does not support raise()" every so often, but how to guess what plugin is it related to? > Still happening on 5.27.6 BTW Yes, I confirm. Ask for every one in this thread: <Alt><F2> ("Plasma search" or "krunner") doesn't work after some time (unspecified). Am I the only one noticed that on Wayland?
(In reply to Rafael Linux User from comment #40) > (In reply to pallaswept from comment #35) > > This bug only happens when you enable the "show small window previews when > > hovering over tabs" > > ... > EXCELLENT explication and thanks for workaround. Thanks, you're very welcome. I hope it gives you an improved experience. We can all look forward to a KDE dev doing their magic on it to fix it up so we can have our window previews back. > Maybe you can know about this error "kwin_wayland: This plugin does not > support raise()" every so often, but how to guess what plugin is it related > to? I took a look at my logs and sure enough they're also full of these. I figured I'd just 'do stuff' for a while and every so often run 'journalctl -e | grep raise' until I noticed I'd done something to trigger it. Turns out any kind of window management seems to do it. pressing alt+tab will do it (even if you just press esc and exit the dialog so nothing happens), right-clicking the titlebar of an application will do it..... This is certainly worthy of your filing a new bug about it. > Ask for every one in this thread: <Alt><F2> ("Plasma search" or "krunner") > doesn't work after some time (unspecified). Am I the only one noticed that > on Wayland? I'm afraid I can't relate, Krunner triggers from alt+F2 for me quite reliably for days at a time. Still, you might like to file another separate bug report for that one.
> > Ask for every one in this thread: <Alt><F2> ("Plasma search" or "krunner") > > doesn't work after some time (unspecified). Am I the only one noticed that > > on Wayland? > > I'm afraid I can't relate, Krunner triggers from alt+F2 for me quite > reliably for days at a time. Still, you might like to file another separate > bug report for that one. Ok. I'll file a new issue about Krunnen, cause I'm sure more users had same issue. Maybe only happens when combining some wedgets with Wayland. New mistery. Thank you
Same issue Operating System: Arch Linux KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.4.7-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-6700K CPU @ 4.00GHz Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2070/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: H170M-DS3H
I commented earlier to point out that this occurs as a result of plasma failing to handle the pipewire objects generated by screen previews, and I thought it relevant that I've noticed plasma also fails to properly handle screen previews from the media player plasmoid, and especially, from the audio volume control. It's quite commonplace to open the volume control, at which point plasma creates a monitor object for every source, and when you close the volume control, it fails to destroy some of them; or you hover the meia playerwidget and it generates a screen preview monitor and then fails to remove it when it should. Same behaviour as with this; pipewire objects being created as a result of user interaction, and failures when those objects should be removed. My point here is that this issue should probably be looked into as a specific example of general failures in plasma talking to pipewire.
Created attachment 160878 [details] 'Stuck' screen preview Here's a shot of qpwgraph showing the 'stuck' screen preview generated by clicking on the media player widget, and then clicking away, which should destroy the screen preview objects (and did, the first three times, and failed on the fourth attempt, showing that this is intermittent in nature). There is no visible representation of these objects on-screen, they just hang there until pipewire is restarted. This is the same behaviour that causes the reported issue, only, a different trigger - instead of a screen preview generated by the task manager widget (which effects us more because it happens more because we have more apps running, switch between them more, and this behaviour is on by default), it's a screen preview generated by a different widget.
Created attachment 160879 [details] 'Stuck' audio monitors Here is the same behaviour, caused by the volume monitoring of the audio volume widget. The boxes in red are 'stuck' monitors and will never go away. The volume control widget is not open at this time. As you can see by the existence of three of these, once it fails, it will continue to fail in the same way, each time I open the volume widget, it will create a new one and fail to destroy it when I close the widget, stacking dead pipewire objects forever until PW is restarted. You can imagine the effect of this when we're talking about hovering screen previews from the task manager widgets.
Created attachment 160880 [details] 'Stuck' audio monitors showing the constant creation of additional stuck monitors In this shot, I have the volume control widget pinned open, so that I can screenshot this for you. The objects in blue rectangles are active and monitoring volume for the widget as intended. The ones in the red rectangles are the stuck old ones. The one in blue with all the red 'friends' (You can see I'm hovering it with the mouse by the tooltip being shown), will get stuck after this, so now I have four of the 'stuck' monitors for this object. This will go on and on. This is what happens to the screen previews from the task manager, which is why turning off the screen previews is an effective workaround.
Pardon the flood of comments about this. If there's a way to add multiple attachments to a single comment I don't know it. Anyway just to get back to the point: My point here is that this issue should probably be looked into as a specific example of general failures in plasma talking to pipewire.
(In reply to pallaswept from comment #48) > Pardon the flood of comments about this. If there's a way to add multiple > attachments to a single comment I don't know it. Anyway just to get back to > the point: > > My point here is that this issue should probably be looked into as a > specific example of general failures in plasma talking to pipewire. I don't feel you have to apologize for bringing all that information you've been finding out on your own to this thread. On the contrary, I, as affected by the problem, I want to thank you for the time you have spent to collect the information you have reflected here, sometimes it seems that developers forget that users like you, also spend time selflessly to provide everything possible to facilitate developers to resolve issues like this. However, on more than one occasion I have experienced in many cases in open threads, silence as a response after providing information and, even worse, after some time without response or more questions from developers, an automatic message from the system warning that the thread will be closed shortly "For lack of information or inactivity". That is to say, time wasted that in the end makes you wonder on more than one occasion whether to provide some information for the resolution of the incidents. For my part, THANK YOU
*** Bug 473245 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #50) Hi Nate, I noticed you've added a "see also" case today, but if you read what I wrote above, you'll see there's unlikely a relationship. This is a pipewire problem, and adding a disk (as per that case) doesn't do anything in pipewire.
(In reply to pallaswept from comment #51) > (In reply to Nate Graham from comment #50) > Hi Nate, > > I noticed you've added a "see also" case today, but if you read what I wrote > above, you'll see there's unlikely a relationship. This is a pipewire > problem, and adding a disk (as per that case) doesn't do anything in > pipewire. Come to think of it, if plasma has some kinda of very generic "add hardware"/"remove hardware" function(s) that might apply to either disks or audio or video (or other) devices, maybe there is a relationship.... You'd know better than I.
In Gentoo Linux, plasma-workspace's dependence on KPipeWire is optional. I rebuilt plasma-workspace without KPipeWire and, having used it for about 4 days, the issue hasn't reappeared. The issue seems to reside in KPipeWire.
*** Bug 474181 has been marked as a duplicate of this bug. ***
(In reply to nsane457 from comment #53) > The issue seems to reside in KPipeWire. Please see my comments above. It's clear that this is definitely a pipewire-related issue.
*** Bug 466580 has been marked as a duplicate of this bug. ***
(In reply to pallaswept from comment #55) > (In reply to nsane457 from comment #53) > > The issue seems to reside in KPipeWire. > > Please see my comments above. It's clear that this is definitely a > pipewire-related issue. Yes. KPipeWire is the specific library related to pipewire that is causing it. I removed KPipeWire while keeping pipewire and haven't been able to reproduce the issue.
Was experiencing related bug 449163, same symptoms and different steps to reproduce, and directed here. For me, just scrolling the mouse wheel while hovering over a grouped icon with multiple windows open will immediately freeze the taskbar as described. This only occurs if "Show small window previews when hovering over tasks" is enabled. Disabling window previews prevents the issue for me. The connection to pipewire makes sense - I recently experienced another taskbar bug (duplicate sound devices after sleep, https://forums.opensuse.org/t/audio-devices-remain-after-disconnect-on-plasma-5-27/168398) that also tied back to pipewire. Removing kpipewire breaks plasma5-desktop dependency, so I won't be trying that. Maybe the scrolling issue is related to previews having audio control. ABOUT THIS SYSTEM Operating System: openSUSE Tumbleweed 20230902 KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.109.0 Qt Version: 5.15.10 Kernel Version: 6.4.11-1-default (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600X 6-Core Processor Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2
*** Bug 474073 has been marked as a duplicate of this bug. ***
(In reply to Robert from comment #58) > Maybe the scrolling issue is related to previews having audio control. There is no evidence of reliance on both video and audio being manipulated, the issues will occur with one or the other alone. You can see this in the posts I made above where either audio alone or window captures with no audio, caused failures of the system to respond. > (In reply to pallaswept from comment #55) > > (In reply to nsane457 from comment #53) > > > The issue seems to reside in KPipeWire. > > > > Please see my comments above. It's clear that this is definitely a > > pipewire-related issue. > > Yes. I removed KPipeWire while keeping pipewire and haven't been able to > reproduce the issue. Yes of course, because you have removed KDE's library for interaction with pipewire. > KPipeWire is the specific library related to pipewire that is causing it. Correlation does not imply causation. Kpipewire's name is pretty self-explanatory. It is how KDE interfaces with pipewire via Qt. But removing it and seeing the fault gone doesn't directly imply that the issue resides in kpipewire itself. What if you remove pipewire and keep kpipewire? Or just deliberately avoid or invoke kpipewire by means such as the volume monitor or window previews? You've also then avoided or invoked pipewire itself, and wireplumber for that matter, not to mention Qt - and the result is the same. So how can you know that the issue is not within pipewire or even wireplumber or Qt, if you have ceased interaction between them all? It would be a mistake to reduce the issue to being specifically caused by kpipewire when there is no direct evidence to suggest it. See for example the other posters' related issues above, where KDE interacting with pipewire via kpipewire, caused KDE faults, and were fixed in pipewire. It's quite possible, even quite likely, that the issue resides in kpipewire, but I see no conclusive evidence yet that "kpipewire... is causing it". By removing kpipewire, and removing the fault, you've shown, as I did earlier, a direct relationship between the fault and interaction with pipewire, but not with kpipewire itself.
Debian bookworm GeForce GTX 1650 Wayland Another way to trigger this bug is to click on a hyperlink in an email message (kmail) while the browser is on another virtual screen. The browser thumbnail appears in the taskbar of the current virtual screen (kmail) instead of switching to the virtual screen where the browser is. If the browser thumbnail is selected, it switches to the browser's virtual screen (showing the page contents) and the taskbar becomes visually frozen. However, if you manually select the browser's virtual screen (showing the page contents), then when you return to the virtual screen where kmail is, the browser thumbnail is no longer there and the taskbar continues to function normally. Maybe this provides some clue.
I spoke with a bunch of KWin developers about this today and none of them with AMD or NVIDIA hardware were able to reproduce the issue at all. :/ However they think there's a chance this may be fixed in Plasma 6 already due to the myriad Qt, KWin, and KPipeWire changes that have been made so far. For anyone who is able to reproduce this issue, can I ask you to test with Plasma 6 on your distro of choice (see https://community.kde.org/Plasma/Plasma_6#How_to_use/test_it), re-enable previews, and see if the issue has gone away? Thanks a lot!
Another thing to check is whether switching to the Threaded render loop in the Plasma Renderer settings fixes the issue. You'll have to find it by searching for "plasma renderer" in KRunner or Kickoff. Try switching to the Threaded Render Loop and rebooting and see if that fixes it as well. If so, then it should be fixed in Plasma 6 for you, as Threaded is once again the default in Plasma 6 after the bugs affecting it in Plasma 5 were fixed.
(In reply to Nate Graham from comment #62) > I spoke with a bunch of KWin developers about this today and none of them > with AMD or NVIDIA hardware were able to reproduce the issue at all. :/ Thanks so much for looking into this for us, Nate. That's really interesting, it must be some specific configuration that we haven't found. I wonder if it's multiple displays (since a few of us have mentioned this setup)? Wayland? (I haven't tried in an X11 plasma session and I can do that right now....) Could be one of a zillion corner-cases. I will try hard to find it. I agree, it's likely that it'd have been fixed 'by accident' with so many changes involved in Plasma 6 (I read all your blog posts about it and it's very exciting news) Anyway, I'd love to try Plasma 6 but I don't really have a non-production system I can risk it on. I'll see if I can replicate the fault in a VM here, and if we're really stuck, I'll put a day aside and take a full disk backup and try my luck with P6. Thanks again for helping us chase this wild goose.
(In reply to Nate Graham from comment #63) > Another thing to check is whether switching to the Threaded render loop in > the Plasma Renderer settings fixes the issue. You'll have to find it by > searching for "plasma renderer" in KRunner or Kickoff. Try switching to the > Threaded Render Loop and rebooting and see if that fixes it as well. If so, > then it should be fixed in Plasma 6 for you, as Threaded is once again the > default in Plasma 6 after the bugs affecting it in Plasma 5 were fixed. I was thinking about this, and also the compositor latency settings. I'll try both right away.
(In reply to Nate Graham from comment #63) > Another thing to check is whether switching to the Threaded render loop in > the Plasma Renderer settings fixes the issue. You'll have to find it by > searching for "plasma renderer" in KRunner or Kickoff. Try switching to the > Threaded Render Loop and rebooting and see if that fixes it as well. If so, > then it should be fixed in Plasma 6 for you, as Threaded is once again the > default in Plasma 6 after the bugs affecting it in Plasma 5 were fixed. It is indeed not reproducible with the threaded renderer. That is probably why this was initially identified as an nvidia-only issue where the basic loop is the default, then some isolated cases popped up of people using the basic loop on other gpus. What i don't understand from your message is if the threaded renderer is now (as of Qt5.15.10 / Plasma5.27.8) usable in Plasma 5
Awesome news! The threaded render loop is used by default in Plasma 6 because we and the Qt people fixed the relevant bugs in it. Can anyone else confirm that switching back to the Threaded render loop fixes this for them? If so, then I guess we can consider it fixed for Plasma 6.
I can confirm that it seems to be fixed when setting plasma renderer to threaded. Congrats!
(In reply to pallaswept from comment #65) > (In reply to Nate Graham from comment #63) > > Another thing to check is whether switching to the Threaded render loop in > > the Plasma Renderer settings fixes the issue. You'll have to find it by > > searching for "plasma renderer" in KRunner or Kickoff. Try switching to the > > Threaded Render Loop and rebooting and see if that fixes it as well. If so, > > then it should be fixed in Plasma 6 for you, as Threaded is once again the > > default in Plasma 6 after the bugs affecting it in Plasma 5 were fixed. > > I was thinking about this, and also the compositor latency settings. I'll > try both right away. I tried all combinations of all settings in both of these. My test process was simple: enable tuhumnail previews on y tanks bar on each of my wo displays. Make the setting change, apply it, hover each of the tabs on my primary display, the hover the tab on my secondary display (I'm watchng a movie on my 2nd screen right now heh). Every time my clock was frozen before the next minute passed.
Can everyone testing right now please post the following information: 1. Does switching to the Threaded render mode and rebooting fix the problem for you? 2. What exact GPU do you have? 3. What exact version of your graphics drivers (e.g. proprietary NVIDIA driver, Nouveau, or Mesa) are you using? 4. How many screens are you using?
Works here. Single screen. Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.109.0 Qt Version: 5.15.10 Kernel Version: 6.2.0-32-generic (64-bit) Graphics Platform: Wayland Processors: 6 × AMD Ryzen 5 4500U with Radeon Graphics Memory: 15,0 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: Acer Product Name: Aspire A515-44G System Version: V1.12
Threaded renderer works GTX 1080 Ti Proprietary NVIDIA driver 2 screens, mixed refresh rate pallaswept: you need to reboot or logout for the change to apply (on systemdBoot=true `systemctl --user restart plasmashell` should be enough)
(In reply to Nate Graham from comment #70) > Can everyone testing right now please post the following information: > > 1. Does switching to the Threaded render mode and rebooting fix the problem > for you? Please explain what parameter needs to be changed and where it is. I don't understand. When the panel freezes, I use this script. #!/bin/bash plasmashell --replace & disown
(In reply to Konstantin from comment #73) > Please explain what parameter needs to be changed and where it is. I don't > understand. Search for "plasma renderer" in KRunner or Kickoff and launch it. In that window, switch to the "Threaded" option for the "Render Loop" combobox.
(In reply to Nate Graham from comment #70) > Can everyone testing right now please post the following information: > > 1. Does switching to the Threaded render mode and rebooting fix the problem > for you? > 2. What exact GPU do you have? > 3. What exact version of your graphics drivers (e.g. proprietary NVIDIA > driver, Nouveau, or Mesa) are you using? > 4. How many screens are you using? 1) Rebooting after changing the setting to threaded rendering seemed to be a necessity. I've done the same as above, except after a reboot. and I'm 5 minutes in and it hasn't locked up yet. Too soon to call it a fix, but it was reliably dying instantly doing this before. The mouse when over the toolbars entries (as in, the box that represents the window) becomes so laggy it's barely controllable, though. It's fine over the empty potion of the task bar and the system tray, but as soon as I hover an app (to show the preview) it lags out hard. Sometimes it doesn't even show the preview, I have to move the cursor off the toolbar and the back to the same application and the it will show the preview. The start menu consistently fails to appear, even when using the shortcut key (hitting the windows/super key). It comes up about 1 in 10 tries. The system try fails to appear almost all of the time. 2 PNY Nvidia RTX3090 (it's a reference board 3090) 3) Nvidia proprietary drivers installed via the repo 535.104.05 4) 2, Primary is 1080p on the left, secondary is 1440p on the right. they are vertically offset , and the second display uses VRR. I set it up with this: kscreen-doctor \ output.HDMI-A-1.enable \ output.HDMI-A-1.primary \ output.HDMI-A-1.priority.1 \ output.HDMI-A-1.position.0,540 \ output.HDMI-A-1.mode.1920x1080@60 \ output.HDMI-A-1.rgbrange.full \ \ output.DP-1.enable \ output.DP-1.priority.2 \ output.DP-1.vrrpolicy.automatic \ output.DP-1.position.1920,0 \ output.DP-1.mode.2560x1440@165 \ output.DP-1.rgbrange.full Please forgive my typos, I have medical issues and my eyes and hands are not working properly right now. (it's not something that could effect my observations, just control.) I will try combining threaded rendering with some other settings to see if these faults disappear.
(In reply to Konstantin from comment #73) > (In reply to Nate Graham from comment #70) > > Can everyone testing right now please post the following information: > > > > 1. Does switching to the Threaded render mode and rebooting fix the problem > > for you? > > Please explain what parameter needs to be changed and where it is. I don't > understand. > > When the panel freezes, I use this script. > #!/bin/bash > plasmashell --replace & disown If you just rightclick the panel and enter edit mode, change the size up and down a notch, and then exit edit mode, you're done. No need to kill plasma entirely, it just needs a swift kick in the butt ;)
(In reply to pallaswept from comment #75) > I will try combining threaded rendering with some other settings to see if > these faults disappear. Nothing worked. It was SIGNIFICANTLY better in X11 than Wayland, but the lag when hovering the taskbar entries inbetween the moment of the hover and the preview appearing, some few hundred milliseconds or more, the whole system is lagging, even the video in the browser is skipping frames. On Wayland it's just so bad I can't even begin to use it. Going anywhere near a taskbar icon is guaranteed to break either that preview, the application menu, It was the same regardless of any of the other Plasma renderer settings or compositor latency settings. Threaded rendering definitely fixed the total freeze of the panel, but it brought on even worse issues.
Thanks everyone. I think we have enough data now to conclude that this issue is caused by using the basic render loop. It's unfortunate that both the basic and threaded render loops trigger different bugs for users of non-Intel GPUs. But thankfully the bugs with the threaded render loop that we know of are fixed in Plasma 6, so let's call this fixed in Plasma 6.
(In reply to Nate Graham from comment #78) I also can't replicate the fault under X11, with the default renderer settings. I wonder if the people you asked to try it were trying it in Wayland?
(In reply to Nate Graham from comment #74) > (In reply to Konstantin from comment #73) > > Please explain what parameter needs to be changed and where it is. I don't > > understand. > Search for "plasma renderer" in KRunner or Kickoff and launch it. In that > window, switch to the "Threaded" option for the "Render Loop" combobox. does not start liberty@Alex-PC ~> krunner qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> Search for "plasma renderer" in KRunner or Kickoff and launch it. In that window, switch to the "Threaded" option for the "Render Loop" combobox. It can be started with command `kcmshell5 kcm_qtquicksettings` from the console.
(In reply to Nate Graham from comment #70) > Can everyone testing right now please post the following information: > > 1. Does switching to the Threaded render mode and rebooting fix the problem > for you? > 2. What exact GPU do you have? > 3. What exact version of your graphics drivers (e.g. proprietary NVIDIA > driver, Nouveau, or Mesa) are you using? > 4. How many screens are you using? 1. No, it just makes it fully freeze instead 2. GeForce RTX 3060 Lite Hash Rate 3. Nvidia proprietary 535.86.05 4. 2 I'll test with Plasma 6 too.
(In reply to aronkvh from comment #82) > (In reply to Nate Graham from comment #70) > > 1. Does switching to the Threaded render mode and rebooting fix the problem > 1. No, it just makes it fully freeze instead Right, that's another bug with the threaded render loop on Qt 5. > I'll test with Plasma 6 too. If you still see a freeze there, please open a new bug report. Thanks!
(In reply to Nate Graham from comment #70) > Can everyone testing right now please post the following information: > > 1. Does switching to the Threaded render mode and rebooting fix the problem > for you? > 2. What exact GPU do you have? > 3. What exact version of your graphics drivers (e.g. proprietary NVIDIA > driver, Nouveau, or Mesa) are you using? > 4. How many screens are you using? 1. Yes, it worked. The panel does not freeze anymore. 2. NVIDIA 1650 Ti 3. proprietary NVIDIA 535.104.05-12.1 4. 1 laptop screen, I use Lenovo Legion 5.
*** Bug 475369 has been marked as a duplicate of this bug. ***
I also have this issue. The only way I can resolve it is by executing "plasmashell --replace" or restarting my PC. My system is: Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 Kernel Version: 6.2.0-36-generic (64-bit) Graphics Platform: Wayland Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz Memory: 62.7 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2060/PCIe/SSE2 Manufacturer: Micro-Star International Co., Ltd. Product Name: GS75 Stealth 8SE System Version: REV:1.0 I have an external monitor connected to my laptop. I have tried with Nvidia drivers v535 and v545. The issue occurs with both.
ssergio-ll, it is fixed in 6.0 as stated on the top and in comment #62 ff.
(In reply to postix from comment #87) > ssergio-ll, it is fixed in 6.0 as stated on the top and in comment #62 ff. Ok. Thanks!
Created attachment 162904 [details] Simple config file to demonstrate this issue exhibiting itself with audio rather than video I don't feel like this is truly fixed. The plasma panel lockup is a symptom of Plasma failing to create and destroy nodes (video nodes carrying the captured image from the application) in the pipewire graph. I don't see how the rendering loop is going to effect the same fault we're seeing with audio devices. It feels like a symptom has been avoided but the root cause has not been approached. Any sufficiently demanding audio environment will cause the same kind of lockups. You can easily replicate this fault with a simple config file to create a lot of virtual loopback devices. Steps to replicate: Start with a stock pipewire installation Put the attached file in ~/.config/pipewire/pipewire.conf.d/ Run systemctl --user restart pipew* Play some audio Open the volume control Enjoy your freezup. The devices created by plasma take a long time to be created, cause silence, and the volume control panel freezes up, and the devices will randomly fail to be destroyed when closing the volume dialog. See this pw-top output showing several volume monitor nodes, after the volume monitor has been closed, and the high count of errors (3349) on each of the devices which has the volume monitor attached: ``` S ID QUANT RATE WAIT BUSY W/Q B/Q ERR FORMAT NAME S 60 0 0 --- --- --- --- 0 Dummy-Driver S 61 0 0 --- --- --- --- 0 Freewheel-Driver S 179 0 0 --- --- --- --- 0 alsa_input.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00.pro-input-0 S 180 0 0 --- --- --- --- 0 alsa_input.usb-USB_Camera_USB_Camera_SN0001-02.pro-input-0 S 182 0 0 --- --- --- --- 0 alsa_output.pci-0000_09_00.4.pro-output-0 S 183 0 0 --- --- --- --- 0 alsa_output.pci-0000_09_00.4.pro-output-1 S 184 0 0 --- --- --- --- 0 alsa_output.pci-0000_09_00.4.pro-output-2 S 185 0 0 --- --- --- --- 0 alsa_input.pci-0000_09_00.4.pro-input-0 S 186 0 0 --- --- --- --- 0 alsa_input.pci-0000_09_00.4.pro-input-2 S 187 0 0 --- --- --- --- 0 Midi-Bridge S 207 0 0 --- --- --- --- 0 v4l2_input.pci-0000_02_00.0-usb-0_9.1.4_1.0 S 181 0 0 --- --- --- --- 0 alsa_output.pci-0000_07_00.1.pro-output-3 R 209 128 48000 113.9us 3.0us 0.04 0.00 3350 S32LE 6 48000 alsa_output.pci-0000_07_00.1.pro-output-7 R 68 0 0 50.9us 0.9us 0.02 0.00 3349 F32P 6 0 + Test 1 Out R 69 0 0 18.4us 1.0us 0.01 0.00 1 F32P 6 0 + Test 1 In R 71 0 0 50.7us 1.2us 0.02 0.00 3349 F32P 6 0 + Test 2 Out R 72 0 0 20.0us 1.0us 0.01 0.00 1 F32P 6 0 + Test 2 In R 74 0 0 51.1us 1.0us 0.02 0.00 3349 F32P 6 0 + Test 3 Out R 75 0 0 21.5us 1.0us 0.01 0.00 1 F32P 6 0 + Test 3 In R 77 0 0 51.3us 1.0us 0.02 0.00 3349 F32P 6 0 + Test 4 Out R 78 0 0 23.0us 1.0us 0.01 0.00 1 F32P 6 0 + Test 4 In R 84 0 0 51.4us 0.9us 0.02 0.00 3349 F32P 6 0 + Test 5 Out R 85 0 0 24.6us 1.1us 0.01 0.00 1 F32P 6 0 + Test 5 In R 87 0 0 51.5us 0.9us 0.02 0.00 3349 F32P 6 0 + Test 6 Out R 88 0 0 26.2us 1.0us 0.01 0.00 1 F32P 6 0 + Test 6 In R 91 0 0 51.6us 1.0us 0.02 0.00 3349 F32P 6 0 + Test 7 Out R 92 0 0 27.6us 1.0us 0.01 0.00 1 F32P 6 0 + Test 7 In R 94 0 0 51.7us 0.9us 0.02 0.00 3349 F32P 6 0 + Test 8 Out R 95 0 0 29.1us 1.0us 0.01 0.00 1 F32P 6 0 + Test 8 In R 97 0 0 51.9us 0.9us 0.02 0.00 3349 F32P 6 0 + Test 9 Out R 98 0 0 30.7us 1.0us 0.01 0.00 1 F32P 6 0 + Test 9 In R 100 0 0 51.9us 0.8us 0.02 0.00 3349 F32P 6 0 + Test 10 Out R 101 0 0 32.1us 1.0us 0.01 0.00 1 F32P 6 0 + Test 10 In R 103 0 0 51.8us 0.8us 0.02 0.00 3349 F32P 6 0 + Test 11 Out R 104 0 0 33.6us 1.0us 0.01 0.00 1 F32P 6 0 + Test 11 In R 106 0 0 51.6us 0.8us 0.02 0.00 3349 F32P 6 0 + Test 12 Out R 107 0 0 35.1us 1.0us 0.01 0.00 1 F32P 6 0 + Test 12 In R 109 0 0 51.5us 0.7us 0.02 0.00 3349 F32P 6 0 + Test 13 Out R 110 0 0 36.7us 1.0us 0.01 0.00 1 F32P 6 0 + Test 13 In R 112 0 0 51.3us 0.7us 0.02 0.00 3349 F32P 6 0 + Test 14 Out R 113 0 0 38.1us 1.0us 0.01 0.00 1 F32P 6 0 + Test 14 In R 115 0 0 51.0us 0.8us 0.02 0.00 3349 F32P 6 0 + Test 15 Out R 116 0 0 39.7us 1.0us 0.01 0.00 1 F32P 6 0 + Test 15 In R 118 0 0 50.8us 0.7us 0.02 0.00 3349 F32P 6 0 + Test 2 1 Out R 119 0 0 41.2us 1.0us 0.02 0.00 1 F32P 6 0 + Test 2 1 In R 121 0 0 50.6us 0.8us 0.02 0.00 3349 F32P 6 0 + Test 2 2 Out R 122 0 0 42.6us 1.0us 0.02 0.00 1 F32P 6 0 + Test 2 2 In R 124 0 0 50.4us 0.8us 0.02 0.00 3349 F32P 6 0 + Test 2 3 Out R 125 0 0 44.1us 1.0us 0.02 0.00 1 F32P 6 0 + Test 2 3 In R 128 0 0 50.3us 0.8us 0.02 0.00 3349 F32P 6 0 + Test 2 4 Out R 129 0 0 45.6us 1.0us 0.02 0.00 1 F32P 6 0 + Test 2 4 In R 130 0 0 50.1us 0.9us 0.02 0.00 3349 F32P 6 0 + Test 2 5 Out R 131 0 0 47.1us 1.0us 0.02 0.00 1 F32P 6 0 + Test 2 5 In R 134 0 0 50.0us 0.7us 0.02 0.00 3349 F32P 6 0 + Test 2 6 Out R 135 0 0 48.5us 1.4us 0.02 0.00 1 F32P 6 0 + Test 2 6 In R 137 0 0 49.3us 0.7us 0.02 0.00 3349 F32P 6 0 + Test 2 7 Out R 138 0 0 50.5us 1.1us 0.02 0.00 1 F32P 6 0 + Test 2 7 In R 140 0 0 48.8us 0.8us 0.02 0.00 3349 F32P 6 0 + Test 2 8 Out R 141 0 0 52.3us 1.2us 0.02 0.00 1 F32P 6 0 + Test 2 8 In R 143 0 0 48.2us 0.7us 0.02 0.00 3349 F32P 6 0 + Test 2 9 Out R 144 0 0 54.1us 1.2us 0.02 0.00 1 F32P 6 0 + Test 2 9 In R 146 0 0 47.8us 0.7us 0.02 0.00 3349 F32P 6 0 + Test 2 10 Out R 147 0 0 55.8us 1.2us 0.02 0.00 1 F32P 6 0 + Test 2 10 In R 149 0 0 47.2us 0.8us 0.02 0.00 3349 F32P 6 0 + Test 2 11 Out R 150 0 0 57.7us 1.2us 0.02 0.00 1 F32P 6 0 + Test 2 11 In R 152 0 0 46.7us 0.7us 0.02 0.00 3349 F32P 6 0 + Test 2 12 Out R 153 0 0 59.5us 1.2us 0.02 0.00 1 F32P 6 0 + Test 2 12 In R 154 0 0 46.1us 0.7us 0.02 0.00 3349 F32P 6 0 + Test 2 13 Out R 155 0 0 61.4us 1.2us 0.02 0.00 1 F32P 6 0 + Test 2 13 In R 156 0 0 45.7us 0.7us 0.02 0.00 3349 F32P 6 0 + Test 2 14 Out R 157 0 0 63.1us 0.9us 0.02 0.00 1 F32P 6 0 + Test 2 14 In R 158 0 0 45.5us 0.8us 0.02 0.00 3349 F32P 6 0 + Test 2 15 Out R 159 0 0 64.6us 1.0us 0.02 0.00 1 F32P 6 0 + Test 2 15 In R 748 128 48000 20.3us 3.0us 0.01 0.00 1 F32LE 2 48000 + Firefox S 210 0 0 --- --- --- --- 0 alsa_output.pci-0000_07_00.1.pro-output-8 S 211 0 0 --- --- --- --- 0 alsa_output.pci-0000_07_00.1.pro-output-9 S 320 0 0 --- --- --- --- 0 v4l2_input._sys_devices_virtual_video4linux_video1 S 756 0 0 --- --- --- --- 0 Plasma PA S 757 0 0 --- --- --- --- 0 Plasma PA S 758 0 0 --- --- --- --- 0 Plasma PA S 759 0 0 --- --- --- --- 0 Plasma PA S 760 0 0 --- --- --- --- 0 Plasma PA S 761 0 0 --- --- --- --- 0 Plasma PA S 762 0 0 --- --- --- --- 0 Plasma PA S 763 0 0 --- --- --- --- 0 Plasma PA S 764 0 0 --- --- --- --- 0 Plasma PA S 765 0 0 --- --- --- --- 0 Plasma PA S 766 0 0 --- --- --- --- 0 Plasma PA S 767 0 0 --- --- --- --- 0 Plasma PA S 768 0 0 --- --- --- --- 0 Plasma PA S 769 0 0 --- --- --- --- 0 Plasma PA S 770 0 0 --- --- --- --- 0 Plasma PA S 771 0 0 --- --- --- --- 0 Plasma PA S 772 0 0 --- --- --- --- 0 Plasma PA S 773 0 0 --- --- --- --- 0 Plasma PA S 774 0 0 --- --- --- --- 0 Plasma PA S 775 0 0 --- --- --- --- 0 Plasma PA S 776 0 0 --- --- --- --- 0 Plasma PA S 777 0 0 --- --- --- --- 0 Plasma PA S 778 0 0 --- --- --- --- 0 Plasma PA S 779 0 0 --- --- --- --- 0 Plasma PA S 780 0 0 --- --- --- --- 0 Plasma PA S 781 0 0 --- --- --- --- 0 Plasma PA S 782 0 0 --- --- --- --- 0 Plasma PA S 783 0 0 --- --- --- --- 0 Plasma PA S 784 0 0 --- --- --- --- 0 Plasma PA S 785 0 0 --- --- --- --- 0 Plasma PA S 786 0 0 --- --- --- --- 0 Plasma PA S 787 0 0 --- --- --- --- 0 Plasma PA S 788 0 0 --- --- --- --- 0 Plasma PA S 789 0 0 --- --- --- --- 0 Plasma PA S 790 0 0 --- --- --- --- 0 Plasma PA S 791 0 0 --- --- --- --- 0 Plasma PA S 792 0 0 --- --- --- --- 0 Plasma PA S 793 0 0 --- --- --- --- 0 Plasma PA ``` It's a different symptom of the same problem and the renderer might avoid the symptom for video but not for audio.
*** Bug 477381 has been marked as a duplicate of this bug. ***
*** Bug 477406 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #74) > (In reply to Konstantin from comment #73) > > Please explain what parameter needs to be changed and where it is. I don't > > understand. > Search for "plasma renderer" in KRunner or Kickoff and launch it. In that > window, switch to the "Threaded" option for the "Render Loop" combobox. No results from that search. There must be some "normal" way to launch whatever configuration UI it is that you have in mind - like a CLI command, a particular executable or something.
It should show up for Plasma Renderer, it does for me. If it doesn't try running `kcmshell5 kcm_qtquicksettings` from a terminal. The plasma-desktop package supplies this settings module on Fedora.
*** Bug 477551 has been marked as a duplicate of this bug. ***
*** Bug 477946 has been marked as a duplicate of this bug. ***
*** Bug 476279 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #63) > Another thing to check is whether switching to the Threaded render loop in > the Plasma Renderer settings fixes the issue. You'll have to find it by > searching for "plasma renderer" in KRunner or Kickoff. Try switching to the > Threaded Render Loop and rebooting and see if that fixes it as well. If so, > then it should be fixed in Plasma 6 for you, as Threaded is once again the > default in Plasma 6 after the bugs affecting it in Plasma 5 were fixed. I realize this is closed issue but is the final answer to this is wait till plasma 6 releases and it'll be solved? Switching to threaded when using proprietary nvidia drivers didn't fix this issue for me. It was only when i enabled software rendering from this same gui renderer thing that the issue stopped occuring. But this isn't ideal i guess cause kde keeps nagging me that other issues may occur...
Wanted to say that I tried running `kcmshell5 kcm_qtquicksettings` and tried setting the rendering back end to OpenGL (on a hunch) and setting the render loop to Threaded (as per what the general consensus is to fix it) to same result. That leads me to believe that either 1. The automatic settings for both of those just happened to be what I manually set it to by happenstance 2. The threaded renderer isn't exactly the solution that should be chased after Should 2 be the answer, it being the default option in Plasma 6 wouldn't resolve this issue. Since my prior issue was marked as a duplicate (issue #477946), I figured I'd share my findings here
It's 2. Myself and another user have demonstrated that the root cause of this is an issue with Plasma's interaction with pipewire, in various ways, not limited to video, or the panels.(grab the most recent attachment if you'd like to experience it in audio form, through a widget, or a stand-alone application like pavucontrol, yourself) We're being ignored - at least directly. Hopefully in spite of the lack of response, our discoveries have been fed to the devs and they'll actually fix it in 6. That being said, set your renderer settings to automatic (not OpenGL) and Threaded, and you'll have the workaround for the issue in the title (and the title of your duplicate), IF you have the right kind of video card, otherwise it will *maybe* fix the previews, and break a bunch of other stuff, and you have to go back to my original workaround of simply disabling previews, and wait for Plasma 6 so we can hopefully not run into this again....
Came here to say: happens to me too. OpenSUSE Tumbleweed Plasma: 5.27.10 KDE Frameworks: 5.114.0 QT: 5.15.12 Kernel: 6.7.1-1-default (64 bits) GPU: NVIDIA GeForce RTX 3070 Graphics Platform: Wayland
(In reply to saif1988 from comment #100) > Came here to say: happens to me too. With your GPU, you cannot use the workaround that is in place (changing rendering mode) and keep window previews. Disable window previews and your panel won't freeze any more, and join us while we look forward to Plasma 6.
(In reply to pallaswept from comment #101) > (In reply to saif1988 from comment #100) > > Came here to say: happens to me too. > > With your GPU, you cannot use the workaround that is in place (changing > rendering mode) and keep window previews. Disable window previews and your > panel won't freeze any more, and join us while we look forward to Plasma 6. Thanks - I don't even know how to get Plasma 6. Besides, the second issue I have on Plasma is that there are random glitches/screen tilts while using Wayland. Like the screen shakes for a moment or something like that. Will check if I can survive longer on Wayland by disabling window previews.
*** Bug 480967 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #103) > *** Bug 480967 has been marked as a duplicate of this bug. *** Hello. Tell me, please. Has the taskbar hang problem been fixed in KDE 6?
The "Version Fixed In" field of this bug report will give you that information. :)
For usability, I think "Version fixed in" should be next to "Status" ... It would be clearer for anyone to identify the resolution of the problem..
I don't disagree, but that's a change that would have to be made in Bugzilla itself, upstream.
(In reply to Nate Graham from comment #105) > The "Version Fixed In" field of this bug report will give you that > information. :) Thanks I didn't figure it out at first :) You really need to write somewhere in the title that the problem has been solved. I'm looking forward to Plasma 6 :)
Created attachment 167679 [details] Stuck screen preview in Plasma 6
Created attachment 167680 [details] Stuck audio monitors in Plasma 6
Sadly, not fixed in Plasma 6. Interaction with pipewire still causes a lockup. It doesn't freeze the panel any more, but pipewire objects are still left 'hanging' until pw crashes. See screenshots of the same behaviour as before.
(In reply to pallaswept from comment #111) > Sadly, not fixed in Plasma 6. Interaction with pipewire still causes a > lockup. It doesn't freeze the panel any more, but pipewire objects are still > left 'hanging' until pw crashes. See screenshots of the same behaviour as > before. Plasma 6 + Tumbleweed. Now, my autohide panel freezes COMPLETELY from time to time. Icons are not responsive at all. Simply panel is FROZEN and visible. I need to launch "kquitapp6 plasmashell || killall plasmashell" and wait about 5 minutes to get panel hided and responsive again.
Can confirm this issue persists in 5.27.11. Full system info - Operating System: Fedora Linux 39 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 Kernel Version: 6.7.10-200.fc39.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-7500 CPU @ 3.40GHz Memory: 47.0 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: B250-HD3 Are there any other solutions beside the workaround of "disabling preview"?
Nvidia 550.67 update today seems to have fixed a lot of the issues I was experiencing, only been about 30 minutes but everything that would lock the display up before seems to be going smooth. Fingers are crossed.
(In reply to pallaswept from comment #111) > Sadly, not fixed in Plasma 6. Interaction with pipewire still causes a > lockup. It doesn't freeze the panel any more, but pipewire objects are still > left 'hanging' until pw crashes. See screenshots of the same behaviour as > before. This is a different bug, not the one described here. Let's try not to overload existing bug reports with descriptions of new issues. Please report this in a new bugzilla ticket. Same for other folks using Plasma 6. Thanks a lot!
> This is a different bug, not the one described here. Let's try not to overload existing bug reports with descriptions of new issues. See screenshots and other attachments: nothing changed... ...But I'm fine with logging a new case to track this issue under Plasma 6 specifically, seems like a good call. I just don't want to be seen to be dragging this one offtopic/hijacking/etc when I'm not.
Does not seem to be happening anymore on: Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.5.0-26-generic (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900 12-Core Processor Memory: 31,2 GiB of RAM Graphics Processor: NV174 Manufacturer: Alienware Product Name: Alienware Aurora Ryzen Edition R14 System Version: 2.15.0
(In reply to Dennis from comment #117) > Does not seem to be happening anymore on: > KDE Plasma Version: 6.0.3 This patch helped in 6.0.3: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2142