Add -D/--dpms option to power off displays when idle #40
Conversation
This option makes use of the new wlr-output-power-management protocol to power off displays when swaylock is idle (i.e. when the unlock indicator, if enabled, is not shown). This approach provides far more reliable DPMS control than the currently recommended solution, which is to use something above swaylock (e.g. swayidle) to coordinate swaylock invocation with a separate swaymsg invocation to control DPMS. Since swayidle is purely input-based and cannot inspect swaylock's state, it will inevitably either power up the screens when it shouldn't or fail to when it should. For example, if swayidle is set to turn on the screens on "resume," it will do so even if the only input was a mouse bump, modifier key press, or something else that swaylock ignores completely. Signed-off-by: Thomas Hebb <[email protected]>
This fixes a critical memory error that could crash swaylock. This stems from a broader issue with wlr_output_power lifecycle management, which also prevents DPMS from working for outputs added while swaylock is running. This commit does not fix the broader issue but rather the immediate symptom of memory errors when an output is removed while swaylock is running with DPMS support turned on.
Currently we don't initialize DPMS when a new output shows up while swaylock is running. This can happen when you plug in a monitor or when you suspend and resume your system, the latter case causing the monitor to get stuck off after resume. Fix the issue by handling wlr_output_power lifecycle in the same way as wlr_layer_surface.
We should immediately update the DPMS state of all outputs after a new one is added, or else it might remain on until the next damage event calls set_dpms().
|
Sorry for the late response. I'm not opposed to this. However, I think there should be a configurable timeout; someone may want their screen to stay on for some time after locking before the display powers off. That's approximately how my setup currently works, where swayidle locks the screen after some period of inactivity, then turns off the screen 20 seconds after that. I'm aware that this will significantly complicate the logic though. Nonetheless, I think it's important. |
|
@mortie I'm using the same staged approach where I first lock the screen after an initial delay and only after a delay turn off the screen. For that usecase, swayidle is already covering configuring delays. I still see this PR useful for usecases where you want to lock instantly (e.g. by a keyboard shortcut). Please reconsider if this could be accepted. |
(Originally submitted upstream as swaywm#152, but rejected as out-of-scope.)
This option makes use of the new wlr-output-power-management protocol to power off displays when swaylock is idle (i.e. when the unlock indicator, if enabled, is not shown).
This approach provides far more reliable DPMS control than the currently recommended solution, which is to use something above swaylock (e.g. swayidle) to coordinate swaylock invocation with a separate swaymsg invocation to control DPMS. Since swayidle is purely input-based and cannot inspect swaylock's state, it will inevitably either power up the screens when it shouldn't or fail to when it should. For example, if swayidle is set to turn on the screens on "resume," it will do so even if the only input was a mouse bump, modifier key press, or something else that swaylock ignores completely.
This is a first pass at the functionality. I've been using it on my laptop with Sway for several months and it seem to work well. However, I occasionally do get in a state where the screen is stuck off after resuming, which I assume means the power manager interface has gone away. I have not yet tracked down why this happens.