There are hardware limitations that make what you're asking for impossible.
Use software solutions if you actually need instant switch. But you probably don't.
Use software solutions if you actually need instant switch. But you probably don't.
On top of that, just look around - there is no perfect display,no matter how much one is willing to pay. Every single one has major drawbacks in certain areas.
It would however be more expensive, since you would need to duplicate at least some of the electronics within the monitor, a few of which also incur licensing/certification/patent/whatever fees.
You can't just tell the computer that you're now interested in the display data of the other display - that would incur latency.
You'll have to be receiving the information for the second display the entire time, storing it in what is commonly called a framebuffer, aka a bitmap in memory somewhere.
Most types of display have such a thing backing them anyways - one way or another - since they need to remember what they're supposed to display.
It's much more likely that the handshaking was implemented by an incompetent organization that doesn't care about quality.
I think you're concerned that because there's "buffers" there would be extra latency? There doesn't have to be.
The bandwidth of that bus is small indeed, but most of the latency comes from artificial delays and error recovery in code: monitor is sending a message to host then sleeping 30ms to make sure the reply is ready, host doing the same thing, and this happens multiple times to negotiate pixel clock, signal timing, colors, resolution, additional features like suspend/reset/HDR/overscan etc.)
You can see how in the MCCS specification [1] both host and display entrypoints for communication start with a delay: https://shots.panaitiu.com/e8D7tQ
You can also see how that looks in Lunar's DDC code [2] [3].
For now, it's incredible that we actually have such a standard as DDC and most monitors work with most devices. A coordinated effort between monitor vendors and laptop/PC/GPU manufacturers into creating another faster standard with modern technology seems out of the question. But maybe with the advent of Thunderbolt this may change in the future.
[1] https://files.lunar.fyi/mccs.pdf
[2] https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#... : Delay on requesting data from monitor
[3] https://github.com/alin23/Lunar/blob/master/Lunar/DDC/DDC.c#... : Delay on communication error before retry
You'd obviously want this to be optional for special cases, but would that work, if implemented in a monitor or KVM?
It's not so much the delay that's annoying, but the renegotiation with something which is so obviously the same device.
The problem that OP is facing is switching to an inactive input that went into power saving mode. In that case, the link between the inactive device and the monitor may have been broken and it's impossible to know if the device is the same as the one before after reconnection (with the same exact video settings etc.).
This doesn't have to be the case though. Before I found out how to use I²C on Apple Silicon Macs, I was using a Raspberry Pi connected to an HDMI input of the monitor that could listen to DDC commands through an HTTP server: https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/#the...
And because I didn't want that Pi Zero to get hot, I managed to only keep the DDC lines open and stopped the video signal from being sent using `vcgencmd display_power 0`.
With those settings, the monitor still switched between inputs in 1 second, with the added small latency of having to run `vcgencmd display_power 1` (which was fast enough once it was automated to run on input switching)
What does this statement add, beyond conveying that you don't personally care what the OP wants?