| Summary: | mpv idle inhibition doesn't work with dmabuf-wayland | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | FK <fk-kde-bugs> |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | dreamkepeer, g311571057, i, mariusz.libera, micraft.b, mjevans1983, natalie_clarius, vgrechannik, w.elwood08+kde, wachidadinugroho.maya, xaver.hugl |
| Priority: | NOR | Keywords: | regression, wayland-only |
| Version First Reported In: | 6.3.5 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
FK
2024-10-26 11:17:22 UTC
https://github.com/mpv-player/mpv/pull/14209/commits/79b3866d6ef58e2de3d696ac3f4d7f11390a127b this mpv fix likely broke it Yeah, KWin only sets up idle inhibit for the main surface of toplevels, not their subsurfaces. That's definitely wrong. 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. (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. 1) The way MPV uses a subsurface for video and a transparent layer over it for OSD is probably correct. KDE should assume the layers are transparent (probably don't even bother testing, if they weren't the app should be smart enough to cull itself), and honor the inhibit flag for _any layers that have it_, irrespective of stack depth. 2) The correct behavior for a video that's playing in Firefox is to also inhibit. However it _greatly irks me_ that browsers no longer default to videos to remain stopped until a user actively engages with a play button. That's the real bug for Firefox. Additionally (empowering end users) they should be allowed to Opt In to allowing websites to auto-play on a domain by domain (maybe with wildcards if they want) basis. I spent at least 20 min trying to search https://invent.kde.org/plasma/kwin for a function that would ** return a list of all layers / surfaces ** (to then test) as I think the source of this bug might be: https://invent.kde.org/plasma/kwin/-/blob/master/src/idle_inhibition.cpp#L78 if (visible && client->surface() && client->surface()->inhibitsIdle()) { The test shouldn't only scan the top most layer (which is what surface() grabs), but instead ** (more ideally) the inhibits idle attribute should be stored / tested on the entire window object, irrespective of what layer, ** OR in this test, it should scan every layer. Between the two options I'd rather a single window-flag bit somewhere be used rather than walking every layer every time. + Arguably this type of 'inhibits idle in a layer beneath a transparent (fully occluding if not transparent) surface' issue is also a presently missing test case: https://invent.kde.org/plasma/kwin/-/blob/master/autotests/integration/idle_inhibition_test.cpp I've also added regresion and wayland-only as just a day ago when I was using x11 and the same Arch Linux software stack on my old PC I didn't have this issue during video playback. As there is not a separate field to track what version is still affected, and since some bot apparently auto-closes bugs that are reported in a version that's "too old", I've increased the only 'reported version' field accordingly to the present highest reproduced bug version. *** Bug 505599 has been marked as a duplicate of this bug. *** This issue has been open for nearly 8 months, and likely going on 2 major releases of KDE Plasma. I still haven't seen any engagement from anyone that seems qualified to turn the general outline of a solution into what sure looks like would be an easy patch if I only understood the subsystems involved and the consequences of changing things. I see no indication that there is even a goal of solving this in KDE 6.5, let alone 6.4 which is supposed to be out soon. 6.4 is out and still is affected As a workaround, here is a mpv plugin that does inhibition by using dbus: https://github.com/mar04/mpv_inhibit Confirmed still broken: Operating System: Arch Linux KDE Plasma Version: 6.4.1 KDE Frameworks Version: 6.15.0-1 kpackage (kf6) not sure what ArchLinux calls this, but everything tagged kf6 is the same version Qt Version: 6.9.1-2 qt6-base (qt6) Kernel Version: 6.15.4-arch2-1 (64-bit) Graphics Platform: Wayland Graphics Processor: amdgpu Still broken Operating System: Arch Linux KDE Plasma Version: 6.5.3 KDE Frameworks Version: 6.20.0 Qt Version: 6.10.0 Kernel Version: 6.17.9-2-cachyos (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 9800X3D 8-Core Processor Memory: 64 ГиБ of RAM (62.4 ГиБ usable) Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS |