The relevant PA thread is this one:

https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-September/026910.html

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.

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?

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.

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.

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.