Hyprland: DPMS does not turn on again

Hyprland Version

System/Version info
Hyprland, built from branch  at commit 791e1b96b3cd12d56648b3ce7ffb0832eba2b37d  ().
Date: 2024-01-23
Tag: 

flags: (if any)

Bug or Regression?

Bug

Description

When I turn my monitors off with hyprctl dispatch dpms off everything turns off, but when I try to turn them back on again with hyprctl dispatch dpms on only my secondary/external monitor turns on. I also checked the versions v0.33.0 and v0.34.0 and the problem is there as well.

My current preferred monitor config is:

monitor=eDP-1,1920x1080@60,0x0,1
monitor=, preferred, auto, 1

But this config results in the mentioned problem.

When changing the monitor config to just monitor=, preferred, auto, 1 or to

monitor=eDP-1, preferred, auto, 1.333333
monitor=, preferred, auto, 1

the problem only occurs after some time, i.e., dpms off and on again turn off and on all monitors. I usually notice it again during lid-switching during a normal workday.

The default resolution of eDP-1 is 2560x1440 but I want to use 1920x1080 without scaling to prevent scaling issues with some programs.

How to reproduce

Set a custom resolution and run hyprctl dispatch dpms off and hyprctl dispatch dpms on.

Crash reports, logs, images, videos

No response

About this issue

  • Original URL
  • State: open
  • Created 5 months ago
  • Reactions: 1
  • Comments: 16 (4 by maintainers)

Most upvoted comments

firstly, LCD does not get permanent burn in. secondly, burn in from 2 weeks of anything is laughable and if it is there you should rather refund your monitor and not cry online. thirdly, this issue is about monitors being unable to wake up, so you got burn in from your screen being off? lastly, your entitled attitude as if you’re paying for hyprland is out of place.

I have never encountered this and neither has anyone from the active hyprland users I have constant contact with.

You are not an authority, you are not entitled to any bugfixes whatsoever, and I will continue to lead the project as I deem fitting. Claiming this bug is “destroying screens” is laughable.

Again, if you can reproduce it and it’s such a big deal to you, this is FOSS, you can try and fix it yourself.

I have the same problem. I change my monitor configuration as below.

# monitor=eDP-1,1920x1200@60,0x0,1   # error happens when using this comfiguration
monitor=eDP-1,2560x1600@60,0x0,1.333333
monitor=HDMI-A-1,1920x1080@60,0x-1080,1

That works for me.

I also have the same problem. Thanks to WuG978 for a workaround! I have this issue on my Dell Laptop with a 4k screen. I was setting the resolution of the eDP-1 display to monitor=eDP-1,1920x1080@60,0x0,1 changing it back to native resolution: monitor=eDP-1,3840x2160@60,0x0,2 prevents the issue.

As long as I have the monitor set to 1920x1080, hyprctl dispatch dpms off will permanently turn off the monitor on that tty until Hyprland is killed, with no way to turn it on as hyprctl dispatch dpms on does nothing.

I’m running into the same issue on my Tuxedo Infinnitybook Pro 14.
The display’s native (preferred) resolution is 2880x1800 at 90Hz. However, I want it to render at 1920x1200, in order to be able to read things on my screen without a magnifying glass.

To test the behavior, I am simply running:

hyprctl dispatch dpms off && sleep 2 && hyprctl dispatch dpms on

Display does not turn back on with hyprctl dispatch dpms on with my monitor configuration:

monitor = eDP-1, 1920x1200@90, 0x0, 1  # fails to turn screen back on

It does however work, when I set the monitor to full resolution, using the preferred setting:

monitor = eDP-1, preferred, 0x0, 1  # succeeds to turn screen back on

Interestingly, one workaround for me that does achieve my preferred display size and appears to work is tweaking the scale factor, rather than the resolution. This however has some other downsides (I found that some applications fail to properly render at the correct display size when changing the scale factor):

monitor = eDP-1, preferred, 0x0, 1.5 # succeeds to turn the screen back on, but has some drawbacks

Just a heads up. I tested it in sway, where turning it off and on again works. I try to look deeper into it.

I had outlines of the buttons and status bars on the screen. Ofc it does not matter what the maintainer thinks or not, his poor people skills aside, things are what they are. Luckily, the error was not permanent in the end. It still looks like shit to have button imprints on the screen that only goes away after turning the screen off for a long time.

I do not mind that the maintainer has poor people skills. I do however mind that he leaves poor code. Sway has the same problem with community mgmt. so I think it is just a fact of the kind of people that are capable of developing this kind of software that I use will be lacking in how they deal with criticism of their work.