https://bugs.kde.org/show_bug.cgi?id=369129
Jakob Petsovits <jpe...@petsovits.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Powerdevil does not provide |Powerdevil does not provide
|a way to inhibit screen |a way to inhibit display
|saving |turn-off
CC| |jpe...@petsovits.com
--- Comment #6 from Jakob Petsovits <jpe...@petsovits.com> ---
I'll take a shot at reviving this 7+ years old bug. A lot has changed since
Plasma 5.7.3, and PulseAudio is also on its way out, but perhaps the underlying
concerns are still valid.
Importantly, Plasma on Wayland does not have a concept of screen savers. If
someone wants to invoke a "screen saver" overlay window after a period of
inactivity, that's possible, but it doesn't look like screen savers as a Plasma
concept are going to make a comeback outside of the lock screen itself.
So let's look at the lock screen specifically.
Plasma 6.0 still supports the old FreeDesktop inhibit interface, and also the
newer systemd-logind inhibit interface with "sleep" and "idle" inhibitors.
"sleep" works like the old InterruptSession policy, meaning it will merely
prevent the system from suspending. "idle" is the policy to prevent both
locking and turning off the screen, also known as ChangeScreenSettings
internally. PowerDevil in 6.0 will still turn off the screen if the screen
locker is already active, with the rationale that no screen contents are worth
saving when they're already obscured by the lock screen.
Plasma 6.0 continues to have a user option for the duration until the
display(s) turn(s) off, as well as a new option for the display turn-off
duration when the screen is locked. One could implement the request by merely
setting these configuration values to infinite (i.e. never turn off the
display) but that's not a D-Bus inhibitor interface, so it would have to
override the user's own setting and probably for multiple power state profiles,
too. That's not a good solution for temporary inhibition.
I wonder if the best course of action would be to open a discussion in the
systemd issue tracker, with the same arguments. On the other hand, unlike
system suspend or shutdown, DPMS is generally owned by the desktop environment
(in Wayland: the compositor itself) so systemd would not provide any behavior
for this inhibitor by itself, it would rely on session services to implement it
in the first place. Probably a good argument for sticking with a Plasma-first
approach.
Either way, it seems to me that the requested interface is related but distinct
from the "idle" inhibitor. Perhaps it's worth considering to rename the
existing ChangeScreenSettings policy to something that more closely represents
the systemd "idle" inhibitor definition. And then reintroduce
ChangeScreenSettings with a new enum value as a third policy, which is
inhibited if an "idle" inhibitor exists, but can also be set independently.
--
You are receiving this mail because:
You are watching all bug changes.
