Bug 391995

Summary:	Inhibition handling is illogical
Product:	[Unmaintained] Powerdevil	Reporter:	Dmitry <dmitriyvalter>
Component:	general	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	kde
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Neon
OS:	Linux
Latest Commit:	https://cgit.kde.org/powerdevil.git/commit/?id=152400c1b6880506ee1395011686c2b191f419a0	Version Fixed/Implemented In:	5.13.0
Sentry Crash Report:

Description Dmitry 2018-03-18 12:52:26 UTC

Inhibition from org.freedesktop.PowerManagement.Inhibit and org.freedesktop.ScreenSaver are handled pretty much the same way with preventing both sleep/suspend and screen power saving/screen locking. 
But that's absolutely illogical as far as powerdevil supports differentiation between these two types of wakelocks (e.g. on laptop lid close when external monitor is present).
So intentions for developers using these inhibitions are absolutely clear, just take a look at chromium (chromium/services/device/wake_lock/power_save_blocker/power_save_blocker_x11.cc:282) or ktorrent (ktorrent/ktorrent/pref/generalpref.ui, ktorrent/ktorrent/core.cpp:972) sources. 

This behaviour makes system keep screen on when no one app really needs it, like chromium/vavaldi/other forks playing audio (not video) or ktorrent downloading something.

It appears at least in KDE Neon, Fedora 26 and OpenSUSE Tumbleweed with 5.10 up to latest Plasma versions.

Comment 1 Kai Uwe Broulik 2018-10-10 09:08:59 UTC

Was fixed in Plasma 5.13