EDIDone - Disable DisplayPort Hotplug

Tired of computers rearranging your screen when monitors turn off? I am.

Similar projects worth following
DisplayPort specification has a requirement for hotplug detection and this causes a problem when the operating system handles it un-gracefully. Tired of waiting for the companies to stop ping-ponging the issue and claiming some other party is responsible for the fix, I aim to fix this issue.

Per the DisplayPort specification set by VESA, all monitors that bear the DisplayPort logo (or uses its specification) are required to support EDID and DDC/CI. This causes a problem when the standard specification also includes a very annoying feature called hotplug detection and the operating system handles it un-gracefully, causing problems such as the resolution of the screen changing, 3D applications crashing, screen not showing up on remote access software, PC failing to boot due to the lack of monitors, or all the desktop windows and icons being shifted to the next available monitor which may or may not exist on the system.

Some people have resorted to getting a dummy display device (which plugs into the port and makes the GPU think there is a monitor attached to it), but in my case, this didn't even work since the GPU still rearranged the screens and Windows 10 reacted by disabling the "Copy Screen" option, which renders the solution useless because you have to go to the option and turn this option back on when you turn the monitor on again.

Moreover, most pre-made solutions (EDID copiers, dummy plugs, DP-to-HDMI converters) do not support any refresh rate above 75Hz, which causes glitches and issues when you want to use 120Hz or 144Hz refresh rate on your new monitor. How do I know? I tried 4 different devices from different manufacturers, all of which showed glitches when set to run at 144Hz. Plus, dummy plugs are useless when you want to make your monitor appear not-turned-off.

Some monitors provide "hybrid sleep" mode which lets you put the monitor to sleep instead of turning off, leaving the hotplug detection happy while you sleep knowing that the service life of the backlight lamp is not going to be wasted when you are not using it, but this feature is missing on many many monitors. To combat this issue, some users have used the "black screen" trick to simulate the monitor turning off, but this still leaves the backlight of the display on, reducing its lifespan and still wastes electricity.

NVIDIA provides kinda-sorta fix on Quadro cards by loading the EDID information from a file, however they're ridiculously expensive and not at all fit for most people (like buying a new car to fix a flat tire is stupid). Intel and AMD refuses to let users disable this annoying feature. Microsoft still does not want to implement a way to disable this feature (even with users understanding that this may cause problems). While on Windows 7 you could do a registry patch to kill this feature, on Windows 10 the supposed fix does not work anymore.

Left with no other options and tired of companies shifting the responsibility to one another over and over, I decided to make something that kills this feature once and for all, and without having to buy the device from some company far, far away from you with no guarantee on whether or not it supports the display refresh rate or resolution you want.

Addendum: I discovered that the VB Audio VoiceMeeter will lock up and crash if the audio device is removed, which includes the monitor!
More reason to kill this annoying feature!

  • The magic is apparently...

    Torbjörn Lindholm04/28/2021 at 05:57 0 comments

    ...Just a regular EEPROM? This dongle is detected as "DVI" (same as the HDMI monitor I have).

    I also discovered that most if not all DP-to-HDMI plugs are also detected as "DVI". I tested 3, and all three are detected as DVI. Even my hacked dongle does that.

    Below are the images of the dongle, with the black solder resist scraped off for visibility.

    (Image flipped to make reverse-engineering easier)

    According to my multimeter, magenta (not pink) is connected to the black pin (middle pin of the three-in-a-row side of the chip).

    Pin 1: Main Link Lane 0 + (Shorted to ground, magenta)

    Pin 6: Main Link Lane 1 - (Shorted to ground)

    Pin 12: Main Link Lane 3 - (Shorted to ground)

    Pin 13: CFG1 (yellow)

    Pin 14: CFG2 (blue)

    Pin 17: AUX - (green)

    Pin 18: Hotplug Detect (red)

    Pin 19: Return (cyan)

    This is a problem because if the card is thinking this is a DVI or HDMI plug, that also means it cannot be used to manipulate DisplayPort. This is probably a dead end. Very disappointing.

    However... Remember the weird behavior with the logic analyzer? 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?

  • Could this work?

    Torbjörn Lindholm04/13/2021 at 06:35 0 comments

    I recovered the project file from my drive and made some changes to it.

    The question is, which wire goes where? I won't know for sure until the dummy plug arrives, but the AUX line is definitely used for this purpose. I even created an EDID data for this purpose (that contains a special string so I know for sure it is the right one)
    00 FF FF FF FF FF FF 00 20 24 37 13 39 05 00 00 17 1F 01 04 A5 34 1E 78 3B DC F1 A6 55 51 9D 26 0E 50 54 AF CF 00 81 C0 81 40 81 80 81 00 95 00 A9 40 B3 00 A9 C0 FE 5B 80 A0 70 38 35 40 30 20 35 00 09 25 21 00 00 1E FB 7E 80 88 70 38 12 40 18 20 35 00 09 25 21 00 00 1E 00 00 00 FD 00 64 90 B4 B4 21 01 0A 20 20 20 20 20 20 00 00 00 FC 00 48 41 43 4B 41 44 41 59 0A 20 20 20 20 01 4C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

     Here's hoping that the plug doesn't get stuck in the shipping process because I want this to be solved as soon as possible.

    Current plan:

    1. Acquire a DP dummy plug
    2. Take it apart
    3. Copy its EDID supplicant circuit
    4. Write something to extract info from the registry (if desired, Linux users will have this easy)
    5. Make sure the chip can be reprogrammed
    6. Open-source the entire thing

    Update: Attaching the EEPROM directly to the AUX line does not work. I'd be pretty shocked if I find out that the plug, which costs $4, is just a DisplayPort-to-HDMI plug permanently wired to a regular HDMI dummy plug. Hoo boy, if that's the case I'll have a gosh-darned field month reverse-engineering the thing... Let me check if it's possible to acquire the chips used in those dongles just in case.

    So far the solution seems to be:

    What will fit into the "Some Magical Component" remains to be seen...

    But I did get a partial success:

    I'm just hoping that this is NOT how those dummy display plugs work, else I'm screwed.

    But for now, [Telstra Music-on-Hold - Whistling]

  • Experiment 1

    Torbjörn Lindholm04/12/2021 at 18:45 0 comments

    After hacking up a DisplayPort cable to bits and wiring up headers, I discovered that in most cases the EDID stream is not used (or I suck at triggering it)

    I did discover that whenever the display is on, the HPD pin is at 3.3V. 

    Here's the logic analyzer screenshot (if you can call this "logic")

    Edit: Looks like this cable only has CONFIG wires broken out. I need to investigate further.
    Edit 2: Well, no dice. Still no stream.

    I'm tapping into these pins:

    So far, I only saw the Hot Plug pin going high and low when it's switched on and off, and I was unable to capture anything on Pin 15 and 17.

    The wiring looks like this (Basically everything is a passthrough, and I'm tapping off of those 4 wires, and there are 1.5K resistors in series so I don't accidentally fry the card should the probe touch the ground and the pin at the same time)

    One interesting observation is that if I connect the logic analyzer (a cheap Saleae USB logic analyzer clone), the computer thinks there's still a display connected, even if the cable is disconnected. So if all fails, I could simply tap off of unused Pin 20 for 3.3V, insert a resistor between that and Pin 18, and pass everything through...
    (Also sorry for all the little updates flooding the feed, I forgot to uncheck the little checkbox that does the stuff)

  • Cursory research

    Torbjörn Lindholm04/12/2021 at 11:03 0 comments

    We're interested in those three (or 5) pins highlighted: GND, DP_PWR, and Hot Plug. (AUX CH+ and CH- is for DDC, and we want that for the EDID)

    We could just forget about the DDC EDID, but this may cause some problems if the host device attempts to read the EDID when the display is turned off or the Hot Plug pin is used to initiate a specific function on AUX pins. Some devices also use DDC to control the parameters of the display, which means it gets very very tedious to manage all of that.

    I think there are few options on this one:

    1. Completely ignore the DDC channel, only intercept Hot Plug signal (breaks USB-over-DP and possibly more features)
    2. Intercept both HPD and AUX pins, force the computer to think there's a display attached (easiest, but obviously breaks some features unless other data streams are passed through)
    3. Attempt to intercept only EDID and HPD, let the source and sink device data through (hardest)

    Come to think of it, I might be (50% sure I am) making a mountain out of a molehill; Probably most computer monitors only use the DDC channel exclusively for EDID (so the OS remembers the monitor) and HPD pin, and doesn't utilize other functions, especially on the lower-end, consumer devices. Moreover, VESA specifications only say (paraphrasing) "AUX lines also can carry other data, such as USB" but doesn't elaborate further, which might signify that this specific function is not used. Now all I have to do is to find the way DP dummy plugs work (there's literally zero documentation on this, I've ordered one and I'm taking it to bits once it arrives), and combine it with a regular cable. If I make the trace as short as possible, I might be able to get away with just using regular "breakout module" type traces, instead of the impedance-matched circuit (I'll still need to make each wire the same length if I were to use the circuit board, but if I make the board a "parasite" I might be able to get away without it)

    This project ( might come in handy also because in this case, it worked just fine (albeit it's HDMI, not DisplayPort)

  • Plans for the future

    Torbjörn Lindholm04/12/2021 at 10:13 0 comments

    First of all, I've confirmed that the hotplug protocol for both DP 1.2 and 1.4 is identical, as well as the EDID (thanks, backward compatibility!)

    One thing I'm currently unsure about is

    1) How not to degrade DP 1.4 signal so 144Hz signal is not corrupted upstream

    2) How to continuously provide EDID signal so the graphic card doesn't go crazy when the monitor is turned off (nobody knows how well the hardware handles having nothing inputted when it should)

    So here's a plan on the research aspect: (feel free to provide information through the chat feature)

    • Figure out a way to capture the EDID data stream, save it, and play it back
      • Or program a custom EDID data and play that back instead (could be used to disable speakers if desired)
      • Since it's I2C data (I2C EEPROM), this should be not insanely hard
    • Make the trace so it doesn't corrupt the DP v1.4 (1920*1080 144Hz or 4K 60Hz) stream
    • Or modify a cable so it can be used as a way to intercept the signal

  • Hey everyone

    Torbjörn Lindholm03/29/2021 at 08:38 0 comments

    Hello everyone, I hope you're all safe and sound, free of "the thing that shall not be named" or "the beer".

    It's been a long time since this project has been updated (never, really).

    I'm still yet to find the solution for emulating the hotplug signals because... The specification sheets are locked behind the paywall and I'm just a lowly engineering student, struggling to graduate and under stress. And for this, I apologize. I'm sorry.

    However, this project is not shelved or canceled. This thing still annoys me greatly and this stupid thing needs fixing.

    But in order to do so, I need some help. If anyone reading this knows about how DisplayPort hotplug works (or knows a guy who knows about this), please contact me through Hackaday chat.

    Again, I'm sorry this isn't the update you were looking for, but I am pretty much stuck now. Thank you all for the interest, and I hope to see you again soon.

View all 6 project logs

Enjoy this project?



Limboman wrote 10/05/2021 at 01:25 point

Were you ever able to find a solution to this damn hotplug issue? The only solution I was able to find was this one

  Are you sure? yes | no

Rick wrote 09/16/2021 at 12:04 point

Have you tried this ?

"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 ?

  Are you sure? yes | no

ziddey wrote 08/08/2021 at 08:36 point

@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).

  Are you sure? yes | no

blockberd wrote 08/06/2021 at 14:30 point

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.

  Are you sure? yes | no

ziddey wrote 08/04/2021 at 02:45 point

> 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:

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:

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.

  Are you sure? yes | no

T Weber wrote 05/04/2021 at 04:57 point

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.

  Are you sure? yes | no

Jaume wrote 03/23/2021 at 14:51 point

solved with

Intel® Graphics - Windows® 10 DCH Drivers

  Are you sure? yes | no

Torbjörn Lindholm wrote 04/12/2021 at 14:04 point

Does not seem to work on NVIDIA or AMD devices.

  Are you sure? yes | no

Kai wrote 04/12/2021 at 22:40 point

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?

  Are you sure? yes | no

grocal wrote 12/23/2020 at 10:30 point

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

  Are you sure? yes | no

Torbjörn Lindholm wrote 04/13/2021 at 06:36 point

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

  Are you sure? yes | no

grocal wrote 09/28/2022 at 09:31 point

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

  Are you sure? yes | no

dissidify wrote 11/22/2020 at 12:26 point

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.

  Are you sure? yes | no

dissidify wrote 11/22/2020 at 12:30 point

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.

  Are you sure? yes | no

bjorklund.robin wrote 11/10/2020 at 20:37 point

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.

  Are you sure? yes | no

Giovanni Di Grezia wrote 11/04/2020 at 23:25 point

Hello, any news on the project?

  Are you sure? yes | no

haxor.system wrote 06/12/2020 at 19:46 point

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

  Are you sure? yes | no

Simon Dainty wrote 06/07/2020 at 11:44 point

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.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates