Plasma Desktop panel freeze while VM (qemu/KVM) is running on second monitor

[dibl]

I know there are many KDE/Plasma users on this forum -- I want to describe an issue that has appeared during the past week, to learn whether anyone else has seen it.

My system (siduction KDE/Plasma, fully updated):

Machine:
  Type: Desktop Mobo: ASUSTeK model: ROG STRIX X299-E GAMING v: Rev 1.xx
    serial: <superuser required> UEFI: American Megatrends v: 1401
    date: 05/21/2018
CPU:
  Info: quad core model: Intel Core i7-7740X bits: 64 type: MT MCP cache:
    L2: 1024 KiB
  Speed (MHz): avg: 800 min/max: 800/4500 cores: 1: 800 2: 800 3: 800 4: 800
    5: 800 6: 800 7: 800 8: 800
Graphics:
  Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] driver: nvidia v: 550.142
  Display: wayland server: X.org v: 1.21.1.16 with: Xwayland v: 24.1.6
    compositor: kwin_wayland driver: X: loaded: nvidia
    unloaded: fbdev,modesetting,nouveau,vesa gpu: nvidia,nvidia-nvswitch
    resolution: 1: 1920x1200~60Hz 2: 1920x1080~60Hz

   
Problem description:

With either chromium or firefox browser running on one monitor, I launch my Win 10 VM on the second monitor, and log in there. It starts and runs error-free. On Win 10, I can launch my genealogy database (or any other app). On the monitor with the browser running, I am able to use my online tools with no problem. However, the panel on the plasma desktop is frozen -- I cannot use the Application Launcher, nor any of the shortcuts that I have put on the panel. The browser window is functional -- I can move it it, resize it, etc. But if I minimize the browser, then it will  not respond when I attempt to bring it back up off the panel. Alt-F2 works correctly to launch apps, and they can be closed normally, but if they are minimized then they are not recoverable. If I shut down the Win10 VM, then the Plasma panel becomes fully functional again.

I assume this is a bug in a recently changed package, but I wonder if anyone else has seen it?

[ro_sid]

It can be an error, but very often it is a message-"window" not "answered" or closed, that blocks the task-bar, which is - to my knowledge - not re-entrant capable.
If my assumption is correct, then please look at your screen(s) for a "hidden" widget somewhere.

[dibl]

This is a good suggestion -- I have seen something like that happen.  However, in this case, even the clock on the right end of the panel is frozen at the moment that the VM interfered with it. So it seems the panel has been cut off from the internal functions of the OS, during the freeze when the VM is in use. But only the panel -- not the rest of Plasma. The window manager is working, Alt-F1 works. Ctrl-F2, F3, F4 changes my virtual desktops. The problem seems isolated to the panel plus Launcher and widgets.

[Mister00X]

I am also encountering somewhat frequently freezes on my desktop, which also has two displays.

In my case I believe I am affected by at least two different "bugs". The behaviour you describe occurs for me often shortly after login or if I turn one of my displays on and off. IMHO what you encounter is a freeze of plasmashell. I usually identify this by looking at the digital clock widget on the desktop panel as I have enabled the display of the current time including seconds. In my case the panel and the rest of plasmashell unfreezes after about 30 s to 1 min 30 s and all interactions I had with the panel are suddenly executed at once.

For me this behaviour is sometimes accompanied by a message in the user journal that looks like this:

Code Select Expand


Apr 08 10:41:45  plasmashell[1571134]: The cached device pixel ratio value was stale on window update.  Please file a QTBUG which explains how to reproduce.


And sometimes I also encounter these messages

Code Select Expand

pr 08 11:04:35 kwin_wayland_wrapper[1565313]: kwin_wayland_drm: The main thread was hanging temporarily!
Apr 08 11:04:38 plasmashell[1571134]: The cached device pixel ratio value was stale on window update.  Please file a QTBUG which explains how to reproduce.
Apr 08 11:04:38 plasmashell[1571134]: file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/items/PlasmoidItem.qml:24: TypeError: Cannot read property 'toolTipMainText' of null
Apr 08 11:04:38 plasmashell[1571134]: file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/items/PlasmoidItem.qml:24: TypeError: Cannot read property 'toolTipMainText' of null
Apr 08 11:04:43 kwin_wayland_wrapper[1565313]: kwin_core: Cannot grant a token to KWin::ClientConnection(0x7f2b00002a20)

I'm not entirely sure if those messages are really related to the freeze you describe, because I also sometimes encounter a full freeze of both displays which I believe is related to electron-based flatpaks.

Do you have similar messages in your user journal?

[dibl]

Thanks for this.

Using journalctl, it looks to me like this message matches the time of the freeze after I logged in to the Win10 VM:

Code Select Expand

Apr 08 15:08:38 hibiscus kwin_wayland_wrapper[4412]: This plugin does not support grabbing the keyboard
Apr 08 15:08:40 hibiscus kwin_wayland_wrapper[4412]: This plugin does not support grabbing the keyboard
Apr 08 15:08:40 hibiscus kwin_wayland_wrapper[4412]: This plugin does not support grabbing the keyboard
Apr 08 15:08:42 hibiscus kwin_wayland_wrapper[4412]: This plugin does not support grabbing the keyboard
lines 14-50/50 (END)


I think maybe we're back to the old "which OS owns the  mouse and keyboard?" issue. Years ago, one of the virtualization packages required me to click "Alt-L" or something like that, to pass the mouse and keyboard to the other OS.

There have many recent updates to libvirt and qemu, and of course also to plasma packages. Maybe we have a type of regression here.

EDIT: I have a second siduction KDE/Plasma desktop system, with similar hardware, but only a single monitor. On that that system, this issue does not happen when the VM is started. So the dual monitor setup is involved with the panel freeze problem.


EDIT #2  Further investigation reveals that the problem is triggered by changing the qemu VM Viewer (spice display) to Full Screen mode. It never happens as long as the VM is displayed in a window, and it occurs within a few seconds after the switch to full screen mode, on a dual monitor setup.