DisplayPort Link Failure after monitor sleep?

I just added a 3rd monitor to my Windows 7 64-bit computer. When the monitor goes to sleep, it won't wake up. The other two monitors wake up fine (connected via hdmi and DVI).

The new monitor I added (an Asus VS278Q-P) is connected via DisplayPort. My video card is an AMD Radeon HD 5830 card which has DVI, HDMI, and DisplayPort connections using Catalyst 15.7 driver version 15.20.1046

If I turn the monitor off and on then it will get a signal but when the monitor comes on, all windows on that monitor are moved to a different monitor and there is an error message displayed about a DisplayPort Link Failure:

enter image description here

Some forums suggest it's something to do with the DisplayPort handshake that goes on.

"By powering the monitor off/on, you are forcing the operating system and/or video card to reinitiate the DP handshake" (source: https://www.sapphireforum.com/showthread.php?32467-Displayport-monitor-does-not-wake-from-sleep)

I should note that my computer is set to never sleep while my monitors are set to sleep after X minutes. I've seen people say on forums that they believe when the computer is set to sleep then when the computer wakes it will send the DisplayPort handshake, but if the monitors sleep and the computer does not sleep then when the monitors wake up the video card will not send the DisplayPort handshake.

Any ideas on how to resolve this? The two workarounds I can think of are both less than ideal:

  1. Manually turn monitor on/off every time it goes to sleep and re-arrange windows
  2. Set monitors to never sleep.

UPDATE

I thought the answer was to simply disable DDC/CI as I answered below, but I was a little to quick to assume that was the answer. If the monitor goes to sleep then I can quickly wake it up and everything is fine but if it sleeps longer than say one minute then it won't wake up. Power cycling the monitor gives the DisplayPort Link Failure error mentioned above.


Solution 1:

I actually think I found an answer to this. That was surprisingly fast considering the number of dead ends I saw on forums. User nixda on a different question, Turning DisplayPort monitor off disables monitor completely, says:

Disable the "DisplayData Channel Command Interface" (DDC/CI) in your monitor settings.

For my Asus LED monitor this meant going to the monitors settings menu (using the physical button on the monitor) -> System Settings -> OSD Setup -> DDC/CI and turning it off.

Seems to be working so far will update if that changes.

EDIT

I thought the above solved it because when the monitor went to sleep (power light changed from blue to orange) I could quickly wake it up without issue. However if the monitor stayed sleeping longer (say 1 minute+) then it would not wake up. I now don't think the above step is necessary.

I found a post on a dell forum which led me to the solution:

This is a video card, video card driver, or operating system power management issue. The monitor DP (DisplayPort) is passive. It simply waits for the signal from the video card to awake. By powering the monitor off/on, you are forcing the operating system and/or video card to reinitiate the DP handshake. The Radeon HD 7790 has eight power management states through its PowerTune technology. My guess is somewhere in that software is the ability to tell it to adjust what the card is doing as far as power management. (source: http://en.community.dell.com/support-forums/desktop/f/3515/t/19520244 )

Elsewhere in that thread is mention of the TriXX Tweak Utility (direct link) from Sapphire Technology (the maker of my video card). This has a setting Disable ULPS (ULPS = Ultra Low Power State). I installed that utility and checked the Disable ULPS setting and sure enough when my monitor went to sleep I could now wake it back up. Success! Well sort of, when I restarted my computer the problem returned and opening the TriXX Utility I could see that the Disable ULPS checkbox was unchecked. As far as I can tell the TriXX utility has no way to make that setting stick between reboots (I might be wrong about this).

Digging further I found several forums discussing disabling ULPS (mostly in the context of working out crossfire issues, e.g.: How to disable ULPS). In those forums the procedure they recommend is searching the entire registry for EnableUlps and changing the value of each occurrence from 1 to 0 (in fact you will see several minor variations on the exact procedure but this is the gist of it).

For me in particular I needed to change the following keys: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\amdkmdag -> EnableUlps HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\amdkmdag -> EnableUlps HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\services\amdkmdag -> EnableUlps

(The EnableUlps setting appeared elsewhere but was already set to 0. Also there's another setting EnableUlps_NA which I did not touch)

If you're like me you'll be reluctant to change the registry to fix a problem that seems like it should have a readily available solution. But as you dig around I think you'll find that ready solutions don't currently exist (and it beats modifying the DisplayPort cable with electrical tape which is an oft suggested solution)

I made the registry tweaks and now it seems to be working properly even after restarting.

Note: people say you will need to redo the registry tweaks every time you update your video drivers.

Solution 2:

thanks for this thread - it has helped me debug my own problem.

I have come across some "misc Chinese industrial" monitor with DP input, that behaved in this way - and, based on available information, it's the monitor's fault.

In spite of the original intentions behind DP (a single electric hop from the south bridge to the display matrix driver), the monitor does contain an "AD board", giving it the ability to select among multiple video inputs (VGA, HDMI, DP). It's the "AD board" inside the monitor that drives the HPD signal - and it's not a plain pullup.

Based on the limited information available, the HPD is normally just a static level-based (active high) indication, from the video sink to the video source (from monitor to PC), that a video sink is plugged in, in a particular Display Port socket on the video source. Plus, allegedly it can be used by the monitor to "hookflash" the HPD signal = to send an interrupt pulse to the PC, which is the only way the monitor has to ask the PC for an "AUX bus transaction" (the AUX protocol is apparently request-response, master-slave, where the PC is the master). Based on my practical experience, I doubt how much use this "interrupt" capability is - it's possibly not essential.

In my case, after cold power-up (of the display), the PC does seem to wake up the display just fine, but when the PC enters S3 sleep (suspend to RAM), something happens in the display, and it doesn't wake up after the PC wakes up. More precisely, after waking up from S3, the PC does not detect a display attached to the DP socket. Why: apparently because the display fails to pull the HPD wire high. Interestingly, if you power-cycle the monitor while the PC is asleep, the display does wake up after the PC wakes up from S3 sleep. Also, the problem doesn't occur if the PC is configured just to turn off the display to save power (or screen backlight) but the CPU and OS stay up and running. So it could be something like a "good night" that the PC tells the monitor via AUX or DP payload during the "PC going to S3 sleep" sequence, and the monitor responds by going to sleep for good.

Interestingly, in my culprit monitor, the HPD signal is inactive after a monitor power-cycle, looking pretty much identical to what it is after the host PC falling S3 asleep. But somehow the PC does wake the diplay after a cold power-up and the HPD goes high. After a wakeup from S3 (not preceded by a monitor power-cycle) the HPD remains low. As if some additional handshaking was going on - not sure if in the payload, the AUX channel or on the HPD signal itself (haven't checked with a 'scope). Either way, I suspect some firmware bug in the monitor's AD board controller chip.

I've noticed the ULPS keyword in this debate and elsewhere, typically in the context of AMD graphics. My graphics adaptor is an Intel IGP (3rd gen = Ivy Bridge in this case). A rare note or two about ULPS in the context of Intel graphics can be found in some open hardware documentation, intended for open-source driver writers. Not much use in a Windows environment. Also, intel's IGP driver config utilities used to be more decent than they are now - especially the IEGD was an excellent tweakable driver package, but now we have to live with what's available. I've tried prolonging the DelayedDetectionForDP in the registry, which had no effect. And, in the config util and VGA driver properties there's no way to "force the port up". (Nor is there an option to disable dependence on DDC, but the DDC/EDID availability seems to be a separate problem, different from the HPD input or VGA load impedance measurement.)

Ultimately, I resorted to soldering on the AD board (inside the monitor). Long story short, fortunately there was a neat PCB trace going from pin 18 at the back of the DP socket. I found a 10-Ohm resistor in series with the gate output driving the HPD signal - so I removed that. And, I attached a 1k pull-up to a nearby capacitor (MLCC) blocking the +3.3V standby voltage rail. Now the HPD line is always pulled high, as long as the display is plugged into the wall. Apparently the theoretical possibility of monitor-to-PC interrupts is not a requirement for the monitor to function properly. I'm attaching a photo merely for illustration.photo of an AD board hack, pulling up the HPD signal to +3.3Vstb No I'm not gonna mention the monitor or AD board makers. A word of caution: you cannot just short the HPD trace to +3.3V and be done with it - in my case, the gate output (HPD line driver) measured as 30 Ohms against GND when low. A short to +3.3V would blow something (you'd be lucky to fry just the gate output). This kind of a hack takes some precautions and "know how" that belong to electronics.stackexchange.com. Not to mention some basic tools: a soldering pen, a multimeter with sharp probes, and a strong magnifying glass. (And something to cleanly desolder the poppy seed sized resistor... some would use a thin stream of hot air, I may prefer a vintage soldering gun with a custom double-tipped loop made of AWG24 wire.)

Solution 3:

Was going to piggy-back on the answer by User, but don't have enough reputation. The combination that worked for me was:

  • Disable the "DisplayData Channel Command Interface" (DDC/CI) in your monitor settings.
  • DP Hot Plug Detection - Always Active in your monitor settings.

The system:

  • Gigabyte GTX 970
  • HP z27q 5K Display (powered by two(!) DP cables).

The two DP ports that worked (out of 3) are those furthest away from the HDMI port.

Now I FINALLY get a picture after a wake up and on a cold boot. Now that took a while...