Per-output power management

[agausmann]

Follow-up from #1108 (comment) , I think if Niri is going to implement the wlr-output-power-management protocol, it needs to be able to control each output individually. However, Niri's current implementation of power management has some behaviors that conflict with this:

1. The actions PowerOffMonitors and PowerOnMonitors, which set the state of all monitors.
2. Niri automatically powers on all monitors when user input is detected.

There are a few resolutions that we could consider:

(a) Share the same state / unify?

For example, if the per-output power management stores a power state for each output, PowerOffMonitors and PowerOnMonitors could set all of those states. But in that case, behavior 2 would constantly override the per-output values, defeating the point of adding per-output power management. In this case, it would make sense to remove behavior 2, or at least make it possible to disable it.

(b) Separate states?

If we want to keep the current behaviors (in particular, behavior 2) as a built-in "screensaver" feature, it could keep its state separate from the per-output states. When not in screensaver mode, each output uses its own state to set its power mode. When the screensaver mode is turned on, it overrides the per-output states, blanking all displays.

(How should this interact with the state reported by wlr-output-power-management? If it reports the displays as "off" during screensaver mode (as they really are off), and a wayland client tries to turn on a display in that state, what should happen?)

[YaLTeR]

Hmm, so let me somewhat take back my comment in the PR. Why would you want separate power states for outputs, like, as a user? I think so far we've been fine with unified state, so let's go with the unified state like in your PR? And then if there's a problem, we can think about it knowing more context.

[agausmann]

As an anecdote, when I had a multi-monitor setup on my desktop, it was nice to be able to simply blank other displays when watching a video to reduce the background light level. That is possible on other wlr compositors like sway and river, but not yet on niri.

Likewise, when connecting to a projector or TV, some users may prefer to blank the PC display. The two main ways to do this are power management or completely removing the output from the compositor, but they're not the same. If the output is removed, then all of the workspaces move to another output. but with just power management, the workspaces stay on that output.
I really appreciate the work you've put into preserving the workspace arrangement, it's a very nice experience, but it's not what I prefer for cases like this, where the change is temporary and/or each output has a different purpose.
(update: i learned a bit more about niri's output X off and output X on, and may reword this later)

I think the strongest argument is the one I already shared in my other comment: principle of least astonishment. If the protocol only provides per-output power management, then users expect it to work that way, and they may have developed their own use cases for it.

[YaLTeR]

You can always press the physical button on the monitor if you want to power it off temporarily without disconnecting from niri. Or as you said use output off.

I think the strongest argument is the one I already shared in my other comment: principle of least astonishment. If the protocol only provides per-output power management, then users expect it to work that way, and they may have developed their own use cases for it.

The users don't use the protocol, they use tools that use the protocol. (And it doesn't appear that many people use this in general, I don't think I've got any questions about it.) If the tools provide a way to turn off all outputs and that's the most used function, then it's ok for niri to keep working the way it does. Otherwise I could argue that maybe niri shouldn't implement this protocol altogether, since its mode of operation doesn't match the expected behavior.

[agausmann]

Ok, I think I can provide a better argument in support, if I take a step back.
I'm just going to focus on these features: lock screen, idle timeout, and DPMS, which are often used together, and is the main reason why I'm pushing for this.

The wlroots-ish ecosystem looks like this:

• Lock screens - protocol ext-session-lock-v1. I can bring my lockscreen to any supporting compositor and it pretty much "just works" (swaylock is my go-to).
• Idle timeouts - protocol ext-idle-notify-v1. I can run whatever program I want to listen to the idle state (for example, swayidle).
• Display blanking / DPMS - protocol wlr-output-power-management-unstable-v1 (which i will abbreviate as wlr-opm). The program wlopm provides a CLI for this protocol, which will work for every compositor that supports it.

Many well-known wlroots and Smithay compositors implement all three of these - for example, Sway, River, Hyprland, COSMIC, and LabWC.

With these 3 protocols, in theory I can write a single config using swayidle, swaylock, and wlopm to implement the same lockscreen and screensaver behavior in all of these compositors (although in practice, I've only really tested on Sway and River) - for example, to turn off the display after 10 seconds of idle at the lockscreen:

timeout 10 'pgrep swaylock && wlopm --off *' resume 'pgrep swaylock && wlopm --on *'

However, Niri is not compatible with this. Without consensus on wlr-opm, I have to write a separate config for Niri, or figure out some other way (e.g. write a helper script) to switch between different commands for DPMS, depending on which compositor is running.

To me, this justifies having some implementation of wlr-opm for better interoperability. I'll admit the protocol is clunky for this usecase, because most end-users only need a global control for DPMS during idle. However, it's what other compositors are already providing.

it doesn't appear that many people use this [protocol] in general

You're right, it's not very popular. Most public dotfiles that I've seen just use commands specific to a single compositor. For me, that doesn't work, It's valuable to me to be able to switch between different compositors. I'm probably the first to mention it here, but not the only one - I did get a few hits when I searched specifically for "dotfiles wlopm". So, some future newcomers may also be interested in this.

If the tools provide a way to turn off all outputs and that's the most used function, then it's ok for niri to keep working the way it does. Otherwise I could argue that maybe niri shouldn't implement this protocol altogether, since its mode of operation doesn't match the expected behavior.

My interpretation of this is that you don't want to change niri's mode of operation or you feel that you can't change it. If you have a technical reason that niri's "mode of operation" must be all-outputs (e.g. making it easier to implement #108), I would be interested in hearing your reasoning. If that decision is already made and not open for discussion, I will respect that.

After re-reading #108, I understand your motivation for a fade animation. I look forward to it, and it would be especially nice if it could also be triggered through some cross-platform interface like wlr-opm (if not that, at least some IPC commands to be able to use it from swayidle/scripts). While the animation might have some strange interactions with per-output DPMS control, I don't think they would be prohibitively incompatible with each other, but understandably could make it a little more difficult to implement.

Thank you very much for your patience and for hearing me out. I think this is the last argument I'm going to make for this. If the answer is still no, if you want to go your own way, I'll respect your decision and just adapt my config for Niri.

[YaLTeR]

My interpretation of this is that you don't want to change niri's mode of operation or you feel that you can't change it. If you have a technical reason that niri's "mode of operation" must be all-outputs (e.g. making it easier to implement #108), I would be interested in hearing your reasoning. If that decision is already made and not open for discussion, I will respect that.

I just don't really see a good enough reason for DPMS-powering off individual outputs. Not enough to justify the necessary changes to niri code to accommodate it anyway, not to mention UX design questions.

That said, your example script also powers off all outputs. Seems like it should be fairly useful even if that's the only way it works (compared to not working at all). So I say let's go ahead with #1108, controlling all outputs at once as niri currently works.

[agausmann]

(c) Reuse the code for output X off and output X on?

Something I completely overlooked before, option (b) is pretty much already implemented with IPC commands. The wlr protocol just needs to be written to do the same thing.

The only quirk is that these commands will move the workspaces on the disabled output to other outputs, which is different from how DPMS works on other compositors (leaving the workspaces where they are), but I'm fine with that. It's especially nice that niri automatically moves workspaces back when the output is re-enabled.

[agausmann]

Semantically, it is a different setting, I think it's currently linked to zwlr_output_head_v1.enabled and the corresponding requests

[YaLTeR]

Definitely don't use output off/on for power management because yeah it's a different function.