Hacker News Reader

Comment by formerly_proven | Hacker News Reader

Using a literal switch or multiplexer would have the link disappear, so switching causes ~5-10 seconds of delay, assuming the machine doesn't crash or hang because somehow that's okay behavior for computers in 2020...?!

Additionally: The DisplayPort spec mandates that operating systems have to throw a huge temper tantrum and garble your desktop and windows when you disconnect or turn off a display. (Yes, nVidia and Microsoft consistently deny implementing an option to turn this utterly braindead behavior off, saying that it's not a bug, but intended behavior because DisplayPort and VESA say so).

What KVMs instead contain is similar to the rescaler ASICs found in a monitor, they receive multiple streams of display data and mix/forward/scale one of these. But since they constantly receive all of the streams, switching can be instant, or at least as quick the monitor can modeswitch (which, for some reason, takes screens at least a second).

View on HN

> What KVMs instead contain is similar to the rescaler ASICs found in a monitor, they receive multiple streams of display data and mix/forward/scale one of these. But since they constantly receive all of the streams, switching can be instant, or at least as quick the monitor can modeswitch (which, for some reason, takes screens at least a second).

Do you know of a DisplayPort KVM switch that actually does that? I tried one a few years ago (it was one of the first ones I saw for a reasonable price), but I returned it immediately because I got the brain-dead window-rearranging behavior you described whenever I switched. I've been reluctant to try another until I know it solves that issue.

I still use one of these HDMI switches (https://www.iogear.com/product/GCS62HU/), because it's EDID support actually does make it transparent to the PCs, so I can switch instantly like I want to.

I haven't used them myself, but I've heard the KVM switches sold by level1tech don't trigger that.

A year ago, I considered their product...then I saw this commentary[1] straight from the cow's mouth:

> Most of the support on (their DisplayPort 1.2 KVM offering) have been down to bad or dodgy DisplayPort cables. Seriously, it's like sort of nuts. Like you go on Amazon, you order a DisplayPort cable, it doesn't work, and it's like, "Well, I have two DisplayPort cables that work independently, but when I plug both of them into the KVM, it doesn't work." The KVM doesn't have a repeater. So if you've got two 6-ft cables that pass through the KVM, it is like as if you have one 12-ft cable, and while one 6-ft cable might work, 1 12-ft cable will not because...(Jedi hand gestures)...repeater. So use good quality cables, you'll be fine.

Ignoring the "repeater" terminology wank, that soundbite disclosed enough about the white label device's internal architecture for me to infer with confidence that even if EDID was properly implemented (the easiest part), the video interface is skimp and doesn't actually buffer frames in realtime...which means that on switch, the monitor's receiving ASIC will detect frame interruption as it starts to receive its new stream and blank for a second or two while it tries to reacquire...which is definitely not the instantaneous performance I was looking for.

[1] https://youtu.be/0b0_yz-oDjQ?t=74

Damn...

I’m using a TESmart HDMI KVM that behaves well, at least with my monitors. My USB peripherals sometimes need a reset though.

https://www.gdsys.de/en/kvm-solutions/kvm-switches/dp12-mux3... This is a switch that can switch video instantly when all source have the same resolution and refresh rate. But it's not really for the consumer market and therefore is quite expensive.

ConnectPRO claims that their switches pass EDID information to all systems. They have some examples of it being in use in Youtube https://www.youtube.com/user/rexwu168/videos

I finally ordered one a while ago after I couldn't find anything cheaper with similar functionality, but it's currently on backorder so it will take some time to arrive & see how well it works in reality.

I have a ConnectPro UDP2-12AP, and can confirm that systems connected to it do not see the monitor go away on switch.

There is an interruption if you press the KVM reset button, but that's not something you should often do.

Can you provide more information about the details of DisplayPort you're referring to, and what actual spec-required behavior you're referencing?

That'd be the most gracious DisplayPort hot-plug detect.

I assume garbling windows isn't technically mandated by the spec, it's just what DWM does when Windows tells it to "rearrange" all windows on a desktop that has lost a bunch of displays, because Windows helpfully noticed that they were turned off.

https://www.reddit.com/r/nvidia/comments/66opvp/this_display... https://answers.microsoft.com/en-us/windows/forum/all/how-to... https://answers.microsoft.com/en-us/windows/forum/windows_7-... (AMD workaround) https://www.overclock.net/forum/74-graphics-cards-general/12... https://superuser.com/questions/630555/turning-displayport-m... https://www.nvidia.com/en-us/geforce/forums/discover/209725/... https://www.reddit.com/r/Windows10/comments/4895u9/turning_o... https://www.reddit.com/r/nvidia/comments/9qn0dk/has_anyone_f... https://www.reddit.com/r/windows/comments/788l4f/put_one_dis... and many, many more, like this one: https://what.thedailywtf.com/topic/24548/displayport-is-the-...

This (monitor being removed from the system if I turn it off) must be the most braindead idea I've seen in a while. This is why don't turn off my monitor after work day any more, but leave it on and let it go to power saving sleep when it wants so.

Until I figured out what the hell was going I was pulling my hair every morning when I turned on my work monitor (40-something inch 4k display) and found all program windows in the top-left corner of the monitor, stacked on top of each other and resized to some svga-resolution.

Be happy it only happens when you turn off the display. A display on one of my computers triggers this when it goes to sleep, which is about 20 times a day; even worse, it causes every single window to then shift to the "newly discovered" monitor when it wakes up. Almost makes multiple monitors pointless because you have to constantly rearrange the windows back to how they were.

> The DisplayPort spec mandates that operating systems have to throw a huge temper tantrum and garble your desktop and windows when you disconnect or turn off a display.

Sounds colorful. Can you cite the requirement and revision of the standard referenced? I'd like to read the actual verbiage for myself.

...and I now see your response[1] to an equivalent question.

[1] https://news.ycombinator.com/item?id=24359220

Looking at the normative language of the early DP v1.1a § 3.3 Hot Plug/Unplug Detect Circuitry:

> The HPD signal is asserted by the DisplayPort Sink whenever the Sink is connected to either its main power supply or “trickle” power. HPD signal specification is shown in Table 3-2.

To be sure, HPD assertion on "trickle" power is the monitor's requirement.

Looking closer at Table 3-2 (empty Nom col removed, Comments col separated for clarity):

  | Parameter                          | Min  | Max | Units | Comments |
  | ---------------------------------- | ---- | --- | ----- | -------- |
  | HPD Voltage                        | 2.25 | 3.6 | Volt  | (a)      |
  | Hot Plug Detection Threshold       | 2.0  |     | Volt  | (b)      |
  | Hot Unplug Detection Threshold     | 0.8  |     | Volt  | (b)      |
  | HPD source termination             | 100  |     | kΩ    | (c)      |
  | HPD sink termination               | 100  |     | kΩ    | (d)      |
  | IRQ HPD Pulse Width Driven by Sink | 0.5  | 1.0 | ms    | (e)      |
  | IRQ HPD Pulse Detection Threshold  | 2.0  |     | ms    | (f)      |

> Comments:

> (a) HPD signal to be driven by the Sink Device

> (b) HPD signal to be detected by the Source Device

> (c) Source Device must pull down its HPD input with a ≥ 100kΩ resistor.

> (d) When a Sink Device is off, it must pull down its HPD output with ≥ 100kΩ resistor.

> (e) Sink generates a low going pulse within this range for IRQ (interrupt request) to the Source

> (f) When the pulse width is narrower than this threshold, the Source must read the link / sink status field of the DPCD first and take corrective action. When the pulse width is wider than this threshold, it is likely to be actual cable unplug / re-plug event. Upon detecting HPD high, the Source must read the link / sink status field, and if the link is unstable, read the link / sink capability field of the DPCD before initiating Link Training.

Then just below Table 3-2:

> The voltage level of the HPD pin is monitored by the Source Device. TTL levels must be used for the detection.

> The Sink Device may detect the presence of the Source Device by monitoring the DC voltage level of the AUX CH lines. Source detection is an optional feature of a Sink Device.

Based on this language and description of noted workarounds, color me unconvinced that DP spec ambiguity was the root cause of this issue.

Where is "trickle power" supposed to come from? DisplayPort also mandates that DP_PWR not be connected by cables (only intended for adapters / dongles, see § 4.2.1.1 and Figure 4-23). Note that EC demands that electronics put in stand-by / "off-mode" may not consume more than 0.5 W of wall power.

So I think what might be going on behind the curtains is that 1) DP requiring handling of hot plug 2) DP forbidding "trickle power" being sourced from the DP port 3) monitors perhaps not being able to meet 0.5 W standby if they'd entertain the DP interface 4) Operating systems handling display hotplug disgracefully combine into one heck of a bad user experience.

Things actually start to align now, because this issue started to happen en-masse around 2013-2014. And that's precisely when the more stringent standby power requirements came into force. For example, the Dell U2713H doesn't do this, while the later U2715H does. Both of these are DP 1.2 monitors, so any new mandates in the non-publicly available DP 1.3/1.4 specs shouldn't matter.

> Where is "trickle power" supposed to come from? DisplayPort also mandates that DP_PWR not be connected by cables (only intended for adapters / dongles, see § 4.2.1.1 and Figure 4-23).

The answer seems to me unambiguous when considering the normative language in § 4.2.1.1:

> The standard external cable connector assembly must not have a wire on pin 20, DP_PWR.

...in conjunction with the normative definition of trickle power per § 1.4 (my emphasis):

> Power for Sink Device that is sufficient to let the Source Device read EDID via the AUX CH, but insufficient to enable Main Link and other sink functions. For sink to drive the HPD signal high, at least the trickle power must be present. The amount of power needed for the trickle power is sink implementation specific.

(To be sure, Figure 4-23 per DP v1.1a is single-slot PCI "Panel Cut Out Reference Dimensions", so unsure what was meant to be conveyed there).

> Note that EC demands that electronics put in stand-by / "off-mode" may not consume more than 0.5 W of wall power.

...which is ~150 mA at 3.3 V nominal. Even generously derating 30% to account for ballpark efficiency losses, we're still talking > 100 mA budget to support an explicitly constrained requirement. I mean asserting HPD in the worst case is apparently a 36 uA affair.

Anecdotally, I haven't encountered the issue despite a bias towards DP (on advise from a friend in compliance test over a random beer discussion on radiated emissions performance); all my setups discriminate to either dual U2415 or dual U2412M as a matter of personal preference.

Just thought I'd remark in passing because VESA specs never really struck me as being technically egregious in its ambiguity.

I was referring to DP 1.2, where Figure 4-23 shows the exact pin connections of a cable.

> ...which is ~150 mA at 3.3 V nominal.

Small power supplies become very inefficient due to relatively fixed losses relative to output power. The 0.5 W spec is wall power, so if you fully use the 0.5 W, you might get 0.1-0.2 W worth of output.

> Anecdotally, I haven't encountered the issue despite a bias towards DP (on advise from a friend in compliance test over a random beer discussion on radiated emissions performance); all my setups discriminate to either dual U2415 or dual U2412M as a matter of personal preference.

I'm using a Dell U2415 connected by DisplayPort to Intel graphics right now, and if I turn it off (using the soft buttons) my desktop and windows are garbled because it "disappears" from the system despite not being disconnected.

Compare this to the DVI days where I could literally switch the outlet strip powering my screens off and nothing would get garbled, and the system would never hang or crash. I'm pretty sure it's impossible for DisplayPort to support that, since the display has to be powered to avoid being un-detected by the system. So I'm not asking for that to work. Obviously a good standard would support this usage, but DP never will, so okay, fair enough. I'm just asking for the insanity of "disconnecting" monitors sent to stand-by / "soft button off" and subsequent garbling of my workspace to stop. And while they're at it, maybe fix crashes and hangs on monitor re/disconnects. Y'know, it's not really "plug and play" if I plug it in and have to hit the reset button to get my machine back.

Real world analogy: A standard for desks that dump everything on the floor as soon as you turn your back to them would never fly. But somehow the equivalent is acceptable for computers.

PS: A Japenese entrepeneur sells DPHPDMA devices, which are little dongles plugged directly into a Displayport output and contain a microcontroller powered by DP_PWR, which intercepts the EDID communication etc. and essentially performs EDID emulation in hardware (since GPU manufacturers disable software EDID emulation for consumer cards). They're like 50 bucks plus international shipping each.

Another question is why does it take so very long in human scale for all these things to happen? You'd think scanning for a valid data frame and flinging bits onto the glass would take under one frame, so 0.01s?

With respect to HPD, one contributing factor per DP 1.1a § 5.1.4:

> There is no mandatory time constraint on the Source Device’s response to a plug / re-plug event, but a Source Device vendor may want to impose a voluntary constraint similar to that for HPD IRQ events (for example, 100 ms) to ensure a good user experience via prompt discovery and configuration of newly attached devices.

There's a lot more going on behind the scenes than mere "scanning for a valid data frame and flinging bits onto the glass", and much of it has nothing to do with approaching technical limits, e.g. the dynamic of multiple product vendors finding incentive to reach consensus in standards development despite naturally seeking to cut each other's throats in the open market.

You wouldn't happen to know how to prevent the tantrum from happening? It's been driving me nuts

Disable all power saving / standby features and never turn the screens off manually or cut their power while the PC is on.

And perhaps a little unpaid ad:

> PS: A Japenese entrepeneur sells DPHPDMA devices, which are little dongles plugged directly into a Displayport output and contain a microcontroller powered by DP_PWR, which intercepts the EDID communication etc. and essentially performs EDID emulation in hardware (since GPU manufacturers disable software EDID emulation for consumer cards). They're like 50 bucks plus international shipping each.

Reply on news.ycombinator.com