Bug 369129 - Powerdevil does not provide a way to inhibit screen saving
Summary: Powerdevil does not provide a way to inhibit screen saving
Status: CONFIRMED
Alias: None
Product: Powerdevil
Classification: Plasma
Component: general (show other bugs)
Version: 5.7.3
Platform: Other Other
: NOR normal
Target Milestone: ---
Assignee: Plasma Development Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-21 01:40 UTC by Manuel Amador (Rudd-O)
Modified: 2017-05-13 19:22 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Manuel Amador (Rudd-O) 2016-09-21 01:40:17 UTC
The D-Bus interface in Powerdevil (specifically the inhibitor interface) does not provide a working way that will let me inhibit screen saving (BUT, importantly, NOT the screen locker).

What I am looking for is a D-Bus call that will let me inhibit DPMS power save on all screens of the session, while allowing the screen saver to kick in and display itself (even if it's the blank screen saver), and the screen locker to activate.

I know I can tell the screen locker to inhibit itself, but that is the opposite of what I want, and furthermore does not prevent DPMS standby from kicking in.

This is important because I am writing a PulseAudio policy module that will prevent screen blanking on HDMI devices when HDMI audio out is being used (DPMS standby kills the audio stream as soon as it kicks in).

Thanks.

Reproducible: Always
Comment 1 Manuel Amador (Rudd-O) 2016-09-21 01:42:36 UTC
The relevant PA thread is this one:

https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-September/026910.html
Comment 2 Kai Uwe Broulik 2016-09-21 06:27:38 UTC
Interesting. I never considered keeping the screen on while locked a desirable usecase as it just wastes power. However, you just described one. :) I'll see what I can do, however, when the screen is locked PowerDevil would explicitly ignore a "keep screen on" inhibition as to not let a playing video (covered by the lock screen and thus invisible) keep the screen on indefinitely.
Comment 3 Oliver Henshaw 2016-09-21 10:45:32 UTC
I thought about this kind of thing once since I had another use-case - a screen where the speaker is powered by the monitor so DPMS would cut the sound. Fortunately in that case the monitor can be configured to keep audio power on when the screen was off.

This was part of the motivation for the proposal in bug 318461. I think that the idea was that screen locking was something that happened when the session was idle, but screen power-saving was something that happened when the screen (logind seat? device?) was idle. Then normally the screen being locked would mean the screen becomes idle but things like screen-powered audio or, now, HDMI audio could inhibit this.

More practically, it may be feasible for active HDMI audio to inhibit screen power saving in the same way external screens currently inhibit any kind of screen interruption. How does that sound, Kai?


I also wonder if this could be handled better with help from further up the stack. Is there an opportunity to do things better with wayland than with xserver dpms?

Is there a gnome (or other desktop) bug filed too, or are you only interested in a KDE Plasma solution?
Comment 4 Manuel Amador (Rudd-O) 2016-09-21 12:10:52 UTC
I don't think things further up the stack have the necessary information to make an informed decision.  The "sound card" of HDMI outs and the video cards powering them appear as different PCI devices in many cases.  Those layers up the stack also do not know how to report back to Powerdevil "well, the reason we are not shutting the screen off, is because HDMI audio is active", primarily because it is stuff like Powerdevil which is in charge of policy and setting the right DPMS configuration bits on the X server (I assume something similar happens in Wayland).

However, if Powerdevil provided an inhibitor (class) that would explicitly inhibit DPMS — but nothing else, not the screensaver, not screenlock in the screensaver, not suspend, not hibernate — then a plugin at the PulseAudio level of the stack can talk to Powerdevil and use that inhibitor class whenever there is an active HDMI audio stream, which is something that PulseAudio is perfectly positioned to know about.
Comment 5 Manuel Amador (Rudd-O) 2016-09-21 12:12:40 UTC
We should tackle the problem with KDE first, as KDE moves faster than GNOME and has a long history of innovating in this space (Solid).  A KDE-only / Powerdevil-only solution is adequate for the first iteration of the PulseAudio side of things.  Later on, we can ask the Power Manager folks to adopt the same inhibition policy.