Bug 495375 - mpv idle inhibition doesn't work with dmabuf-wayland
Summary: mpv idle inhibition doesn't work with dmabuf-wayland
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 6.2.2
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-26 11:17 UTC by FK
Modified: 2025-02-05 09:20 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description FK 2024-10-26 11:17:22 UTC
SUMMARY
Using the dmabuf-wayland vo with mpv doesn't inhibit KDE's screensaver from activating.
mpv appears to do the right thing, powerdevil/kwin not handling subsurfaces properly is suspected, see mpv issue: https://github.com/mpv-player/mpv/issues/15181

STEPS TO REPRODUCE
1. set the screensaver|screen blanking delay to a low value
2. run mpv --no-config --vo=dmabuf-wayland --stop-screensaver=yes|always <file>

OBSERVED RESULT
Screensaver/Screen blanking turns on, even while the video is playing (--stop-screensaver=default|yes) or paused (--stop-screensaver=always)

EXPECTED RESULT
powerdevil should recognize mpv playing and inhibiting the screen blanking. 

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.2.2
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
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

ADDITIONAL INFORMATION
Other mpv vos (e.g., gpu-next) work properly.
Comment 2 Zamundaaa 2024-10-28 22:23:52 UTC
Yeah, KWin only sets up idle inhibit for the main surface of toplevels, not their subsurfaces. That's definitely wrong.
Comment 3 Vlad Zahorodnii 2025-02-04 13:42:56 UTC
One could argue whether it's actually useful if the idle inhibitor is deactivated in case the surface gets obstructed. As a user, it would be unexpected to me. In either case, since other compositors work like this, I guess it's too late to argue.

We could look into it in 6.4. It would be nice to use the visibility state of the SurfaceItem to determine whether an idle detector should be taken into account.
Comment 4 FK 2025-02-05 09:20:29 UTC
(In reply to Vlad Zahorodnii from comment #3)
> One could argue whether it's actually useful if the idle inhibitor is
> deactivated in case the surface gets obstructed. As a user, it would be
> unexpected to me. In either case, since other compositors work like this, I
> guess it's too late to argue.
> 
> We could look into it in 6.4. It would be nice to use the visibility state
> of the SurfaceItem to determine whether an idle detector should be taken
> into account.

Aren't those separate issues though? Currently kwin doesn't appear to consider subsurfaces with idle inhibitors, which means playing a video with dmabuf-wayland doesn't inhibit power saving/screen locking at all. Couldn't this be addressed for 6.3 already?

Considering obstruction might be nice for when e.g. firefox starts using subsurfaces for playing videos. I need to manually block inhibitors from it, just so no random tab with video playing keeps my screen from turning off.