Close
0%
0%

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!

  • A signal plan

    Torbjörn Lindholm02/19/2023 at 14:28 0 comments

    This will be a test setup made with some discarded graphics cards and extenders. We first let the signal through without interruption for 150ms to facilitate communication for the monitor and GPU, which tells the computer what it is and how it should interact with certain aspects of the hardware.

    Then, we wait until the signal stabilizes. The moment the HPD signal from the monitor goes down (which would be 3.3V > x > 2.7V), the device intercepts this signal and replaces it with its own 3.3V logic signal (with a 5mA current limit)

    When the signal comes back, it immediately hands it back to the monitor (this may change -- may require the AUX lines to be held high at the same time to suppress double communication)

    The planned HPD signal interception

  • Closer look at the "solution"

    Torbjörn Lindholm02/05/2023 at 13:54 1 comment

    Well, looks like I will either have to pony up close to 300 dollars in total in order to get this device, or I will have to make something that emulates what it does. Since I'm still broke, I will choose the latter option for now.

    So, let's begin by reading how it works. This comes from this site -- https://www.networktechinc.com/displayport-hotplug-maintainer.html

    It both says "maintaining" and "providing", meaning it can do both (duh). Moreover, it mentions that it also supports headless and passthrough modes, which means it probably doesn't even touch the display signal lines.

    Another product exists from Japan that deals with this issue, this time with UART control: https://paleblew.blogspot.com/p/engdphpdma.html

    We can also gather information from application notes from Intel and Analog Devices.

    We now know for sure that this is a 3.3V logic signal. What about the data? It doesn't look like it is transporting much:

    We now know that the HPD signal is default high, with interrupt and other one-way signaling done by pulling the line low.

    This almost confirms that, should the circuit be made to keep the line high BUT lets the signal (if any) through when it happens, this imaginary circuit will probably work to kill this "feature" until it's unplugged.

    And the way it works would be something like this:

    1. First, it lets the signal through without any modification when plugged in for at least 500ms, to ensure whatever transaction occurs between the display and the GPU will succeed
    2. After that time delay, it waits until the display has stopped giving the "HPD high" signal
    3. It then immediately intercepts the signal and replaces it with a fake one to continue the signal
    4. When a button is pressed or some other "stop tampering with the signal please" command is given, it hands the signal over from the fake HPD signal stream (if there's any, to begin with) to the actual signal from the display
    5. Well, that would be it!


    Also, I have a word about VESA; They put this awful text under EVERY page of the documentation as if they're going to sue a customer tired of their antics for copyright violation.

    Suck it, VESA. You made a faulty standard that you're not willing to fix, so I will do it. Don't get in my way because I am very frustrated, and I will not stop until you do something or I conquer your damned standard "feature".

  • Long-awaited "solution"

    Torbjörn Lindholm02/05/2023 at 06:32 0 comments

    Apparently, there is a product called "DisplayPort Hotplug Maintainer" made by NTI, and used by KVM switch setups to prevent the OS from killing the connection and rendering the KVM device useless. It goes for anywhere between 100 and 240 dollars from what I can gather.

    It is potentially criminally expensive if all it contains is one chip or one board with a resistor on it, and I plan to get one and see what I can do with it. I'm SO sick of this hotplug issue, and I want to solve it. Please wait until I acquire one and analyze it. Thank you so much for your interest, it is a little relief that I'm not the only one having this issue.

  • 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 (https://hackaday.io/project/18634-edid-inserter) 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 9 project logs

Enjoy this project?

Share

Discussions

Michael wrote 12/21/2023 at 19:02 point

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

  Are you sure? yes | no

sofakng wrote 05/08/2023 at 17:23 point

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.

  Are you sure? yes | no

Taylor wrote 04/10/2023 at 20:29 point

Any luck on the test?

  Are you sure? yes | no

Steve wrote 02/01/2023 at 01:35 point

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!

  Are you sure? yes | no

Torbjörn Lindholm wrote 02/05/2023 at 14:04 point

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

  Are you sure? yes | no

Lucas wrote 12/09/2022 at 22:09 point

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.

  Are you sure? yes | no

Torbjörn Lindholm wrote 02/05/2023 at 14:07 point

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.

  Are you sure? yes | no

ziddey wrote 02/05/2023 at 19:13 point

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

  Are you sure? yes | no

Limboman wrote 02/05/2023 at 20:07 point

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.

  Are you sure? yes | no

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 https://www.networktechinc.com/displayport-hotplug-maintainer.html

  Are you sure? yes | no

Torbjörn Lindholm wrote 02/05/2023 at 14:08 point

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.

  Are you sure? yes | no

Limboman wrote 02/05/2023 at 20:02 point

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?

  Are you sure? yes | no

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

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 ?

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

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

  Are you sure? yes | no

Torbjörn Lindholm wrote 02/05/2023 at 14:11 point

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

  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 27.20.100.9316

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