mpv-player
dmabuf-wayland in git doesn't block the screensaver, even while videos are playing and with/without --stop-screensaver=yes|always
mpv Information
mpv v0.39.0-233-g9af491fc80 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
built on Oct 26 2024 08:15:05
libplacebo version: v7.349.0
FFmpeg version: n7.0.2
FFmpeg library versions:
libavcodec 61.3.100
libavdevice 61.1.100
libavfilter 10.1.100
libavformat 61.1.100
libavutil 59.8.100
libswresample 5.1.100
libswscale 8.1.100
Other Information
Operating System: Arch Linux
KDE Plasma Version: 6.2.2
Kernel Version: 6.11.5-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 PRO 4750U with Radeon Graphics
Memory: 46.3 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Reproduction Steps
play video file with mpv --no-config --vo=dmabuf-wayland (optionally with --stop-screensaver=yes|always)
Expected Behavior
Screen blanking/screensaver doesn't kick in while video is playing (defaults, --stop-screensaver=yes) Screen blanking/screensaver doesn't kick in at all (--stop-screensaver=always)
Actual Behavior
Screen blanking/screensaver starts, even while the video is playing.
This doesn't happen with --vo=gpu-next
Log File
Sample Files
No response
I carefully read all instruction and confirm that I did the following:
- [X] I tested with the latest mpv version to validate that the issue is not already fixed.
- [X] I provided all required information including system and mpv version.
- [X] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of
--log-file=output.txt. - [X] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
- [X] I attached the full, untruncated log file.
- [X] I attached the backtrace in the case of a crash.
[ 1.948][v][vo/dmabuf-wayland/wayland] Enabling idle inhibitor
mpv is doing everything fine from its side, this is probably a KDE bug because it's confused about subsurfaces
Reported against powerdevil then: https://bugs.kde.org/show_bug.cgi?id=495375
Let's see.
We had similar issue in the past on mutter (#14206) and the culprit ended up being that we didn't set the idle inhibitor on the surface actually playing the video and changed it to that. I think the change for mutter was correct however so I would expect kwin needs a fix.
set the idle inhibitor on the surface actually playing the video
To be clear, we should set the idle inhibitor on the surface that's always visible. This is the video subsurface, but the osd subsurface may be above it which might cause Kwin to think the video surface is occluded? Can't think of anything else
btw. I experience the video turning black with vo=dmabuf-wayland, when screen geometry changes (i.e. additional displays get turned on / off), pausing/unpausing doesn't help - moving foward/backward does though.
And strange behavior with i and o when paused, info / progress doesn't always show on the video, often needs two or more button presses. Are these kwin issues as well or should I open new issues here?
Those sound like kwin problems to me. Changing around outputs shouldn't affect the idle inhibitor.
No, these two issues don't relate to the idle inhibitor, and thus not to this issue. I'm just unsure where to file them.
Oh I thought by "turning black" you mean the idle inhibiting thing not actually rendering black. You can open up a new issue here although it's not clear to me why that would happen (does sound like upstream but I didn't verify myself yet).
Wherever the bug exists, it's still an issue.
mpv --version
mpv v0.40.0-dirty Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
built on May 21 2025 20:53:16
libplacebo version: v7.351.0
FFmpeg version: n7.1.1
FFmpeg library versions:
libavcodec 61.19.101
libavdevice 61.3.100
libavfilter 10.4.100
libavformat 61.7.100
libavutil 59.39.100
libswresample 5.3.100
libswscale 8.3.100
Arch Linux
Linux host 6.14.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 29 May 2025 21:42:15 +0000 x86_64 GNU/Linux
[AMD/ATI] Navi 48 [9070 XT] [1002:7550] (rev c0)
Mesa 25.1.1-arch1.2
plasma-desktop 6.3.5-1
Graphics Platform: Wayland
Arch Linux repos for all involved software
New system, first time using Wayland too.
Related KDE bug https://bugs.kde.org/show_bug.cgi?id=495375
Please reply to that KDE issue instead, this is purely a Kwin bug there's nothing mpv can do here.
Future visitors should also add their impacted status to the KDE bug thread. I did my part (for now) last night. They really are only monitoring the top layer in a 'stupidly smart' sort of way, instead of just doing the correct thing and assuming any layer with the flag is intended to be visible / have an impact.
https://bugs.kde.org/show_bug.cgi?id=495375
it occurs in Plasma6.4.0 (kwin-wayland) with not only --vo=dmabuf-wayland, but also --vo=gpu-next
