# Resetting displayport/hdmi/dvi after suspend?

## eccerr0r

Apparently after a DPMS powerdown of my monitors, my (mini)Displayport connected monitor does not come back up.  It remains in suspend indefinitely.  Can't get it to come back up.  Computer appears to acknowledge the monitor is there as I can move things to the invisible desktop.  My other monitor comes up just fine, but it's hooked up to the HDMI port using passthrough works perfectly fine coming back up out of suspend.

Only thing I found that seems to get the monitor out of suspend is rebooting the computer.

Well, that's not really helpful.

I also found out by doing a physical unplug and replug of the displayport seems to work too, but the whole hotplug thing (another monitor event gets through and sets up a "new" monitor), while glad it works, gets annoying.

Any idea how to get the monitors to come back up out of suspend?

Note: The displayport monitor is actually a minidp to VGA adapter, and connected to a VGA display.  Again unplugging and replugging the adapter seems to restore operation without rebooting...

Disabling DPMS power saving ... may be an unpleasant workaround...

----------

## Anon-E-moose

Go to /sys/class/drm/card<monitor that's off> 

what shows with "cat dpms enabled status"

----------

## eccerr0r

Happened again...

```
/sys/class/drm/card1-DP-2 $ cat dpms enabled status 

On

enabled

connected

```

Bad.  It thinks everything is hunky dory.  Might be the miniDP-VGA adapter that's confused but should there be a way to reset it...possibly turning it off by cutting power off through the displayport?  Something is allowing the reset to happen by doing ctrl-alt-del reboot, just that trying to come out of suspend doesn't work...

I don't have any real displayport monitors or displayport-dvi/hdmi adapters so I can't test whether or not it's just the VGA adapter ...

(Just to be complete, minidp is the same as regular displayport except smaller?)

----------

## Anon-E-moose

Is this running in X or just at console?

If X, does xrandr turn it off and back on?

I know that status is set rw (root) but don't know if setting connected/disconnected will do anything.

----------

## eccerr0r

This is in X.

Switching VT's to console and then back to X does not restore operation (it's also sleeping in console mode). 

I just rebooted because the machine's console is dysfunctional after the event(the X unlock screen and the primary text mode console is on the sleeping display, secondary display remains blank but enabled after DPMS resume and I can move the mouse pointer there)...

----------

## Anon-E-moose

sounds like you won't be able to use dpms on that monitor, could be the monitor doesn't handle dpms well, the dp/vga adapter not passing all signals, etc.

----------

## eccerr0r

Alas I can re-enable it by rebooting (switch to console VT, control-alt-delete), so there must be a workaround!

----------

## Anon-E-moose

What gpu connectors do you have available? (dp, anything else)

It does understand when you pull the cable, so I would imagine the dp adapter isn't passing some signal.

A straight dp to vga cable might work, emphasis on "might"

----------

## eccerr0r

Displayport as far as I know does not have analog signals on it - must be translated with an active device.

This particular GPU is an ATI R7 250 and it has nothing but mini displayport connectors on it.  I tried xrandr and it says the display is enabled...

I'm also getting an impression that different levels of DPMS sleep is affecting the system differently, or at least something is not consistent.  I've seen it sleep and come back just fine -- just not all of the time.

---

Spotted this in my dmesg:

```
[ 8644.343705] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed

[ 8644.343734] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed

[ 8644.591328] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed

[ 8644.591357] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
```

----------

## Ralphred

 *eccerr0r wrote:*   

> I tried xrandr and it says the display is enabled...

 

How does it behave if you manually "disable"/enable it with xrandr?

----------

## Anon-E-moose

eccerr0r, which version of X are you runninng?

----------

## eccerr0r

x11-base/xorg-server-21.1.3-r1 -- and what exactly are the commands to "enable"/"disable" outputs?

Tried offing an output and have it autoconfig but it didn't wake up the monitor in any sense.

----------

## Anon-E-moose

The only other things  that might work (software wise) is either xset or vbetool.

I know xset has flag for dpms, including forcing *be aware that xset doesn't work by monitor but by display (all monitors)

Not sure about vbetool, but I've seen reference to it before.

other than this the only things I can think of is learn to love pulling the cable  :Laughing:  or 

set a screensaver w/blanking (should drop power usage a little, but not sure how much)

----------

## eccerr0r

Until I get all OLED displays, blanking does not make any dent in power consumption -- need to turn off the backlight to save energy.

Yeah I need to find a solution that controls ports individually.

I do wonder how many cycles the connectors will last if I keep pulling them, they will eventually wear out :(  And I only have one minidp plug total, if it wears out, the video card becomes useless.  It's too bad that I can't disconnect the VGA side, that does not help.

----------

## eccerr0r

I found another workaround!

Seems if I hibernate and resume, the sleeping monitor comes back up!

Suspending isn't sufficient.  Has to be a full hibernate.

Unfortunately this too is annoying as it has to dump a lot of RAM to disk, so burn SSD write cycles or a minidp plug/unplug cycle...

----------

## Ralphred

 *eccerr0r wrote:*   

> x11-base/xorg-server-21.1.3-r1 -- and what exactly are the commands to "enable"/"disable" outputs?

 

xrandr --delmonitor <name> removes it from xrandr entirely, as if you'd booted X without it attached.

Adding a monitor is more complex but still scriptable.

```
xrandr --setmonitor +<port name> <pixel width>/<mm width>x<pixel height>/<mm height>+<x offset>+<y offset> <port name>
```

If the video mode is missing after the remove you'll have to add it

```
xrandr --newmode "mymode" 148.50  1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

xrandr --addmode <port name> mymode
```

Then switch it back on

```
xrandr --output <port name> --mode mymode [--right/left-of <diff port name>]
```

From memory, you can pull all that info from xrandr when it's working, I don't remember hunting to find it when I was messing around with it.

----------

## eccerr0r

```
$ xrandr --listmonitors

Monitors: 2

 0: +DisplayPort-1 1280/337x1024/270+0+0  DisplayPort-1

 1: +HDMI1 1280/380x1024/300+1280+0  HDMI1

$ xrandr --delmonitor DisplayPort-1

X Error of failed request:  BadValue (integer parameter out of range for operation)

  Major opcode of failed request:  139 (RANDR)

  Minor opcode of failed request:  44 ()

  Value in failed request:  0x184

  Serial number of failed request:  62

  Current serial number in output stream:  63

```

Hmm....

----------

## Anon-E-moose

I believe delmonitor works with setmonitor (as they both trigger on name)

you can play around and see if setmonitor will allow you to use it on the existing output then delmonitor "should" work

----------

## eccerr0r

Allright... I now have a bunch of adapters so I can connect my mDP to DVI... and now to see what happens with this monitor...

---

Okay... so now confirmed, it's this mDP to VGA adapter that fails to come out of sleep mode until a system reset occurs.  A mDP to HDMI to DVI adapter chain works perfectly and the monitor comes out of suspend just fine...

----------

## eccerr0r

NOOO....

Looks like I can also get my mDP -> HDMI -> DVI connected monitor to also fail on sleep mode.  It likewise also can't seem to restore clocks and a reboot is needed to get the monitor to work again.  Only the on motherboard HDMI port reliably goes into DPMS sleep and comes back each time, unlike the mDP connectors on the ATI board...

----------

## Anon-E-moose

If you're using adapters, then they might not be passing all the signals needed for sleep/wake.

Only way to tell is use a cable with proper adapters on each end (still need to make sure all signals pass, but that's a question for vendor)

A lot of adapters only carry the signals needed for display, not all the "possible" functions of video card/monitor

----------

## eccerr0r

They are passing all the signals as the sleep/wake are coded in-band on the data streams.

This is clearly a video card driver/firmware issue, and once again the monitors do go to sleep, just do not come back out properly until the video card is rebooted.

----------

## Ralphred

 *eccerr0r wrote:*   

> This is clearly a video card driver/firmware issue

 

Sounds like it's time to start trawling through the docs at kernel.org, looking for anything acpi related?

----------

## eccerr0r

Don't think it's acpi related, it's probably some driver issue or perhaps it's making assumptions the displayport connectors are connected to displayport monitors - but I've seen some posts around the web that this appears to be problematic with real displayport monitors as well.

Not sure how many people here use DP monitors on ATI graphics cards yet, though it may be specific to my card... the ATI R7-250 IIRC...  I don't recall this issue on the V3900 DP connector however.  Might have to switch back to that and see if the same problem occurs though it's not consistent with the mDP-DVI-D connection.  It is consistently borked restoring the mDP-VGA connection however, but I can't plug in the same mDP-VGA adapter in the V3900 (was using a different DP-VGA adapter for that card.)

mDP = mini displayport

DP=displayport

DVI-D=Digital Video Interface-Digital

VGA=Analog Video Graphics Array connector

----------

## Ralphred

 *eccerr0r wrote:*   

> It is consistently borked restoring the mDP-VGA connection however

 

They are active are they not? Been a while since I worked on this stuff...

----------

## eccerr0r

it has to be active...no analog signals on mDP connectors...

Back to the original intent... it sure would be nice if I can reset these DP/mDP ports because they all magically come back to life if I control-alt-delete reset the machine, hence software bug versus hardware, IMHO.  Still could be firmware bug but definitely not hardware.

----------

## eccerr0r

hmm...looks like a half baked restore ... I've seen displays magically restore itself after blanking and conking out... ugh.  Flaky operation...

----------

