Hyprctl dispatch dpms off issues with Dell monitor over HDMI

[verystealthy]

• Steps to reproduce: Run hyprctl dispatch dpms off directly or via swayidle
• Expected outcome: Monitor stays off until dpms on is called, or input is detected.
• Noted outcome: Monitor stays off for a couple of seconds, turns on again, bypasses swaylock and jumps to a new workspace.

That being said, I am somewhat reluctant to even create this issue, because it seems like the monitor is at fault here. My hope is that folks having the same issue can find this and get some peace of mind.

The monitor in question is a Dell S3221QS connected over HDMI. swayidle calls swaylock normally after the timeout, swaylock does its job if input activity happens before hyprctl dispatch dpms off is called. If hyprctl dispatch dpms off is called, the monitor turns off, and turns back on after a few seconds. When the monitor turns back on, swaylock is bypassed, and a new workspace is created. For example, if 3 workspaces were active when hyprctl dispatch dpms off was called, workspace number 4 would be created when the monitor turns back on. Another "interesting" tidbit is that after the monitor turns back on, swayidle is no longer active unless you go back to one of the original workspaces (i.e. swayidle and swaylock won't trigger on this newly created workspace).

Looking at the logs (attached here), something is causing Events::listener_monitorDestroy to be called. After a bit of testing, it is clear that this is being caused by the monitor itself, as I've performed the following:

• Tested with three different HDMI cables: Same unexpected behavior;
• Tested both HDMI inputs on the S3221QS: Same unexpected behavior;
• Tested hyprctl dispatch dpms off on a laptop running Hyprland: Normal behavior (e.g. screen remained off);
• Tested hyprctl dispatch dpms offon a TV connected to the original computer via HDMI: Normal behavior (e.g. screen remained off);
• Reset S3221QS to factory settings: Same unexpected behavior.

Additional details:

• Hyprland 0.20.1
• NixOS 23.05 (Stoat)
• Kernel 6.1.8
• CPU: AMD Ryzen 7 3750H
• GPU: Radeon Vega Mobile Gfx

Hyprland log:

hyprland.log

[beltofdespair]

Same with crappy ViewSonic HDMI monitor. My VGA Dell monitor appears to work correctly.

[ghost]

I am having the very same issue here with a BenQ GW2283.
My main, Philips 275S1AE is working fine.

The BenQ monitor is connected over DP to HDMI
and the Philips monitor over DP to DP.

[ghost]

UPDATE:
I did a few tests:

• Connected my BenQ GW2283 over D-SUB VGA: The issue is gone
  things to note: That connection is from HDMI to VGA (with an HDMI to VGA adapter)

• Connected my Philips 275S1AE over HDMI: The issue is present
  That connection is with a DP to HDMI cable. It doesn't matter that it's a DP to HDMI cable tho as the same thing happens with a plain HDMI to HDMI cable for my BenQ GW2283 for example.

So this is definitely an HDMI issue here, D-SUB VGA and DisplayPort work fine.

Btw, in my case swaylock is not bypassed

I use this script:

#!/bin/zsh

sleep 1; hyprctl dispatch dpms off;
swaylock -c 000000;
hyprctl dispatch workspace 1;

@vaxerski This looks like a software issue, but I'm not sure.

[vaxerski]

can you test on sway-git? (important: git)

If it's reproducible there it's a wlr issue

[ghost]

Yup, tested on Sway-git, DPMS stays off there.
It's not reproducible, does this mean that it's a Hyprland issue?

[vaxerski]

It's not reproducible, does this mean that it's a Hyprland issue?

Yes

[psiho]

Same here with AOC U2790B model but with one addition... my monitor OSD turns off as soon as I turn it on! It's basically unusable because it lasts for only fraction of a second.

Maybe you could check if you have the same issue on those other monitors reported and if issue is related?

[verystealthy]

Quick add: I've removed the hyprctl dispatch dpms off from the config, and swayidle/swaylock work fine unless there's some change in the HDMI state. If, for example, swayidle is active and I use a KVM to switch the monitor to another computer, everything crashes when I return the KVM to the computer running Hyprland.

[ghost]

Here's my hyprland.log:
hyprland.log

What I did was:

• execute dbus-run-session Hyprland
• launch (my afk script) using fuzzel:

#!/bin/zsh

sleep 1;
hyprctl dispatch dpms off;
swaylock -c 000000;
hyprctl dispatch workspace 1;

• wait till DPMS on DP-3 (BenQ GW2283) turns on
• unlock swaylock
• open a terminal and copy the hyprland.log to ~/

This is my hyprland.conf:
hyprland-conf.log

This is the part from turning DPMS off till I unlock swaylock:
dpms-part.log

From what I read out of the part of the log, Hyprland destroys the monitor, then finds it and sets it up again.
It's basically doing this: https://www.youtube.com/watch?v=mvU7X67A2JI
Not to mock the software - Hyprland is amazing - but just to illustrate.

[ghost]

@verystealthy; @beltofdespair; @psiho

Hey back, I have developed a workaround using 2 shellscripts:

# Script: dpoff
while [ $DPMS = "off" ]; # For as long as the DPMS variable is set to "off",
do
  sleep 5; # wait 5-20 seconds to not make the system laggy
  hyprctl dispatch dpms off DP-3; # and ensure that the affected monitor stays off.
done

#!/bin/zsh
# Call a shell, any shell you want to use.
# Script: afk

sleep 1; # Sleep to not make the monitors wake up right away after turning DPMS off (caused by key_press_enables_dpms).
export DPMS=off; # Set the DPMS variable to off.
${XDG_PROJECTS_DIR}/dpoff & # Execute the dpoff script and fork it to the background.
# ${XDG_PROJECTS_DIR} is defined as "$HOME/Projects", basically.

hyprctl dispatch dpms off; # Turn off the other, un-affected monitors.
swaylock -c 000000; # Execute swaylock.
hyprctl dispatch workspace 1; # Go to a selected workspace to not end up in a random one, after.
killall sh; # Kill the dpoff script, so that the affected monitor won't be turned off all the time.

Hope this helps at least a bit!

[verystealthy]

Thanks, @HanoJing. I'm sure this will come in handy for someone, but I've moved on from Hyprland. I'm leaving this issue here just in case.

[CaptainJack42]

Having the same issue atm. Noticed it first when running hyprctl dispatch dpms off through swayidle, but also confirmed that it still persists when running it directly from the command line. It only happens on one of my two monitors. One is connected via DP and works as excpected, the other one is connected via HDMI and will turn back on a few seconds after dispatching dpms off. However all workspaces on the HDMI monitor are moved to the other monitor before it turns back on creating a new workspace while doing so.

hyprland.log

[ghost]

Having the same issue atm. Noticed it first when running hyprctl dispatch dpms off through swayidle, but also confirmed that it still persists when running it directly from the command line. It only happens on one of my two monitors. One is connected via DP and works as excpected, the other one is connected via HDMI and will turn back on a few seconds after dispatching dpms off. However all workspaces on the HDMI monitor are moved to the other monitor before it turns back on creating a new workspace while doing so.

hyprland.log

Same for me.

@vaxerski How's the progress on this? Thanks!

[vaxerski]

there is no progress, and please consider not adding noise. I am aware. It's not my fault your monitor(s) behave weirdly. I have other things to worry about as well.

If you want this fixed faster, make a mr yourself.

[verystealthy]

Open source, am I right?

[Thaodan]

there is no progress, and please consider not adding noise. I am aware. It's not my fault your monitor(s) behave weirdly. I have other things to worry about as well.

It might be HDMI vs Display Port or more than one screen connected.

I don't think closing the bug helps..

[CaptainJack42]

It might be HDMI vs Display Port or more than one screen connected.

My thought exactly. I might be able to look into this soon™, but will definitely need some time getting familiar with the codebase and so on.

Edit: Also what is kinda scary (imo) about this is the window manager being able to bypass swaylock

[vaxerski]

Edit: Also what is kinda scary (imo) about this is the window manager being able to bypass swaylock

Hyprland is not a window manager. It's the entire display server, like Xorg itself. Again, don't know how many times I have to repeat that.

swaylock is not possible to bypass if you update it to use the proper protocol and stop using a horribly outdated fork.

I don't think closing the bug helps..

I don't think so either, but some people apparently expect undivided attention from me at all times and bugfixes within 10 minutes. I am not in any way, shape, or form obliged to give any support. I work on things that I deem the most important at a given time. Doesn't mean I will never work on your issue, it just means there are more pressing ones.

Adding to the fact of course that I do not use HDMI anywhere and have never seen this happen myself, so I can't repro.

[psiho]

well, this escalated quickly. I understand some people expect "undevided attention" as you say, but what about many others, having the same issue, that are not? Closing the issue in this manner is just... mah.

[vaxerski]

Umm, consider reading who closed it. Not me.

[verystealthy]

My apologies. I think I might have given the impression that I still care about this issue, Hyprland, or extremely low stakes drama. About three months ago (give or take), I went through the trouble of gathering the information required for a useful bug report, submitted it, and that was it. It went unassigned, unacknowledged, and no further information was asked. I have since moved on from, well, all of this, but I keep getting notifications from GitHub about the issue. Needless to say that those notifications are a nuisance, entitled users are indeed annoying, and bitchy developers, who—much like DJ Khaled—seem to be suffering from success, are tiresome. Given all that, I did indeed close this. So, reopen the issue. Create a new one. Move away from Hypland. Purchase a Mac. I do not care. Just let this particular thread die peacefully and let's all move on with our lives.

[Thaodan]

My apologies. I think I might have given the impression that I still care about this issue, Hyprland, or extremely low stakes drama. About three months ago (give or take), I went through the trouble of gathering the information required for a useful bug report, submitted it, and that was it. It went unassigned, unacknowledged, and no further information was asked. I have since moved on from, well, all of this, but I keep getting notifications from GitHub about the issue. Needless to say that those notifications are a nuisance, entitled users are indeed annoying, and bitchy developers, who—much like DJ Khaled—seem to be suffering from success, are tiresome. Given all that, I did indeed close this. So, reopen the issue. Create a new one. Move away from Hypland. Purchase a Mac. I do not care. Just let this particular thread die peacefully and let's all move on with our lives.

You can disable notifications for this issue..

[ghost]

My apologies. I think I might have given the impression that I still care about this issue, Hyprland, or extremely low stakes drama. About three months ago (give or take), I went through the trouble of gathering the information required for a useful bug report, submitted it, and that was it. It went unassigned, unacknowledged, and no further information was asked. I have since moved on from, well, all of this, but I keep getting notifications from GitHub about the issue. Needless to say that those notifications are a nuisance, entitled users are indeed annoying, and bitchy developers, who—much like DJ Khaled—seem to be suffering from success, are tiresome. Given all that, I did indeed close this. So, reopen the issue. Create a new one. Move away from Hypland. Purchase a Mac. I do not care. Just let this particular thread die peacefully and let's all move on with our lives.

If I was Vaxry, I would be easily stressed out, given how much they work. And I think that it is totally ok and necessary for them to rightfully stand their ground and reject issues that are unimportant. I don't expect anything from them, I was just asking. And I wanted to help them and the people who have this issue by mitigating the issue with the shellscript I wrote.
A wide user base behind a software sure brings more bug reports with it, but it can also help make the software better.
I just want to help developers, not be entitled and expect unimportant or impossible things. I especially don't expect anything since Open Source is a labour of love most of the time and they don't get paid for it. I apologize If I sounded entitled, it's not my intention.

[simskij]

Thanks for all your hard work, @vaxerski!

For anyone else still having issues with getting this to work, here's the locking script I run which works flawlessly both with HDMI and DP:

swayidle \
    timeout 1 'hyprctl dispatch dpms off' \
    resume 'hyprctl dispatch dpms on' & 
swaylock -c 000000ff --image ~/.wallpaper.png
kill %%

Adjust timeout duration and other settings to your liking.

[beltofdespair]

After a frankly absurd amount of testing, it seems that for me that script works, but only if I leave timeout at 1. Any other number and the monitors immediately turn back on. A real head scratcher. But that might be enough to lure me back from Sway. On Arch Linux with latest release version 0.26.0-1.

[Arroquw]

I'm running into the same issue with an MSI MAG274QRF-QD. DPMS doesn't stay off, and in swaylock/swayidle it keeps turning it off and then on again until finally it crashes with a red screen of death.

[Arroquw]

After further testing, it seems not to be my MSI monitor but instead the dell secondary monitor. It keeps turning on immediately after turning itself off on the "no output on DP" message.

Both my monitors are running purely on DP. No HDMI nor converters.

[ghost]

After further testing, it seems not to be my MSI monitor but instead the dell secondary monitor. It keeps turning on immediately after turning itself off on the "no output on DP" message.

Both my monitors are running purely on DP. No HDMI nor converters.

That's interesting, so it's not an HDMI issue then. I will test this again soon and see if things have changed now that Hyprland has evolved a lot more.

[Arroquw]

I did some more testing, and it actually seems to be an issue with my wireless mouse. I have a logitech g pro wireless, and if I disable mouse_move_enables_dpms and also remove the resumecommand from my swayidle (I'm using nixos):

-        resumeCommand =
-          "${pkgs.hyprland}/bin/hyprctl dispatch dpms on";
+        #resumeCommand =
+        #  "${pkgs.hyprland}/bin/hyprctl dispatch dpms on";

It will work, however, my 2nd monitor won't turn on when I unlock swaylock. My primary MSI monitor turns on fine, however.

If I enable mouse_move_enables_dpms, and take out the wireless receiver of my mouse from its usb port, it also works. Flipping the switch on my mouse, however, does not work.

In either case, it doesn't enable the dell monitor on unlock, as I removed the swayidle resumecommand and thus have to run hyprctl dispatch dpms on manually.

Not sure if my issue is exactly the same as the reported one, in my case at least it's definitely swayidle/hyprland responding wrongly to my wireless mouse. Also, swaylock is not bypassed and no new workspaces are created.

[ghost]

Hmm weird, I have an issue with mouse_move_enables_dpms as well
in that it just turns on DPMS right after disabling it, without moving the mouse at all. This is why I have disabled mouse_move_enables_dpms.
Your issue doesn't seem to be what has been reported though.

My BenQ GW2283 will come on again a few seconds after DPMS has been turned off. Maybe it's the screen-brightness indicator of my monitor that causes it to want to turn on again who knows.

[p4rfait]

I had this issue with an HP monitor (HP M24fw FHD 3CM2230DRR). I simply disabled the 'Auto-Switch Input' feature in it, and since then, it has been working as expected. If this doesn't work try disabling any other automatic options your monitor may have; maybe one of them is causing the issue.

[ghost]

I had this issue with an HP monitor (HP M24fw FHD 3CM2230DRR). I simply disabled the 'Auto-Switch Input' feature in it, and since then, it has been working as expected. If this doesn't work try disabling any other automatic options your monitor may have; maybe one of them is causing the issue.

Thanks for the suggestion, it sadly didn't work for my monitor model, good that you mention it though. My monitor seems to turn on because it wants to show me some icon regarding brightness. It doesn't want to not shot it even when turning off auto-brightness.

[Lassebq]

Update on this:
This is most likely related to a 4 year old bug
Seems to happen on older AMD GPUs (I could reproduce it with my Radeon RX 580, Never had this problem on nvidia)
And considering the original reporter has Vega Graphics, it's probably one of affected GPUs too

[Lassebq]

amdgpu.dc=0 kernel parameter does fix the issue on my side. I'd suggest giving it a try.

[beltofdespair]

Radeon RX 550 here, amdgpu.dc=0 kernel parameter appears to be working so far. I can turn the monitors off and use hyprctl dispatch dpms off without issue.

[Lassebq]

Do note that it will prevent HDMI audio from working, so if your setup involves using that (Mine for example did), you may want to stick to broken Display Core

[pkulak]

Turning off auto input select on my Dell fixed it for me also, fwiw.

[grizzz1y]

Using HDMI on Samsung monitor, turned auto source to manual solved the problem for me! Thanks for continuing the comments.

[musjj]

@beltofdespair
I'm using RX 550 too, but amdgpu.dc=0 didn't help. After turning on the dpms, I'm still thrown into a random empty workspace.

[FShou]

I've found really good work around for this using ddcutil + hypridle

# dpms
listener {
    # DPMS TIMEOUT
    timeout = 120
    # DPMS ONTIMEOUT
    on-timeout = ddcutil setvcp d6 4
    # DPMS ONRESUME
    on-resume = ddcutil setvcp d6 1
}

[lakshya-sky]

I have a monitor on which I can't turn off auto input switch so I made script to send dpms off repeatedly.

dpms-off.sh

#!/usr/bin/env bash

start_time=$(date +%s)
end_time=$((start_time + 30))

while [[ $start_time -lt $end_time ]]; do
  sleep 0.1
  hyprctl dispatch dpms off &>> /tmp/dpms-off.log
  start_time=$(date +%s)
done

listener {
  timeout = 620
  on-timeout = ~/.config/hypr/scripts/dpms-off.sh
  on-resume = hyprctl dispatch dpms on
}

[Arroquw]

Turning off auto scan on my MSI monitor fixed the issue for me, dpms will stay off on both of my monitors now. The only thing that I did need in my config is to remove mouse_move_enables_dpms as somehow my wireless mouse can't not send data.