Screen doesn't turn off / power management options don't work / Screensaver doesn't activate

[tzell]

What is the output of

Code: Select all

xset -q

I seem to have isolated the problem

The issue seems to be with the graphics card HDMI port
I have two screens connected, one through DP and the other HDMI

One screen connected with just DisplayPort - monitor standby works!
The same one screen connected through HDMI port - the problem occours, monitor wakes up after a second.
I tried both HDMI ports, both cause issue.

Does this help perhaps?

[SMG]

Does this help perhaps?

The person in the other topic just posted the reverse. Problems with DP, but not HDMI.

I'm in a different time zone than both of you so it will take me a little time to catch up and see what I can find related to the issue. They have Intel graphics while you have AMD which would mean different graphics drivers, both drivers for each of those are in the kernel. They found they could use the same xanmod1 kernel for both LM20.3 and LM21, but only had the problem with LM21.

[tzell]

Pretty strange we're both having the same issue just with opposite connectors causing the problem.

[SMG]

One screen connected with just DisplayPort - monitor standby works!
The same one screen connected through HDMI port - the problem occours, monitor wakes up after a second.
I tried both HDMI ports, both cause issue.

Does this mean you only had one monitor attached at time? Or did you always have one attached to a DP port? Your xrandr info indicates there are two DP ports which is why I ask. (Didn't know if maybe you could hook both monitors using DP.)

The next time the stand-by does not work, run the following in a terminal and we'll see if there might be any clues as to what is happening.

Code: Select all

dmesg -T | tail -n 200

The other person noticed some specific errors related to their graphics driver (Intel) when doing this.

Tests they did with different DPMS settings seem to indicate DPMS is not the issue.

[tzell]

1. yes I have two monitors connected one to DP and one to HDMI.
I can try to buy an hdmi - displayport adapter and plug the hdmi screen into the DP for a workaround,
I guess there's no other way to solve it for now?

2. dmesg doesn't seem to indicate any error when I run it after failing stand-by mode
system logs don't seem to indicate anything either
How do I check for more places for errors?

3. What kind of tests should I try with the DPMS to make sure thats not the issue?

[SMG]

1. yes I have two monitors connected one to DP and one to HDMI.
I can try to buy an hdmi - displayport adapter and plug the hdmi screen into the DP for a workaround,
I guess there's no other way to solve it for now?

I asked the question to make sure it wasn't an issue of only one monitor being attached. I do not know for sure if two DP connections will work because I'm not sure what is causing the issue.

The other person had LM20.3 installed before moving to LM21. Even with the same kernel being used for both, LM20.3 works.

2. dmesg doesn't seem to indicate any error when I run it after failing stand-by mode
system logs don't seem to indicate anything either
How do I check for more places for errors?

dmesg is where I usually check for error messages, especially of this type.

3. What kind of tests should I try with the DPMS to make sure thats not the issue?

roblm made suggestions in this post and one subsequent one, but you already have the screensaver set to 0 (based on your xset -q output) so not sure how helpful those tests might be.

[tzell]

The other person had LM20.3 installed before moving to LM21. Even with the same kernel being used for both, LM20.3 works.

That made me think, it would seem another component is causing the issue then.
I tried installing MATE desktop env and switch to that (instead of cinammon) - didn't solve it.
I tried cinammon 'software rendering' - didn't solve it.

Is there perhaps an operation system 'safe mode' mode I can boot into?
Would that help?

roblm made suggestions in this post and one subsequent one, but you already have the screensaver set to 0 (based on your xset -q output) so not sure how helpful those tests might be.

Yeh I tried running those tests too, didn't help.

[tzell]

I also tried playing around with xrandr output options, let me know if it helps:

1.

Code: Select all

xrandr --listmonitors
Monitors: 2
 0: +*DisplayPort-0 3840/697x2160/392+3840+0  DisplayPort-0
 1: +HDMI-A-1 3840/598x2160/336+0+0  HDMI-A-1

Tried turning off just the HDMI monitor - it wokeup by itself (same problem)

Code: Select all

xrandr --output HDMI-A-1 --off

Now here's where things get different -
tried turning off just the DisplayPort monitor - it worked.
monitor went to sleep, while the HDMI monitor kept active (both were connected at the same time)

Code: Select all

xrandr --output DisplayPort-0 --off

So this time, monitor standby mode worked just for the displayport monitor,
while both screens were connected as long as just the displayport screen got the turnoff command.

2.
Another thing I noticed while trying

Code: Select all

xrandr --verbose

DisplayPort monitor has -VSync

Code: Select all

DisplayPort-0 connected primary 3840x2160+3840+0 (0x59) normal (normal left inverted right x axis y axis) 697mm x 392mm
3840x2160 (0x59) 533.250MHz +HSync -VSync *current +preferred
        h: width  3840 start 3888 end 3920 total 4000 skew    0 clock 133.31KHz
        v: height 2160 start 2163 end 2168 total 2222           clock  60.00Hz

HDMI monitor has +VSync

Code: Select all

HDMI-A-1 connected 3840x2160+0+0 (0x60) normal (normal left inverted right x axis y axis) 598mm x 336mm
1920x1080 (0x60) 148.500MHz +HSync +VSync *current +preferred
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.50KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  60.00Hz

Perhaps the issue has something to do with the +VSync versus the -VSync thing?

Does that help?

Edit: I set the HDMI monitor mode to the following:

Code: Select all

1920x1080 (0x7f) 170.000MHz +HSync -VSync *current
        h: width  1920 start 1928 end 1960 total 2026 skew    0 clock  83.91KHz
        v: height 1080 start 1105 end 1113 total 1119           clock  74.99Hz

with "-vsync", still problem persists. So probably not related?

[SMG]

Now here's where things get different -
tried turning off just the DisplayPort monitor - it worked.
monitor went to sleep, while the HDMI monitor kept active (both were connected at the same time)

Code: Select all

xrandr --output DisplayPort-0 --off

So this time, monitor standby mode worked just for the displayport monitor,
while both screens were connected as long as just the displayport screen got the turnoff command.

That would seem to be in line with your earlier observation that the DP port works.

Perhaps in whatever code tells the monitors to go to sleep, the HDMI gets the signal first and because that is not working then the DP also does not shut off when both are connected? Just a theory that might fit in with your observations.

with "-vsync", still problem persists. So probably not related?

If you do a search on what vsync is, it should not be related at all to this issue.

[tzell]

Yes I thought perhaps the vsync thing was interrupting also it was a difference I could see between the screens

[ekarnots]

For what its worth, I am having the screensaver not activating on a dell e6400 laptop screen after moving to lm21 from lm20.3. had no issues on 20.3! Power management also does not function! Using invidia drivers.
No biggee but it would be nice if it worked!

[SMG]

For what its worth, I am having the screensaver not activating on a dell e6400 laptop screen after moving to lm21 from lm20.3. had no issues on 20.3! Power management also does not function! Using invidia drivers.
No biggee but it would be nice if it worked!

If you would like help on your issues, please create a new topic and supply the complete system info and how Mint sees your system in the first post.

[tzell]

Guys I thought of a workaround,
just need to know if possible to automate it:

Basically - if I 'unplug' disconnect the problematic screen using display layout settings,
then the other screen can get to standby mode without a problem:

(in the picture, monitor number 1 is the HDMI problematic port that keeps waking the screens up from standby)



so it leaves just monitor number 2, then standby mode works


So - is there a way to automate this process with a script / tweak?

Once standby mode time arrives ->
1. disconnect screen "1"
2. put screen 2 on "standby mode"

Once standby mode expires (mouse click, keyboard input)
1. reconnect screen "1" (hopefully using last configuration position wise)
2. get out of "standby mode"

[SMG]

Guys I thought of a workaround,
just need to know if possible to automate it:

Basically - if I 'unplug' disconnect the problematic screen using display layout settings,
then the other screen can get to standby mode without a problem:

Is that not the same thing you did with the xrandr command you posted earlier?

Code: Select all

xrandr --output DisplayPort-0 --off

While you could make a script with that line in it, I am not sure how doing that and then doing the reverse might impact apps you have open on that screen. I know shifting of apps to a different screen was an issue with the prior version of Cinnamon. I do not know if the rebase to mutter completely resolved that issue in LM21.

When you tested that earlier, did resume from suspend keep everything where you had it originally?

[tzell]

Is that not the same thing you did with the xrandr command you posted earlier?

Code: Select all

xrandr --output DisplayPort-0 --off

When you tested that earlier, did resume from suspend keep everything where you had it originally?

Its not the same thing I think, since the xrandr command doesn't solve it, the screen turns back on immedietly.
Perhaps there's a different command to unplug the screen? xrandr doesn't do the trick.

And no, resuming did not keep everything where it was originally.

[SMG]

I went through some of the GitHub repositories and I just do not understand the code well enough to know what might be possible from a scripting standpoint.

Sorry, I do not have any other ideas.

[roblm]

With the Power Management settings enabled, try these commands:

Code: Select all

nohup xset dpms force off &>/dev/null &

nohup xrandr --output HDMI-A-1 --off &

Use this command and see if the screens turn off after 2 min (120 sec) of idle time:

Code: Select all

gsettings set org.cinnamon.desktop.session idle-delay 'uint32 120'

To disable the gsettings setting, use this:

Code: Select all

gsettings set org.cinnamon.desktop.session idle-delay 'uint32 0'

[tzell]

With the Power Management settings enabled, try these commands:

Code: Select all

nohup xset dpms force off &>/dev/null &

nohup xrandr --output HDMI-A-1 --off &

Use this command and see if the screens turn off after 2 min (120 sec) of idle time:

Code: Select all

gsettings set org.cinnamon.desktop.session idle-delay 'uint32 120'

To disable the gsettings setting, use this:

Code: Select all

gsettings set org.cinnamon.desktop.session idle-delay 'uint32 0'

Tried using what you wrote, sadly, same issue, screens turns off for one second then comes back to life.
This is the output:

Code: Select all

nohup xset dpms force off &>/dev/null &
nohup xrandr --output HDMI-A-1 --off &

[1] 39892
[2] 39893
nohup: ignoring input and appending output to 'nohup.out'

[tzell]

Anyone might have another idea?

[tzell]

Turns out the problem was with the HDMI CABLE (5 meters long)

I have no idea why, but that particular cable kept waking the screens up from DPMS mode.

Problem is solved when using other HDMI cables (shorter ones).
Perhaps the cable length has something to do with it?

That is very strange, the problematic cable seems to work fine under a windows operating system.

So in conclusion, switching HDMI cables works as a workaround.