Ask HN: Can you recommend an “instant-switch” Monitor? Does one exist?
Current situation:
- I have three sources connected to my monitor (1 HDMI, 1 DP, 1 USB C).
- The monitor is on a switched off source i.e. due power save mode.
- When I try to switch to another source, it takes 4 seconds or more to switch
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.
184 comments
[ 4.2 ms ] story [ 228 ms ] threadI 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.
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.
Use software solutions if you actually need instant switch. But you probably don't.
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)
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.
What does this statement add, beyond conveying that you don't personally care what the OP wants?
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.
For the highest resolution you needed a better monitor though so I didn't have much experience with that one. The Atari Falcon also had more resolutions with instant switch but my memory is getting quite fuzzy there :-)
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.
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.
More options, like if you need higher res: https://www.bhphotovideo.com/c/buy/Live-Switcher/ci/2865
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.
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).
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.
Expecting everything instant-on is naif.
But in reality, you've got whatever tiny micro is inside the monitor, talking to whatever's on the graphics card, in turn talking to display drivers and who-knows-what-else on the PC side.
Slightly related to this, in some ways, is things like wifi connection. I have an ESP8226 that I've built a clock around. That thing will connect to the wifi, negotiate security, contact a time server, probably within one second. None of that is down to my ingenuity, it's literally how it works out of the box.
So the problem may just as much be on the OS side, rather than the monitor and the E-DID protocol.
Yeah. And the DM must adapt to the new resolution, redraw stuff, maybe adjust the refresh rate. That's why I think stating "I want it on immediately" is a bit naive and assuming.
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/
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.
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 ;-)
https://www.blackmagicdesign.com/products/blackmagicmultidoc...
I don't really have a use for one but I wish I did ...
Everything now is so slow.
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.
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.
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.
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.
May not be worth it if you are already at 4s though.
Linux isn't my daily driver so this might be a dumb question, but what's up with Wayland? I feel like I've been hearing for a solid decade that X is dead yet whenever someone recommends me a piece of software it never works on Wayland. Wayland is fourteen damn years old at this point.
Most app developers are dragging their feet when it comes to supporting wayland, but with big distros now shipping wayland by default, the pressure to make sure their apps work in wayland is really high in the past two years. For example, just last week vscode finally fix rendering issues that plagued wayland + nvidia users for years (had to use insiders version with some extra args but at least I can use vscode in wayland now). I think the rate of developers finally adding wayland support in their apps is finally accelerating.
Please note that I’m having issues with their smart keyboard port, but that may be related to the interaction between the two.
[0] https://www.amazon.com/gp/product/B088WGKFZH
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...
TLDR: because it is done over a slow protocol (I²C) and because of artificial delays in code to account for slower devices
The negotiation is done when the host initiates it, usually when the cable is connected to a port or when coming back from deeper sleep/standby.
If the host remains active after the negotiation, the monitor doesn't go through the process again, I explained how that worked for me here: https://news.ycombinator.com/item?id=34051428
The problem that OP has is when the host being switched to is in standby. In that mode, most devices deactivate the video ports completely, disconnecting the monitors and removing them from the hardware device tree.
Switching to the inactive input without waking up the host device will usually show a "No signal" message on the monitor. Waking the device before switching to the input could improve the waiting time, but that is an implementation detail depending on both the monitor and the OS and can't be guaranteed.
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.
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.
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.
Why does the negotiation take so long, though? There doesn't intuitively seem to be a lot of information.
[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...
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.
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.
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.
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!"
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.
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.
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.