dmabuf-wayland in git doesn't block the screensaver, even while videos are playing and with/without --stop-screensaver=yes|always

[fkroener]

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

mpv.log

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• 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.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[llyyr]

[ 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

[fkroener]

Reported against powerdevil then: https://bugs.kde.org/show_bug.cgi?id=495375

Let's see.

[llyyr]

Reported against powerdevil

Should be a report against Kwin

[fkroener]

Yeah, I wondered about that. Thanks.
Changed it to kwin/wayland-generic.

[Dudemanguy]

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.

[llyyr]

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

[Dudemanguy]

We are using transparent buffers for the osd though.

[fkroener]

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?

[Dudemanguy]

Those sound like kwin problems to me. Changing around outputs shouldn't affect the idle inhibitor.

[fkroener]

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.

[Dudemanguy]

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).