What the monitor should do: S - Switch instantly no matter if the current source is on or not.
WHY the long delay??? It is really something that angers me.every.damn.time.
I have a Dell U2723QE, but older models have that as well as others from other brands.
Would love to get a recommendation for an instant switch model.
If you want to switch fast and often your best bet is getting an HDMI switcher that is basically always connected to the monitor and both sources and then toggles between the two. Beware of the supported resolutions and framerates.
A cheap hack would also be to connect your second source to the first using a HDMI Grabber (basically a HDMI-source-to-USB-webcam-converter) and open a fullscreen window displaying that. Then you could e.g. switch by switching virtual desktops.
Another post recommended rhe Blackmagic Atem, this should also work.
http://decimator.com/ Has some really good shit including (accidental) hdmi copy protection removal.
Sometimes the 400 Euro grabber works sometimes the 30 Euro one works. The expensive ones are surely more rugged tho.
I suspect all most manufacturers do is build a decice around some existing HDMI IC and if your stuff is supported by that IC and they didn't cut a ton of corners it works. Maybe you need the 4000 Euro price class to run it all, I never tried.
May not be worth it if you are already at 4s though.
Please note that I’m having issues with their smart keyboard port, but that may be related to the interaction between the two.
[1] https://www.nvidia.com/content/Control-Panel-Help/vLatest/en...
[2] https://nvidia.custhelp.com/app/answers/detail/a_id/3569/~/m...
[3] https://portal.7thsense.one/user-guides/MC264-display-config...
Why does the negotiation take so long, though? There doesn't intuitively seem to be a lot of information.
Is this something you've tried before and could go into more detail about? I've got an HDMI grabber for using a DSLR as a webcam, but never thought to output the display of one of my computers to another. This would solve a lot of issues regarding switching between work and personal laptops.
Can no EDID negotiation be faster?
Even if you remove the DDC wires, the OS will still try to communicate, and it might delay this even more because of the retries and delays in code.
You might get a headstart if you hardcode the EDID in the OS itself. There are ways to do this on Linux [1], Intel macOS [2] and Windows [3].
[1] http://billauer.co.il/blog/2020/08/linux-override-fake-edid/
[2] https://github.com/mbruggmann/osx-edid-overrides
[3] https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
No, at this point removing EDID will simply get the display not detected at all. It used to be optional in the times of VGA, where you could just drive out 640x480 "blind", but there's too much stuff in there these days.
Everything now is so slow.
Learn "FPGA 'n stuff" and build my own display controller. Like many people here, I don't understand why this takes so much bloody time. Not just the input switching, but also switching resolution or refresh rate on the same input. So either I'd have an a-ha moment and see why it's not possible (more likely outcome), or well, it'll just work and I can write a cool hackaday post.
The EDID explanation given in the comment currently at the top doesn't make too much sense: Even if the display is off and not in some super hardcore energy saving mode, EDID works, i.e. your computer can query the EDID data from the screen and know what its preferred resolution is, etc. Likewise, even if your display is switched to HDMI-1, a machine connected to HDMI-2 can already be outputting 1080p60 to it, so why does switching inputs take more than a few milliseconds?
Afaik (and I only have very rough knowledge here), there is no side-channel in HDMI/DVI that tells the display what mode it's actually receiving, so the display has to look at the signal and make sense of it. So you have to put some brains in it. But that can hardly take several seconds, i.e. hundreds of frames? Maybe two or three frames! I could see this being a cost cutting measure, maybe doing the dumb implementation that takes seconds instead of milliseconds saves you a cent or two per device.
The hdcp handshake is a particularly bad mess which most manufacturers don't implement well due to a very confusing spec. My experience has been some devices start showing video right away and kill it if hdcp handshake fails, while other devices don't show video until hdcp handshake succeeds. Behavior is quite hardware dependent.
The commercial vendors like Extron (crosspoint switchers) and Crestron (digitalmedia switchers) have this figured out pretty well where switching is almost instant so it's definitely possible. I think Crestron has some technical papers out there that discuss the challenges involved.
Similar root cause though - technology becomes available that makes the steady state performance much better in return for some setup costs, the setup costs are worth paying in almost all applications so it's an obvious choice to go with the new technology but still annoying when you encounter its drawbacks.
What would be nice is if it had a low-quality stream with more keyframes so it could switch quickly and then go to the higher quality stream when that gets to a keyframe.
But I can see why that kind of complexity wouldn't be added just so you can switch quickly to 3 seconds of low quality video.
Sure, soon after I would give up TV for other reasons, but I probably would have kept regular TV for way longer if this delay was never introduced.
Yep, and everything was exactly the same video format, and all TVs had the same capabilities.
The slowness was present on VGA monitors as well, if you recall.
Slow switching is a tradeoff worth having, given that it allows me to have any number of digital resolutions and color depths available to me.
I was quite surprised when the brand new PC needed 2-3 seconds just to switch resolution. And we are still there after 30-odd years? A KVM switch with analog signal was just the same, still long time to switch between signals. I'm using a remote control software to the local computers so I don't have to wait between every switch. With the added bonus that I can copy/paste between the computers without having to think.
On the Atari and Amiga, the horizontal/vertical scan rates are constant; the only thing that changes is how scanout turns pixels in video memory into signals for the CRT.
I can't speak to the Atari, but my memory is that this is not true of the Amiga.
The Amiga could do this amazing thing where it would display multiple resolutions on a monitor at the same time, divided horizontally. Analog was flexible that way.
An Amiga could even display two different resolutions from two different sources on the same monitor at the same time.
This was part of my workflow when I used an Amiga to do live TV news graphics around 1990.
PC monitors were analog too, but with PC monitors from EGA onwards, changing modes meant potentially changing scan frequency, which required the monitor to sync with the signal at the new frequency. Apparently a high-quality Sony monitor could do this instantly but many of us were slumming it with monitors that took a while to sync.
See, for example, boot up times.
Also see how recovering from sleep/hibernation is now slower than 80s computer boot times, so expect a second layer of abstraction to form soon in the market, a faster recovering sleep mode than actual sleep mode.
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.
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.
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.
What does this statement add, beyond conveying that you don't personally care what the OP wants?
Something like this should probably work:
https://www.rextron.com/product-4K-2-Port-Full-Frame-PBP-KVM...
Edit: The one above is merely the first one I found, not a recommendation.
Be aware that such things may incur extra latency, since it's not just passing signals through, but rather processing them and repackaging them.
Rextron is not a company or set of devices I've ever encountered. From a quick look at their site they look to be an OEM/ODM provider though so would hazard a guess they may have taken some 'inspiration' from either of the above orgs.
They also support hot key switching, so my hands don't need to leave the keyboard to switch, which is nice.
Note that the keyboard interception is less than stellar, so it’s equally possible your keyboard just won’t work correctly when plugged into their magic port. My copy-paste is impossible when plugged in (well, dropped 2 out of 5 times, which might as well be).
That was handshaking, and it was how modems figured out which speeds and protocols each other supported so they could figure out how fast to transfer data and how to encode it.
Monitors are kind of the same. There's handshaking that goes on each time you connect a monitor to a video source.
Like (and I'm totally making this up):
- Hi, I'm an AMD video card.
- Hi, I'm an LG monitor.
- You're a monitor? Great! I have some data I'd like to display. What resolutions, refresh rates, and color depths do you support?
- Well, I support 1920x1080x24bpp@60Hz, and 1600x900x24bpp@70Hz, and...
- Cool! I'd like to display at 1920x1200x24bpp@60Hz, please.
- Sure thing, hang about while I get that set up.
[Monitor CPU sets up whatever framebuffers, scalers, etc. are necessary to display at 1920x1200x24bpp@60Hz]
- Right then. Ready for your first frame.
- All right, first frame incoming...
Only then will you get your display. This can take a couple seconds.
If the connector is high bandwidth enough to send hundreds of thousands of pixels 60 times a second, how can it possibly be so slow to send a few bytes of handshake or EDID data?
Handshakes should be happening nearly instantly. You can complete opening a TCP connection to the other side of the world in a fraction of the time it takes to switch input on the average monitor.
The former is indeed very high speed, in the order of gigabits per second (up to 48gbps in later iterations), whereas the latter can seem ancient in comparison - 500bps to 115.2kbps - several orders of magnitude slower. The reason is that while the high data rate bus is handled by powerful, dedicated hardware (GPUs and ASICs/FPGAs), the control plane is usually done by micro-controllers (or otherwise lower-power devices) that are responsible for general management of the display. Sure, it would be nice if they had more powerful hardware and a faster bus, but those changes usually aren't what people are shopping for and so the standards committees aren't pushing makers to make these changes...
Most EDIDs are 256 bytes in that repo. At 500bps it may take seconds to transmit, but 115.2kbps (14kbytes/s) is enough to do it in an instant.
As usual, the issue is probably not a bus speed or a chip cost itself, but a crappy legacy timeout-based negotiation process which nobody touched or restandardized since it was slapped together. You can’t just autoupdate all compatible hardware in the world and move on.
My blind economical guess is that one couldn’t even find controllers today which are slow enough to DDC back and forth in seconds, because the package/assembly probably takes 95% of the cost anyway. Please correct me on that, I’m curious.
Why does this whole negociation take seconds and not milliseconds?
Or my car: it's full of electronics. Chips and code everywhere. Even my pedals, which used to be cables decades ago, are now fly-by-wire. It's chips and code everywhere.
Yet feedback is instant.
Now I understand a monitor is not the same as ethernet and is not the same as a car but... Seconds?
Car: your car is an integrated system where all the components have been selected with the intent of working together as an integrated system. A display device often supports many modes and has very few guarantees about how sources will behave, thus inter-device negotiation is needed upon connection.
As other comments have noted, the control channel is fairly low bandwidth and there is potentially a decent sized chunk of info to exchange, plus timeouts and delays to ensure the display can work with older or less featured sources.
I think the quirk was, if I have something plugged into the VGA input, and the HDMI input goes to powersave mode, the monitor "helpfully" says, "Oh, no HDMI signal? Let me switch sources!"
The amount of actual information transmitted there the handshake should be as close to what we perceive instant.
We know the cable can handle it because a modern desktop resolution at 60fps goes down the same cable.
However, what I really want is just to be able to switch the input via command line. I know that there is a protocol that supposedly allows this (ddc?), But it seems that support for it is not standardized. This means the feature I want can't be found in the product specs.
So my question: what's a monitor I can buy that will allow me to switch inputs by command line? (Ideally 4k)
I also keep a public monitor database here where you can check if a specific monitor usually works with DDC or not: https://db.lunar.fyi/
The problem with LG is that they report very generic names so they can't be filtered well in the database. You can see what I mean with this query:
SELECT DISTINCT ON ("DisplayProductID")
name, ddc,
"resolutionString",
"refreshString",
"dotsPerInch",
"isHiDPI",
"isRetina",
"DisplayProductID"
FROM
displays
WHERE
ddc AND "is4K" AND width IS NOT NULL
AND NOT "kCGDisplayIsVirtualDevice" AND NOT "isAirPlayDisplay" AND NOT "isTV"
AND "DisplayProductID" != 0 AND name NOT LIKE 'Unknown Display%' -- Filter out those in a semi-connected state
AND name LIKE 'LG%' AND "DisplayProductName" LIKE 'LG%'
ORDER BY
"DisplayProductID" DESC
LIMIT 10;
FYI, I originally learned about this stuff via https://haim.dev/posts/2020-07-28-dual-monitor-kvm/.
I sometimes want independent control of the keyboard switch and the monitor switch, so I'm not sure if a KVM is the best option for me.
Yesterday my kid wanted to see a video of volcanos on YouTube, followed a really bright picture of My Little Ponys, the monitor managed to start flickering and retain a shadow image of the little ponies, even as I switched between laptops and power cycled the monitor. This only happens on USB-C input, but seeing as the monitor have an Ethernet adaptor and works as a USB hub, USB-C is pretty much the reason I got it.
Notes: It happens really rarely, and exclusively with the M1 MacBook Air. It might be a firmware update away from being fixed. Also Dells has an excellent return policy.
[0] https://i.dell.com/is/image/DellContent/content/dam/ss2/prod...
I assume that the upgraded version U2723QE should be only better, with the possible exception of firmware bugs like what was mentioned by the other poster.
https://hdfury.com/product/8k-vrroom-40gbps/
It maintains a live connection to each of 4 x HDMI inputs, 2 x HDMI outputs (mirrored or matrixed), and 1 x eARC audio output, and can switch between them "instantly" as you ask. You can switch with a button at your desk, or via API.
I selected this model because it supports (a) up to 8K and we use 5K monitors, both full 5K and ultrawide 5K, and (b) variable refresh rate (VRR) at 4K@120hz for gaming.
In a teleconference room with e.g. a big on the wall and a small screen on the table showing same or different sources, this lets you have multiple input sources (e.g., teleconf system, laptop, game system, and OTT TV source) that 'just work' without users having to know how to make it work.
The feature list for video includes:
- Unlock true VRR/FRL on Samsung Q90/QN900/QN95 and similar models
- Up to 8K60 444/RGB 12-bit via DSC at 96Gbps
- World First 40Gbps Upscaler, Splitter, Switcher with full audio extraction for VRR and any signals
- Play Xbox 1X games at 4K120 Dolby Vision on LG C9, BX & SONY HDMI 2.1 TV
- Work from ANY HDMI source to ANY HDMI, ARC or eARC sound system
- HDMI 2.1 Full Audio/Video passthrough up to FRL5: 40Gbps/1200MHz
- Upscale FRL5 and ANY signals 2K>4K, 4K>8K and 2K>8K up to 120Hz (no upscale for VRR/1080i/720p/480i-p)
- Downscale ANY FRL0/TMDS signals 8K>4K, 4K>2K or 8K>2K up to 120Hz (no downscale for FRL5/VRR tbd)
- Add or remove any input from the CEC network at any time via webserver, APP, IR/IP or RS232
And for audio, it solves getting eARC signal to amps or soundbars that can support Atmos when the monitor or TV doesn't support it:
- Full Audio from ANY HDMI source (including VRR signal) to ANY HDMI, ARC or eARC sound system
- Full Audio up to Atmos/TrueHD from any HDMI source to SONOS Arc/Beam2 or any eARC sound system
- Solve SONOS Arc/Beam2 + other lip sync issue when using external HDMI sources connected to eARC TV
If you get one and find yourself needing support, join their Discord server.
Anyway, pretty amazing if niche devices with fantastic customer support and willingness to add functionally for relatively small numbers of users.
I tend to play games with my projector on mirroring computer output (for things like watching people play VR games socially), and I use a "cheaper" HDMI switcher for the projector to achieve this (it's one of the better ones you can buy in Amazon)—but this breaks the 4K60 HDR output for some games if I'm mirroring displays.
This might switcher might be fully featured enough that my computer won't balk at it.
I have a similar function on my LCD monitor and its basically useless, it seems it throws away 50% of the pixels or something.
Expecting everything instant-on is naif.
Weird how you say that then the thing that was “that’s just the way it is” is often completely solved in the next day or two.
This is the challenge... Not many are willing to question why things are the way they are anymore. In fact, this seems to be frowned upon in more circles than ever before.
"don't rock the boat", "it is what it is", et. al.
The only way out of this hell is to begin construction of your own ladder.
A large part of the delay that you are seeing is from EDID negotiation and HDCP. This happens of the 100kbit/s DDC channel and requires a bit of back and forth. On the above systems this is pre-negotiated so that switching can take place across a single frame.
A lot of that equipment is likely price prohibitive for desktop use, but you may be able to reduce the time a little with sidestepping that process either in your machine setup or with an external bit of lower cost hardware like and EDID emulator (e.g. https://www.extron.com/product/edid101h4kplus).
When a suitable set of image parameters have been agreed HDCP (may) then step in to ruin your day. Again a nice walkthrough of that is available here: https://blog.cryptographyengineering.com/2012/08/27/reposted....
As other commenters have correctly noted, there's definite room for improvement. One thing to remember though is this involves hardware that can be in operation for the order of decades so there's a lot of cruft that accretes in order to maintain compatibility. Frankly it's mildly impressive that for the most part all the above happens in silence and continues to (mostly) work.
https://www.blackmagicdesign.com/products/blackmagicmultidoc...
I don't really have a use for one but I wish I did ...
Maybe try one of the first gen (2014) GSync monitors along with a DisplayPort KVM, if that can work for you. It's my understanding that the first gen GSync monitors all used the same monitor driver board that Nvidia made, so they probably behave similarly.
Honestly I didn't know how much I needed fast wakeup until I had it. It's a way better feature than GSync, yet monitor and TV reviewers generally ignore it completely. There are probably newer monitors with fast wakeup but it's impossible to know without testing. My TV takes like 8 seconds to even turn on its backlight and it's just ridiculous.
It’s not instant but input switching through DDC is the fastest possible method.
That’s because the input that will be switched to is already connected and receiving video in the background, skipping the HDMI/DP protocol handshake and going straight into rendering the new video on the screen.
Between recent models of Acer/Dell/Eizo/LG, I found Eizos to pose the least friction so far, with the LG (may be model-specific) a surprising worst. Reply to this comment with your anecdotes!
EDIT: To address the OP: Switching from an offline source to an active one is def smoother than you describe on my Eizo FlexScan EV series - I estimate it to <2s. The input switching is bearable enough that using the PbyP (two input sources split) is something I occasionally do, whereas with Dells it was just annoying enough to make me not bother.
Now that I have two inputs, and I switch a few times a day, I'm considering getting a new monitor, in some part to move to one with better input controls.
0: I use `ddcutil` (on Linux), it takes about 2 seconds for the switch: `ddcutil -b $bus setvcp 0x60 $source`
1: Use something like NoMachine or VLC - would probably cause more problems if you've got devices that go into power-save mode
2: Ensuring that your devices are outputting the exact same mode may decrease the time.
I guess the reason for this is actually the monitor and GPU. They will resync to each other after figuring out the peer capabilities and probably take some time for an actual frequency sync. Therefore I don't think any kind of switch would make it better - the switch would need to be intelligent enough not to drop the display stream but be an actual GPU on its own. Plus in this case it would need to have the exact same display signal frequencies that the attached GPUs use.
I haven't tried it with a computer but I think mouse-to-screen latency would be a limiting factor.
In my (very poor) understanding, it 'caches' the information about monitor capabilities. I used it to prevent my laptop from rearranging windows when my monitor goes to energy saving mode.
Not always, though. The switch sometimes happens instantly. (At least, it has been this way since I replaced my Nvidia card with an AMD. I don't recall whether the Nvidia ever switched instantly.)
I wish I knew what conditions make it instant, so I could try to make it happen consistently.
https://www.lindy.co.uk/audio-video-c2/matrix-switches-split...
This is your problem, isn't it? I never use power save mode and have no problems with these delays.
[1] https://connectpro.com/collections/video-emulators
[2] https://news.ycombinator.com/item?id=24362388
Do you want your cake, or you do want to eat it too?
More options, like if you need higher res: https://www.bhphotovideo.com/c/buy/Live-Switcher/ci/2865
Somewhat on this topic, I wish one could compare motherboards by the time-to-boot delay.
If reviewers start benchmarking something, manufacturers will optimize for it eventually.
As an added bonus, the built-in firmware is terrible, and presents a "quick-switch" list of inputs which is different from the "normal" list of inputs, because… well, I don't know, just to make customers miserable, I guess.
But this is kind of a hack and you would possibly have undesired latency, especially noticeable when typing fast and moving the mouse.
Link: https://xpufx.com/posts/hundred-percent-software-kvm-switch/
So if your monitor supports it, turn off energy-saving mode settings might fix the issue.
It might also be less annoying to wait 4 seconds, if you think of it as helping to save the planet ;-)
I was in a similar situation when I wanted a easy way to switch between speakers/headphone at any time without messing with settings or apps. I ended up using a physical switch. https://www.amazon.com/gp/product/B008BMLXAU/