I found a software solution! https://github.com/kangyu-california/PersistentWindows

Completely automatic and just works.

(Assuming what you're looking for is preventing windows from being shuffled around when monitors turn off, or rather, putting them back. Can't speak for any other issues this EDID problem may be causing.)

There seems to be a few programs that do this, not sure which one's best. Here's another one I've seen people mentioning: https://github.com/hunkydoryrepair/MonitorKeeper

I was looking into this as well and to me this problem seems to be solveable without any signal proxying through MCU but also without 1) risking a short circuit due to simply shorting DP_PWR to HPD and 2) breaking interrupts.

Just one note regarding the DP_PWR wire: DP 1.0 never mentioned that this cable shall exist. This pin was always meant to only provide power to devices or adapters. There was no change in 1.1 but just a clarification to make it absolutely clear. Also, as Wikipedia claims, 1.0 was never implemented but the first products on market already were 1.1. Thus, no need to worry about this.

Anyway, here's my solution:As others already tried out, simply shorting DP_PWR to HPD on the GPU side works. However, this breaks interrupts, possibly causes short circuits when HPD on the sink side is still present. So this is probably the reason why various people came up with the idea of simulation the HPD signal. I think this can be done easier.

Facts from the DP 1.2 specification:

- section 3.2
  - DP_PWR = 3.3 V (min. 3.0 V, max 3.6 V)
  - DP cables must have no wire for DP_PWR

- section 3.3
  - HPD termination for both upstream/downstream device: >= 100k ohms pull-down
  - Hot plug detection threshold = 2.0 V lower limit
  - Hot unplug detection threshold 0.8 V upper limit

In the "worst" case scenario, both sides are plugged in and are terminated with 100k ohms pull-down to GND. That means, we have a 50k pull to GND when HPD is not driven. The unplug limit of 0.8 V is the upper limit, so it's possible that unplug already triggers at 1.99 V for specific devices. Thus, let's assume 2.0 V as the lower limit.

In order to keep HPD at at least 2.3 V, there needs to be a pull up of R=3.3/2.3 * 50 - 50 = 20k ohms.

I didn't have a 20k ohms resistor at hand, so I chose a 10k resistor and placed it between DP_PWR and HPD on the GPU side of the cable. I only tested for a short time with a few times unplugging and replugging but it worked!

A 20k (or 10k) resistor will not prevent interrupts and won't cause any short circuits (0.18 mA max. at 3.6V and 20k).

I'm also wondering if there is any update?  I'm looking to build/purchase a simple adapter to keep the PC thinking the monitor is always connected.

Any luck on the test?

Is this why my Debian machine is giving me a hard time?  any monitor/port/cable combination works on my HP SFF machine but if I have both monitors hooked up, I'm in an endless loop of the monitors going in and out of sleep mode, and the computer moving the windows back and forth between the monitors as they wake up and go to sleep.  It's almost like as one wakes up, it triggers the other one to go to sleep and vice versa..  The strange thing is that it's fine UNTIL I log in..  When logged out, it is stable with both screens, but as soon as  I log in, it freaks out.  SO frustrating!

That is a possible cause. I HATE this feature and I wouldn't shed a single tear if this "feature" goes away today.

Hope you have not given up on this, or for someone else to take the torch.

It's insane how it's *still* a problem and will likely always be a problem for DP displays because of Vesa.
Even on my current single display setup, using an AOC 32:9 monitor, I have crashes/freezes on Linux caused by the display dying when switching inputs (or turning on side-by-side inputs mode).
It's very, very fun to have to reopen programs just because you changed an input. I've even seen it kill the amdgpu driver when input changes like switch variable refresh rate on or off and overdrive mode occur.

This is gonna be a long one, but I want to try and stir some life into this issue, so I'm gonna dump some of my research on the topic.

At least two products have been made to address it, both are unreasonable:
- DPHPDMA: https://paleblew.blogspot.com/p/engdphpdma.html
-- Unreasonable because the author appears to have stopped selling it, I don't think they made their process open source either, which sucks. Also requires an USB cable for powering, although that's not that bad.

- DisplayPort Hotplug Maintainer: https://www.networktechinc.com/displayport-hotplug-maintainer.html
-- Unreasonable because it is pretty much the only product on the market, is extremely overpriced (seriously, 250$ for something so stupidly simple, add international shipping to that and it becomes a joke, even resellers still charge premium) and they have a patent pending for it, which pretty much kills third parties from releasing clones of it (and there don't seem to be any in China interested in releasing such a niche product either, who wouldn't care about patents).

If someone has used either of the above products, please reply with your experience, so we can at least know if they actually work or not. Wasting so much money on something you don't know for sure will work is pretty risky.
At least one commenter in this Reddit post said they had little problems with, aside from some reset weirdness: https://old.reddit.com/r/Monitors/comments/t0xyce/has_anyone_tried_the_displayport_hotplug/
Someone in the replies to that comment even claims to have been working on their own version of it, though they haven't elaborated further and also weren't 100% on open sourcing it either.

I have also seem some actively powered DP repeaters, if someone has used them before, do they work to trick computers into thinking the display is still on? They also require a micro usb connection, so there's at least a chance they might not properly support HPD which is entirely in our interests. One obvious advantage to them is that there are plenty on the market and they are much, much cheaper than NTI's adapter.

Also, you mentioned you were unable to access certain documentations due to requiring royalties. Would something like this work for you? https://glenwing.github.io/docs/DP-1.2.pdf

Also @ziddey has your solution worked in the long run? Any fried cables/monitors/GPUs/other components? Do they "just work" or are there any quirks?

Lastly, if we can document which monitor models and brands offer the option to kill this feature, it'd be very nice.
I have come across a few posts that claim Asus monitors let you disable this by turning off "deep sleep" or ddc/ci, but nothing concrete. Maybe Dell too.

Sorry for the late reply, I was very busy. You're right, they're charging a crazy amount of money for something that *could* be just a cheap microcontroller and a resistor. That is unacceptable. I will try various solutions I come up with using my computer or a sacrificial PC, and report back.

Yeah, it just works. It's been over a year and a half, and I pretty much forgot the issue ever existed.

I ended up purchasing a https://www.networktechinc.com/displayport-hotplug-maintainer.html and I can confirm it actually does what it says it does and stops windows from detecting that the monitor is disconnected when I turn the monitor off (I don't use linux so can't confirm if it works there).

That being said I did have a little bit of weirdness when I used it for the first time and the first time and it didn't pass anything through but it worked perfectly after I unplugged and replugged it.

Were you ever able to find a solution to this damn hotplug issue? The only solution I was able to find was this one https://www.networktechinc.com/displayport-hotplug-maintainer.html

Sorry for the late reply, currently there are only two commercially available (or previously available) solutions, one is the plug you mentioned and the second is a Japanese signal interceptor dongle, which seems to have gone out of production. I will try to come up with a solution.

Edit: Since I was unable to reply to your comment, I will answer your question here; DP 1.4 and DP 1.2's HPD protocol is identical according to anonymous sources, so I figured that wouldn't be necessary.

I ended up purchasing the https://www.networktechinc.com/displayport-hotplug-maintainer.html device and to my relief and surprise it actually does what it says it does and now if I turn off my DP monitor windows does not think I have removed it.

That being said I am still hopeful that you are able to find a solution that will work as I don't want to have to buy multiple of that device if I need more in the future. In your last project log post you mentioned that the specification sheets are locked behind a paywall, which sheets are you talking about? if the cost is not too great and you think those sheets will help you I may be able to pay for them?

Have you tried this ? 

https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU

"CRU creates software EDID overrides in the registry and does not modify the hardware."

And if its not 100 working then maybe ToastyX can solve the issue in software ?

@blockberd bridge hpd and dp_pwr on one end of the cable and plug into the gpu. bend the hpd pin on the other end back and forth until it breaks off if you want to be safe and not feed gpu 3.3v into the monitor's hpd 3.3v (I didn't bother but it's probably a good idea).

https://i.imgur.com/6l9pKE7.jpeg

While this might work, this might break compatibility with other monitors using this elusive DP v1.4 specification. Hence, I will try to come up with a solution that both satisfies the trick and the requirements of the monitor.

Are there any (final?) updates on this? With more and more GPUs only having 1 HDMI and a ton of DP ports, it gets more and more of a problem and a concern for me.

> I discovered that by simply supplying 3.3V to the HPD pin, the graphics card thinks it is still connected to the monitor, as long as there WAS valid EDID information supplied before it shut off. Maybe it's time to pursue this road?

This was the trick I did back in the day with a DVI monitor that had hotplug issues. The same works for DP and it's far easier to do. HPD and DP_PWR are right next to each other, closest to the angled corner. Strip a little spare stranded wire to steal a single strand. Shove it in one of the pinholes all the way and bend the wire to mark the depth/length of wire needed. Pull wire and form a U at the bend (about the width of two pinholes). Trim wire and shove in HPD and DP_PWR pinholes.

With DVI, I had the monitor upside down while I tried to get the wire in the right pinholes being careful to clear other holes since the hpd/3.3v pins weren't adjacent. Then had to carefully plug it in before flipping it back around. Worked great until I forgot about the jumper and unplugged it to do some cable management.

Finished product: https://i.imgur.com/6l9pKE7.jpeg

Having the jumped HPD on the monitor side would be ideal, but I haven't tested to see if DP_PWR is constant even in standby or if it gets supplied quickly enough on wake. If it doesn't work, jumping HPD on the GPU side is more guaranteed. However, the GPU may not release the monitor when unplugging / plugging a different monitor, so the cable may need to be replugged on the GPU side as well.

Confirmed using a samsung ud970 + intel uhd630 alongside 2 other monitors with both DPMS and S3 standby. Have it jumped on the gpu side.

If anyone wants to attempt this, do take note of the warning here: https://en.wikipedia.org/wiki/DisplayPort#DP_PWR_(pin_20)

There shouldn't be any harm jumping the monitor side, but doing gpu side will join the gpu's 3.3v to the monitor's hpd 3.3v. No issues personally, but the danger is there.

edit: Just tested reversing the cable so hpd is jumped using the monitor's 3.3v. Unfortunately it doesn't supply 3.3v in time. Swapped back to using the gpu's 3.3v and we're back in business. If you're concerned about introducing the gpu's 3.3v to the monitor's hpd 3.3v, you could then break off the hpd pin on the other plug. Just make sure to plug the cable into the monitor before the gpu to avoid any issues.

Godspeed on finding a solution to this.

 I have 3 monitors and will change the input on one of them to work on a different system sometimes, while still wanting to view and use the other two monitors on the first system (I use Barrier to switch the keyboard and mouse between systems).

At random times, the hotplug detection will kick off for the monitor with the changed input, the resolution of the changed display gets changed, the windows rearrange, and Barrier gets confused, so I actually have to stop what I’m doing and change the input back to the first PC, let it fix the resolution, window positions, re-enable gsync, then swap back to the other input so I can continue working. It’s infuriating.

solved with 27.20.100.9316

Intel® Graphics - Windows® 10 DCH Drivers

Does not seem to work on NVIDIA or AMD devices.

This doesn't seem to be the case for me - I've installed and read all the release notes and can't see any mention of a fix? Can you share the fix if it's been fixed?

Is this project still alive? I look forward for any kind of solution that will prevent DP hot-plug shenanigans.

Yes, just waiting on some parts to arrive so I can experiment with them.

Hi Torbjorn! What's up with this project as of today? Keeping my fingers crossed still. TIA!

accidently found a somewhat compromise solution. main monitor is DP 1.4 HDR 1440p 144hz overclockable to 170hz, overclocked to 155hz the rest are HDMI or display port, I needed an easy way to divide my portrait monitors in half so downloaded a few bits software trials and freeware. 

I found that the free software Actual Multiple Monitors does what I needed allowing me to snap windows to the top and bottom of the portrait monitors but it also remembers where my windows were before a hotplug event so everything moves back to my main monitor when it is powered on (though adds a few seconds to do this when there are lots of windows open). compromise is that windows will still move over to monitor 2 so any windows used when my main monitor is disabled remember their new monitor location.

this works for my use case when my main monitor is the only hotplug monitor and will always be on when I'm at my PC but may not be for you if you need to regularly sleep multiple hotplug monitors. the hotplug event does resize windows on the portrait displays but these are reverted back to the way I set them when the main monitor is plugged back in.

Have been trying to find a solution for this for some days now but seems like there is no option if you are using HDMI 2.1 with res 3840x2160@120hz with 10 bit color depth and RGB. Please keep us posted if you have a solution.

Hello, any news on the project?

A simple hardware device is available from the following link: http://monitordetectkiller.com/.  It is a homemade product that I suspect has put the person thru school. 
What would be great would be a commercially made product that would be just a male/female HDMI connectors and be more robust than the fellow at the above website.

I was looking for a solution for so long. I just wish for this to work.

DisplayPort hot plug detect is an absolute nightmare on multi-display setups, with no end in sight.  Neither GPU vendor or Microsoft is willing to do what it takes to resolve the issue for fear of not being fully compliant with the DP specification.  So, with that in mind, it's great to see some recent inertia in search of a solution.

I've been fixing to hack a DP+USB combo cable to keep the hot plug detect (HPD) pin high, drawing the required 3.3v from the USB's 5v source, but time just isn't on my side lately.  With that in mind, I do remember happening across a pre-built solution that probably works the same way, but it was at a premium - and I lost the link.

Hope you're having more success.