[Bug]: Suspend fails / system won't sleep when hardware-accelerated video wallpaper is active (NVIDIA UVM freeze deadlock)

[giotherobot]

I have:

• Searched if this issue hasn't been reported yet.
• Verified that I am using the latest version (Wallpaper settings > top right corner for version 1.0.0 and later), should be the same as https://github.com/luisbocanegra/plasma-smart-video-wallpaper-reborn/releases/latest

Install method used:

• Using Plasma's "Add new widget" (KDE Store)
• AUR
• Manually from the latest source code

Describe the bug

When a video wallpaper (desktop and/or lock screen) is active and using hardware decode (NVDEC/CUDA), attempting to suspend the system (via systemctl suspend, loginctl, or the Plasma sleep menu) fails. The kernel's freeze-userspace phase for suspend times out after 20 seconds because a QThread inside kscreenlocker_greet (rendering the video wallpaper) is stuck in uninterruptible sleep (state D), blocked on a mutex inside NVIDIA's nvidia_uvm kernel module while tearing down its CUDA/UVM context.
Suspend ultimately fails outright with Failed to put system to sleep. System resumed again: Device or resource busy.
Separately (possibly related, possibly a second bug), plasmashell also crashes with SIGSEGV around the same suspend window, in a PipeWire audio thread (libpipewire-module-protocol-native.so), likely triggered by the audio graph tearing down while the wallpaper's video/audio session is active. Disabling the video wallpaper (switching to a static image) resolves both issues — sleep works reliably via both systemctl suspend and the Plasma menu once disabled.
To Reproduce

Set desktop and/or lock screen wallpaper to a video file with hardware-accelerated decode active (confirmed via nvtop showing decode usage)
Trigger suspend: sudo systemctl suspend or via Plasma's sleep menu
Observe: suspend either fails after ~20s, or system briefly suspends/resumes/fails in a loop

Expected behavior

System suspends normally with the video wallpaper active; the plugin should release its hardware decode/UVM session before the freeze phase begins, or fall back to software decode / pause playback proactively on PrepareForSleep D-Bus signal.

Key log evidence

Kernel freeze timeout, showing the blocked thread inside kscreenlocker_greet and the deadlocked NVIDIA UVM call:

Freezing user space processes failed after 20.008 seconds (1 tasks refusing to freeze, wq_busy=0):
task:QThread         state:D stack:0     pid:105734 tgid:105701 ppid:2366
Call Trace:
 __schedule+0x30d/0x7a0
 schedule+0x27/0x90
 schedule_preempt_disabled+0x15/0x30
 __mutex_lock.constprop.0+0x538/0x9e0
 __mutex_lock_slowpath+0x13/0x20
 mutex_lock+0x3b/0x50
 uvm_va_space_mm_shutdown+0x56/0x4a0 [nvidia_uvm]
 uvm_va_space_mm_unregister+0x12/0x50 [nvidia_uvm]
 uvm_release.isra.0+0x107/0x180 [nvidia_uvm]
 uvm_release_entry.part.0.isra.0+0x53/0xa0 [nvidia_uvm]
 uvm_release_entry+0x2d/0x40 [nvidia_uvm]
 __fput+0xea/0x2d0

Final suspend failure after retries:

systemd-sleep[106324]: Failed to put system to sleep. System resumed again: Device or resource busy
systemd[1]: Failed to start systemd-suspend.service - System Suspend.
systemd[1]: Dependency failed for suspend.target - Suspend.
Plasmashell coredump — crashing thread inside PipeWire, main thread inside PulseAudio-compat proplist parsing:
Stack trace of thread 104183 (raised the fatal signal):
#4 libpipewire-module-protocol-native.so + 0x1a689
#5 libspa-support.so + 0x9656
#6 libpipewire-0.3.so.0 + 0x981f7

Stack trace of thread 103832 (main thread):
#1 pa_flist_pop (libpulsecommon-16.1.so)
#2 pa_hashmap_put (libpulsecommon-16.1.so)
#3 pa_proplist_set (libpulsecommon-16.1.so)
#4 pa_tagstruct_get_proplist (libpulsecommon-16.1.so)

System information (from kinfo)

Operating System: KDE neon User Edition
KDE Plasma Version: 6.7.0
KDE Frameworks Version: 6.27.0
Qt Version: 6.11.1
Kernel Version: 6.17.0-35-generic (64-bit)
Graphics Platform: Wayland
Processors: 16 × Intel® Core™ Ultra 9 285H
Memory: 32 GiB of RAM (30.8 GiB usable)
Graphics Processor 1: Intel® Graphics
Graphics Processor 2: NVIDIA GeForce RTX 5090 Laptop GPU

Workaround

Disabling the video wallpaper (switching to a static image, both desktop and lock screen) fully resolves suspend failures.

(I had claude help drafting this, I double checked anything possible, I am available for more tests)

[luisbocanegra]

Did you test other video players? If they have the same problem this is probably a nvidia thing and not something I can fix. Stop here and report it to nvidia.

If it doesn't happen with other players it could be either a KDE or Qt bug

Please download file as test.qml

test.qml.txt

In line 14 change video.mp4 to the absolute path of one of your videos

If using video wallpaper switch back to the image one then run the test file like this:

QT_MEDIA_BACKEND=ffmpeg QT_FFMPEG_DEBUG=1 QT_LOGGING_RULES="*.ffmpeg.*=true" QT_LOGGING_RULES="*.multimedia.*=true" qml6 test.qml &> log.txt

With the video playing, suspend your system. If that reproduces the problem you will have to report it to Qt.

[giotherobot]

I tried to run the test file with my videos, without the video wallpaper and lockscreen, and the sleeping works as intended.

Here is the log:

log.txt