Ask HN: Can you recommend an “instant-switch” Monitor? Does one exist?
184 comments
HDMI Switching like that takes long because there is a EDID negotiation going on between the minitor and the input devices.
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.
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.
Note that an expensive HDMI switcher is different from a cheap dongle goblin from Amazon. Try the cheap one first but if you really need instant switching you’re looking at a professional AV device.
http://decimator.com/ Has some really good shit including (accidental) hdmi copy protection removal.
http://decimator.com/ Has some really good shit including (accidental) hdmi copy protection removal.
I am a media technician myself and the odd thing is that I have found no real corellation between price and capabilities when it comes to HDMI switchers, splitters and grabbers.
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.
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.
That’s what I’ve seen. Some super expensive gear works often but having various devices with various chipsets seems the way to go.
Even with one of the fancy KVM switches that were recommended here my switching isn’t instant. It did go down from 10-20 seconds of flickering to +/- 2 seconds though.
May not be worth it if you are already at 4s though.
May not be worth it if you are already at 4s though.
What model do you use that gave you 2 seconds switching time? One of the mentioned Rextron or something else?
I have some knockoff brand off of Amazon, but it has full HDMI EDID emulation so stuff doesn't move around when switching screens. The input switching is about 2.5 seconds or so. The listing [0] looks scammy, and I thought so too when I bought it, but it works -much- better than the previous unit I had from Tesmart, which had generally good reviews but didn't work at all for my purposes, and it was like 40% of the price. I took the plunge on this one as the Tesmart didn't behave nicely with my thunderbolt docks hanging off my various mac laptops, which was extremely, maddeningly frustrating to not have it work all the time.
[0] https://www.amazon.com/gp/product/B088WGKFZH
[0] https://www.amazon.com/gp/product/B088WGKFZH
My "NEWCARE HDMI 2.0b Switch 3 in 1 Out" switcher is that fast.
Can I inquire how you switch inputs (mouse, keyboard) along with the hdmi?
I've found the simplest way is to just use a mouse and keyboard that support bluetooth and RF and just keep the RF dongle on one PC and the bluetooth paired to the other PC. If you're running Windows, Mouse Without Borders is a handy utility and I'm sure there's an equivalent for Linux. I often find myself just using Moonlight streaming as a remote desktop since my tower is a lot more powerful than my laptop.
On linux you can use Barrier / Input Leap. No Wayland support though, still work in progress for unforeseeable future. Can't find any KVM app that works on Wayland yet. RKVM used to work on Wayland but not anymore.
No Wayland support though, still work in progress for unforeseeable future
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.
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.
Wayland itself is actually pretty solid right now as long as you're not using nvidia card. In the past, applications that need to interact with other applications (e.g. remote desktop, screen recording, keystroke injection, etc) can't be ported to wayland due the lack of api. Those api now already exist in wayland, but completely different which requires huge effort by application developers to rewrite their app. So right now we're just mostly waiting until those apps finally run on wayland, and nvidia finally stop being buggy on wayland.
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.
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.
Thanks just ordered one!
I have the https://www.amazon.co.jp/-/en/gp/aw/d/B078LY741V?psc=1&ref=p...
Please note that I’m having issues with their smart keyboard port, but that may be related to the interaction between the two.
Please note that I’m having issues with their smart keyboard port, but that may be related to the interaction between the two.
Workstation GPUs (Nvidia Quadro[1][2] / AMD Radeon Pro[3]) can emulate/force an EDID in the driver settings and the OS will "think" a display is attached. At least in theory that should get around the handshake.
[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...
[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...
> HDMI Switching like that takes long because there is a EDID negotiation going on between the minitor and the input devices.
Why does the negotiation take so long, though? There doesn't intuitively seem to be a lot of information.
Why does the negotiation take so long, though? There doesn't intuitively seem to be a lot of information.
> 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.
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.
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.
But why is this at input selection? Have manufacturers cheapened out and only 1 port (with DP-AUX, HDMI-I2C ...) is active at the CPU?
[deleted]
Interesting tangent: I wanted to know what ATEM stood for - nothing:
https://forum.blackmagicdesign.com/viewtopic.php?f=4&t=11160...
What if you modify the cables to remove the DDC wire?
Can no EDID negotiation be faster?
Can no EDID negotiation be faster?
EDID is important because it is the only way for the host to know which resolution, color depth, frame rate the monitor supports.
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...
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...
But why is EDID negotiation slow?
See my answer here: https://news.ycombinator.com/item?id=34050157
TLDR: because it is done over a slow protocol (I²C) and because of artificial delays in code to account for slower devices
TLDR: because it is done over a slow protocol (I²C) and because of artificial delays in code to account for slower devices
Why wait until the user switches input sources to do the negotiation? Why not do it earlier so that the new input is ready to go?
The monitor is not the active device in this situation, the host (Mac/PC/SBC) is.
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.
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.
> Can no EDID negotiation be faster?
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.
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.
This has been annoying me since I first tried a PC after using Atari computers since they were a thing. No matter what monitor I use, it will take for ever to switch input port or just a simple change of resolution. I was used to be able to switch resolution several times per frame, you could make a game with low resolution and color on the upper 3/4 of the screen and have the stats in higher resolution 4 color mode on the lower 1/4 of the screen without any sort of delay in the signal, you just set an interrupt on every scanline and if the monitor was painting the 300'th scanline, you witch mode and suddenly it's doing double resolution for the rest of the frame. Then switch back on the Vertical Blanc Interrupt at the start of the frame paint.
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.
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.
One of the reasons why you could switch modes mid-frame is because the concept of a "video mode" is fundamentally different on a PC than on an Atari or Amiga. On a PC, ever since the EGA, the adapter can output at different horizontal and vertical scan rates and the monitor can adapt to the requested mode from the video card. That's why switching video modes takes a couple seconds and may involve a "click" or two. Upon mode switch, the monitor must resync to the new signal.
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.
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.
No. I have a Sony G520 CRT monitor with a hardware switch. When I flip the switch, the other image appears in less than a second. In the past I had a Samsung (I don't remember the model) that made the switch without even interrupting the electron beam, in mid-frame. First 2 frames were garbage, until it sync'd to the new signal, but it only took a blink of an eye to switch (at 85 Hz). It was also very quick to sync after a mode change. I could see BIOS screens that modern flat displays are to slow to display before they dissapear.
Oh man, I miss my Sony G520. It's still the best monitor I owned. I haven't had a monitor that nice since I gave it away a decade ago. It was still in great condition at the time too.
On the Atari and Amiga, the horizontal/vertical scan rates are constant
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.
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.
Yes, because the scan frequency didn't change -- that's what I'm trying to say (my terminology may have been a bit off). The timings of the horizontal and vertical sweep of the beam were constant; upon mode change the CRTC changed how scanout occurred, doubling the width or height of pixels in lower resolution mode but it didn't change the scan frequency, allowing the mode change to occur while the beam kept moving along.
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.
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.
The Amiga could do a lot more than the Atari with the gfx chip. The Atari had three modes, 320x200, 640x200 and 640x400 so two horizontal and two vertical resolutions. It also can change frequency between 50 and 60 Hz but that wasn't instant, it took a couple of frames to stabilize. This I think you could use to get borderless screens with even higher resolution but I've forgotten exactly how it worked.
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 :-)
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 :-)
It was really jarring when I got my M1 Pro MacBook and switching resolutions on the internal display was literally instant. No black screen between the switch whatsoever, it was just there. Makes you wonder what else we've been missing out on all this time.
It's because Macs (almost) always output the native resolution of the display. What you are changing is the draw resolution or scaled resolution.
Good news is thruput always increases with computers over time, bad news is latency only increases over time.
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.
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.
Closest you’ll get is something like a Blackmagic ATEM switcher, using “Program” as the output. Then you can map a software key to swap it out in a single frame. As discussed in another thread, the computer has to be sending the display signal to some device that is seen as a display, and that switcher keeps the video from both PCs buffering at 60 or 30 fps. To the computer it can’t know the display switched and the display can’t handle two simultaneous streams, so you have a device in the middle that bridges that. Down side is depending on the quality of the switcher you might get 1-2 frames of lag because it’s optimizing for frame accurate sync to ensure the least possible “flicker” when the source is switched.
Tangent ... these BlackMagic 2.5" multidocks are so cool:
https://www.blackmagicdesign.com/products/blackmagicmultidoc...
I don't really have a use for one but I wish I did ...
https://www.blackmagicdesign.com/products/blackmagicmultidoc...
I don't really have a use for one but I wish I did ...
This is one thing I really miss about analog tv. You could switch channels as fast as you could press the button.
Everything now is so slow.
Everything now is so slow.
This is one of the things on my TODO-list for when I stumble upon a way to have infinite amounts of time:
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.
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.
Top comment leaves out HDCP entirely as well which I would wager is where a lot of people experience delay. If you want to learn more about it search for the edid hotplug detection. Once that gets negotiated it is followed by the hdcp handshake. Keep in mind while reading up on this the industry terms for devices are "source" and "sync". Video goes from source to sync.
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.
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.
Or, perhaps, weird regulatory/big customer energy saving reasons - “TCO” stickers and whatnot imply some kind of standard measurement, can imagine a “wake from sleep on source change” benchmark driving odd behaviours.
I assume this is for a different reason - buffering and stream compression, you have to wait for a key frame before your TV can display anything.
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.
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.
Good point.
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.
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.
This was the reason I stopped watching TV with my cable box back in the day. I used to love channel surfing, but that became impossible because I would have scrolled through 2-3 channels by the time the next one loaded.
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.
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.
My current (Samsung) display is a pain to switch off. If I forget and switch the PC off first, it goes to sleep and starts blinking its annoying bright blue LED, which I managed to disable when it's on or off, but not when it's asleep. To get it to switch off I have to wake it up, wait until it cycles through all its inputs, gives up and shows me the menu, from which I can finally turn it off.
I destroy or cover with electrical tape any blue leds that mistakenly come into the home. I try to avoid them but sometimes not possible.
I'd plug the thing into a switched wall socket!
This is the way. Too much electronics has LEDs which remain on as long as there is power connected. A switched wall socket or switched power strip is the only sane way to keep electronics in a bedroom.
I remember the sound of just keeping the "Channel Up" button on the remote of my parent's 90ies TV pressed. It was like 10 channels a second, just gliding through syllables. "Br-Da-Wi-Pl-Ka-Ts-Mm-Di-Tu-S-Za-Ol-".
> You could switch channels as fast as you could press the button.
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.
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.
Yes! I remember running my finger down the column of electrical contact switches and changing the channel at 60 fps. "brrrrrrip!"
100% convinced we wouldn’t live in a world with trash like this if just a few more people would say “it’s very slow, can you make it faster? No I don’t care what the excuse for it being slow is I still think it can be faster, currently it feels cheap and awful”
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.
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.
> if just a few more people would
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.
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.
Having been on both sides of that very dynamic, I'm inclined to agree.
Recently (last few months) I've been testing HD Fury VRRoom, and am happy with it, as it allows switching instantly regardless of monitor, by having negotiation already set up:
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.
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.
HD Fury is also well known among home theater enthusiasts and they make some really amazing devices. They’ll also add new features based on fairly niche demand. For example they allow LLDV to be used with projectors that don’t natively support it (JVC, Epson) including sending serial commands to the projector to change its video mode when HD Fury device detects an HDR signal.
Anyway, pretty amazing if niche devices with fantastic customer support and willingness to add functionally for relatively small numbers of users.
Anyway, pretty amazing if niche devices with fantastic customer support and willingness to add functionally for relatively small numbers of users.
Given the $550 price of these, did you ever get to trail one of the cheaper ~$100 options for an 8k 4x2 matrix switcher?
I had been looking at one so that I can retain HDR with windows when duplicating displays and the cheaper ones seem to provide similar functionality.
Dang, this seems like it might actually resolve some of my HDMI issues for my gaming computer display output.
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 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 just bought this and the switching is anything but instant. It still negotiates for a at least a second or 2.
Not on a monitor (that I'm aware of), but it is a major feature of signal distribution equipment for installed AV and broadcast.
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).
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).
100kbit/second is still blazing fast for communication which ought to be on the order of a hundred bytes... 4 seconds at 100kbit/s is 50kB. Why does it have to be so chatty?
When the input is first selected here's will be a hot plug detect, EDID request and an EDID response. That response can be up to 32kB so anywhere up to ~2 seconds depending on how many extension blocks are in use by the display. Here's a nice breakdown on more of what happens there: https://research.nccgroup.com/wp-content/uploads/2020/07/hdm....
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.
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.
Your answer wont be found in monitors. You need a media switch, a good one like thise used in the enteraimment industry for broadcast-quality transitions between inputs. Alternatively, look into streamer-quality "media switches" used by streamers with multiple camera rigs.
https://restream.io/blog/best-video-switchers/
https://restream.io/blog/best-video-switchers/
You'll need a fancy KVM switch that does more than merely acting much like a physical switch would.
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.
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.
Unfortunately I have a similar KVM switch and it is very much not instant. In the same 4 second ballpark as OP. Annoys me too but I just put up with it since I don't have to switch very often and it's sure faster than switching inputs on my monitor's shitty OSD which is what I used to do.
Huh. I don't personally have one, but it seemed more like 1s in normal operation to me and pretty much instant when switching while in PIP mode.
As an aside: does anyone know the deal with Rextron, Extron, and Crestron? What’s going on with the names there?
Extron and Crestron are both major vendors within the audiovisual industry. Both make (mostly) extremely solid products.
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.
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're all a play on the word "electron", which is the subatomic particle that CRTs would fire at the phosphorous screen to produce an image.
There is no price listed for this switch. How much does it cost?
I have a few tesmart HDMI switchers are they are fairly reasonably priced (~$100) and switch decently fast (Under 1 second usually). Occasionally I have to switch the unit off/on if it gets confused, once a quarter or so. There's a switch on the front of the unit so it's not terrible.
They also support hot key switching, so my hands don't need to leave the keyboard to switch, which is nice.
They also support hot key switching, so my hands don't need to leave the keyboard to switch, which is nice.
> 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).
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).
OK, remember when modems were like EEEEEEEkRrRrRrRrRrRrRbaBONGbaBONG....
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.
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.
> Monitors are kind of the same. There's handshaking that goes on each time you connect a monitor to a video source.
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.
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.
There's a major difference between the data-plane (the lanes where frames go from the signal source to the display) and the control-plane (the command and control channel that is bidirectional and used to discover a peer and negotiate settings).
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...
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...
Example EDID: https://edid.tv/edid/752/ (one can also go through a github link at the bottom)
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.
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.
[deleted]
But why does it take a couple of seconds? I can send a ping thousands of kilometers away and get the ICMP reply in 100 ms or something. I can ping my router in less than a millisecond and my router is further away than my computer.
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?
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?
Ping: your device, your router, your ISP's router, etc are already up and running and ready to participate in protocol interactions. Having done a bit of networking in the days where it was still reasonable to use analog modems as backup connectivity, I remember waiting 15-30 seconds for dial out + negotiation to occur before ping replies began flowing again.
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.
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 have an Asus monitor, it has DVI, HDMI, VGA. The HDMI has a quirk, I forget what, so I use a HDMI to DVI cable to connect my laptop to it. And when I switch sources away from DVI, the laptop doesn't think the 2nd display disappeared. So I don't think there's a handshake being done when switching back, because they were holding hands the whole time.
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!"
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!"
Although this is justification to why it’s terrible I don’t consider it an excuse of why it is terrible.
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.
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.
but why does this need to happen every time, when the connected devices are basically static?
Ugh yes, this should be benchmarked! I’m currently on a 34” widescreen Philips monitor and it takes about 10 seconds to switch, it annoys me majorly every time I do it. Just starting the overlay UI seems to take 5 seconds.
I think HDMI EDID Emulator can be useful. For instance, https://smile.amazon.co.uk/gp/product/B095JXDM84/ref=ppx_yo_...
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.
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.
This delay also often happens when I switch between linux virtual consoles (Control+Alt+F7/F8), despite both of them using exactly the same X display settings.
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.
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.
I bought one of the first GSync monitors many years ago (ASUS PG278Q ROG Swift) and it goes from sleep to displaying an image in just a fraction of a second. It's totally amazing, way faster than any other monitor I've ever seen, including newer GSync monitors. It only has one single input port though. I've never tried hooking it to a KVM, but I bet it would switch super fast.
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.
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.
My native Gsync monitor, a now discontinued LG 32GK(?)650 is quite fast as well. I’ve complained a tiny amount about monitor reviewer blind spots, and this is one of them. The speed of every interaction on this monitor is very very fast. It is why I am very unwilling to let it go, even if it keeps me locked into the Nvidia side of things, since my monitor predates native Gsync modules that support DP Adaptive Sync and HDMI VRR.
You need a video matrix such as:
https://www.lindy.co.uk/audio-video-c2/matrix-switches-split...
https://www.lindy.co.uk/audio-video-c2/matrix-switches-split...
There are applications that seem to switch faster than using the OSD, like [0], however, they need an OS running to use.
0: https://codeberg.org/Okxa/qddcswitch
0: https://codeberg.org/Okxa/qddcswitch
> i.e. due power save mode
This is your problem, isn't it? I never use power save mode and have no problems with these delays.
This is your problem, isn't it? I never use power save mode and have no problems with these delays.
Gigabyte gaming monitors come with a physical kvm button:
https://www.gigabyte.com/Monitor/M32U
Thanks for sharing, I didn't know these even existed!
I appreciate this question, I would also appreciate a solution, and the explanation of why it happens is interesting.
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)
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)
In 5 years of getting support emails for Lunar (https://lunar.fyi/), LG monitors were the least mentioned of all. They seem to have the best DDC compatibility of all monitors.
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:
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;
Excellent, thank you!
I think Dell has pretty good support for this, I had a pretty old Dell model before my current monitor and ddc worked fine with it. I now have an AORUS FO48U and it also supports it. I'm not sure it's always listed as a feature though when you're buying a monitor so it might be tricky.
FYI, I originally learned about this stuff via https://haim.dev/posts/2020-07-28-dual-monitor-kvm/.
FYI, I originally learned about this stuff via https://haim.dev/posts/2020-07-28-dual-monitor-kvm/.
If you just need "switch using keyboard", not necessarily "switch using shell", some KVM switches allow input switching using keypresses. For mine, it's <SROLLLOCK> <SCROLLOCK> <1-4> <ENTER>, though I think that can be customized.
Well, what I actually want to do is switch via my DIY macropad. My keyboard switch goes through that, without relying on any of the main computers. I had a cheap HDMI switch that worked the same way, but it just stopped working reliably after a month.
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.
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.
Yeah would be nice to be able to alt-tab between monitors (or I should say: sources). I never understood why it is so slow. I have a somewhat older Samsung TV and I even have to cycle all the inputs (8?) to arrive a the correct one and it takes 1-3 sec on every input before I can get to the next. Absolutely maddening. But I guess manufacturers were too busy making 3D a thing and then "curved". Maybe they can now decide to fix some basics?
My old LG 27UD88 switches in about 1 second when pressing the relevant hotkey in Lunar (https://lunar.fyi/)
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.
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.
yeah I think also that with macbook the display is constantly sending video to the display (as there is no way to disable extenral displays).
Take a look at ConnectPro video emulators [1]. Mentioned [2] and praised [3] here on HN before, but there are limits on their KVM's [4] to watch out for so just a caution to don't hastily ascribe the same performance from their emulators to their KVM's if you're also messing around with switching configurations.
[1] https://connectpro.com/collections/video-emulators
[2] https://news.ycombinator.com/item?id=24362388
[3] https://news.ycombinator.com/item?id=24362975
[4] https://news.ycombinator.com/item?id=26906688
[1] https://connectpro.com/collections/video-emulators
[2] https://news.ycombinator.com/item?id=24362388
[3] https://news.ycombinator.com/item?id=24362975
[4] https://news.ycombinator.com/item?id=26906688
Unrelated: OP, how do you like the U2723QE? Been trying to decide on pulling the trigger on two of them recently.
I have one, it's a really nice monitor, sadly there is a small "but". Sometimes, it starts flickering. I'm not completely sure what causes it, but closing the nearest Eletron app will normally fix it.
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.
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.
I've got a U3223QE which is the same just larger. The screen itself looks really nice, its bright, no complaints there. The stand is pretty good, reasonably tidy. My only complaint is that when it said USB-C hub I expected it to have USB-C ports for peripherals and it doesn't, only USB-A ports. My older LG has USB-C ports, so I know its possible. It's annoying because as more and more stuff switches to USB-C the only place to plug those in is the laptop itself, which means messing around with too many cables.
Just in case you missed it, the U3223QE does have one USB-C port for peripherals. See [0], bottom right of the image.
[0] https://i.dell.com/is/image/DellContent/content/dam/ss2/prod...
[0] https://i.dell.com/is/image/DellContent/content/dam/ss2/prod...
That's the USB-C upstream port for if you connect PC-2 via HDMI and PC-1 is connected to the USB-C display port.
I meant further to the bottom-right. Here: https://imgur.com/00KDqpq
thanks! I had no idea that one was even there. That sorts out my headphones!
I have its older version U2720Q and I am quite content with it, in a multi-monitor setup under Linux, using 30 bit per pixel, and also including a Dell loudspeaker system connected to U2720Q, used for audio via DisplayPort or HDMI.
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.
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.
> The monitor is on a switched off source i.e. due power save mode
Do you want your cake, or you do want to eat it too?
Do you want your cake, or you do want to eat it too?
Tangentially related: I find many monitors that look great on paper are a real annoyance when it comes to controls, be it brightness/contrast or input switching, making those 4s irrelevant in comparison.
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.
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.
My Samsung monitor has a 4-way joystick control for navigating the menu. It's the worst physical monitor menu UX I've used. It's also on the back of the monitor, which makes it a pain to reach. When I bought it, I only had one input, so it didn't bother me.
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.
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.
If you can get HDMI from all your sources, something like this might work for 1080p: https://www.bhphotovideo.com/c/product/1507214-REG/blackmagi...
More options, like if you need higher res: https://www.bhphotovideo.com/c/buy/Live-Switcher/ci/2865
More options, like if you need higher res: https://www.bhphotovideo.com/c/buy/Live-Switcher/ci/2865
I like using KVM switches for connecting multiple sources - if you are using multiple laptops/PCs, it has the benefit that you can use the same keyboard/mouse for all of them.
Slow screens, they annoy me so much too!
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.
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.
If you're looking for a monitor with responsive software avoid the Gigabyte M28U like the plague.
Sure it's got 4k 144hz and when that works it's visually great.
However, monitor sleep/wake or any other funcitonaly such as switching inputs had been a nightmare to the point that the most effective way to switch inputs quickly is to turn it off and on.
At this point I'm really considering selling it for something with better software.
I'm spending anywhere from 10 to 30 seconds every time I want to turn my monitor on. It's a game of fiddling with the buttons, trying to get it to wake up faster.
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.
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.
You might be able to do that with a master computer running OBS in studio mode, an HDMI capture car for each source you want to connect, projecting the scene to your Monitor all the time and some hardware device with buttons to switch scene.
But this is kind of a hack and you would possibly have undesired latency, especially noticeable when typing fast and moving the mouse.
But this is kind of a hack and you would possibly have undesired latency, especially noticeable when typing fast and moving the mouse.
I was annoyed by this too. My solution was to buy a 49" samsung monitor and have either 50:50 or 1/3:2/3 split on the screen so I can see both at once. If I only want one active I can change the source but this has the flicker/delay as noted.
I run Barrier software on both to move one keyboard and mouse between the screens.
Doesn't this split incur some horrible scaling artefacts? Does it work well even
for text?
I have a similar function on my LCD monitor and its basically useless, it seems it throws away 50% of the pixels or something.
I have a similar function on my LCD monitor and its basically useless, it seems it throws away 50% of the pixels or something.
Can you link to the software? It’s a pretty common term but sounds interesting
It's the same as Synergy which is at https://symless.com/synergy
Unlike Synergy, Barrier is entirely open source.
I actually pay for Synergy hence the curiosity :)
Thank you kind stranger.
Thank you kind stranger.
I am using the setup from this blog as a software kvm solution and would love for it to be faster but it is manageable with my HP monitor.
Link: https://xpufx.com/posts/hundred-percent-software-kvm-switch/
Link: https://xpufx.com/posts/hundred-percent-software-kvm-switch/
I don't know the specifics of your monitor. But you say the source is in power-save mode? I think then it has also signaled to the monitor to enter power-save mode.
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 ;-)
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 ;-)
Maybe solving your problem in other ways:
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.
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.
Would you mind sharing what monitor you have? Mine "supports" DDC, but switching inputs from CLI doesn't work.
I have a Samsung S34J55x, and a DisplayPort 4 port KVM from Lindy. I have 3 laptops connected, all different makes (lenovo, dell, ms), and they generally take 1-2 sec to switch between machines. Maybe the key is the video interface eg HDMI vs DVI vs DP, be an interesting experiment.
I have an OLED monitor and between being completely black with no input, and taking a long time to switch inputs, I'm often not sure if it's actually turned on or not.
[deleted]
Maybe get a dedicated display for your devices or just get a huge 4K or 5k display with PIP mode or vnc/remote into the machines so that the switch is software based.
If I were you I'd use a hardware KVM device that goes to a single input source on the monitor and keep the monitor always-on with a black screen saver to prevent burn-in.
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/
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/
An external KVM switch might help but a lot of monitors suffer from this issue u fortunately and I don’t think anyone has benchmarked this
I'm using a pretty low level Displayport switch, and I think it also takes 4s to get a picture back.
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 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.
If you got the cash, get a Blackmagic Atem Mini video mixer and an appropriate amount of x-to-HDMI dongles.
I have a hand-me-down Atem Mini that "survived" many, many productions, and honestly I wouldn't recommend it - the internal fan noise is getting worse, and I wouldn't want it next to my setup.
I haven't tried it with a computer but I think mouse-to-screen latency would be a limiting factor.
I haven't tried it with a computer but I think mouse-to-screen latency would be a limiting factor.
I suspect there is a tiny CPU inside the monitor that looks at a variety of things before deciding how to decode the signal and present it. As @alin23 notes, DDC protocol is also handled. Obviously the manufacturers are using the lowest cost BOM that they can get away with and that would probably mean a $1 microprocessor in charge of the "smarts".
Even a $1 micro should be able to handle a few bits of resolution information in less than a millisecond. This can't be it.
There's a lot going through between your OS and the monitor when you plug a display, really. HDMI and DP are two-way protocols.
Expecting everything instant-on is naif.
Expecting everything instant-on is naif.
Then there must be something badly wrong with the protocol and/or implementations. Negotiating a few bits over a high-quality cable link should be instantaneous.
There could be, but there are (at least) three parties involved in whatever's causing the slow monitor response. I find it irritating even without a switch, just plugging in my external monitor should not take what seems like thirty seconds to actually turn on.
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.
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.
> 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.
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.
No, nothing like that exists, and no KVM exists that does instant switching.
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.
What's impossible about it? I've seen devices in the past that can combine multiple HDMI signals into a single image (like picture-in-picture, or making one high-res display out of several lower-res video connections). And if you can do that, surely you can do instant switching just by toggling between "full screen input 1" and "full screen input 2" layouts.
Were any of these devices monitors? Were they cheap? Like it or not, price is a major factor.
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.
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.
Also, if all your inputs are the same res(or even aspect ratio) and frame rate you avoid a gazillion edge cases
What are the hardware limitations? Surely this is possible if there was investment and interest in making this work? Or do the protocols really not allow this?
Most of the delay is I/O bound. Handshaking happens over the Display Data Channel (DDC) which is a protocol over I²C (a two-wire comunication bus). HDMI/DP/DVI have 2 dedicated wires inside the cable for this, USB-C has to switch over to use differential signaling on pins A8 and B8, and then switch back after communication is done.
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
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
Naively it seems like you could optimise this at least for the second and subsequent switches: you could detect if the cable corresponding to the input you've previously switched to has been reconnected since last switch. If it hasn't, then you could re-use the previous EDID values for the device.
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.
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.
I believe that is already being done. As I said in my comment here (https://news.ycombinator.com/item?id=34049171) switching between two active inputs takes about 1 second for me.
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)
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)
In theory you could have a monitor that handles both signals all the time, buffering the output. Then it could switch immediately.
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.
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.
Why would you buffer? Monitors are capable of playing full-screen video, which implies the ability to update every pixel once per... 30hz? frame, doesn't it?
Because when you want instant switching you need to already have the data you want to display available the moment someone flips the switch.
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.
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.
Okay, I'm willing to wait 1/30th of a second while the screen gets its pixels; is that not an option? Or is there no way to request all pixels and it doesn't send them all every frame?
I don't think I understand what you're saying.
I think you're concerned that because there's "buffers" there would be extra latency? There doesn't have to be.
I think you're concerned that because there's "buffers" there would be extra latency? There doesn't have to be.
That's what I'm asking. When the monitor is live, it can draw a complete screen ~30+ times every second, so why does it take more than 1/30th of a second to start from nothing? Then, I speculated that the only reason I could think of was if the graphics card doesn't actually send every pixel every frame, and there's no way for the monitor to request a full refresh.
Monitors don’t request anything. The monitor has to do a basic handshaking/negotiation before it even knows what sort of video stream to expect
Ah. And we couldn't stick... What, 4 ints of metadata in the video steam (width, height, depth, frame rate)? Not like we don't have the bandwidth. I can believe that, but it's disappointing that nobody bothered.
Historically speaking bad things happen when you hand a display something it can’t handle - including not being able to see the settings dialog to fix it.
It’s ok, I can wait 17ms for the next frame.
With basic analog you could set it up in a way where you would just wait for the next frame (or don't even wait that long), but with the new digital stuff there's bootstrapping/handshaking - whatever you want to call it. It's not so simple anymore.
What could they possibly be doing that takes 4 seconds? That's ~4,000,000,000 instructions on a typical embedded processor.
It's much more likely that the handshaking was implemented by an incompetent organization that doesn't care about quality.
It's much more likely that the handshaking was implemented by an incompetent organization that doesn't care about quality.
It is extremely odd to see so many people in this thread ignore that a handshake requires billions of instructions to be executed for some reason....
One of the grandparents of this comment thread explicitly ignored it; this is a discussion on frame buffering.
Quite a few monitors support a Picture-in-Picture mode, so they are able to receive and decode two signals at the same time. But if that mode isn't enabled, they only receive one signal.
> But you probably don't.
What does this statement add, beyond conveying that you don't personally care what the OP wants?
What does this statement add, beyond conveying that you don't personally care what the OP wants?
There are multiple input (5xHDMI) same output (1x HDMI) switches on the net, which feeds one input of the monitor and you can change the source on the adapter with a round robin button. It's almost instant. Another cool feature is whenever a new input source is detected it automatically feeds that to your monitor. I haven't seen the configuration you need, but if you can use adapters to convert each source to HDMI, it works like a charm. It's called an HDMI switch.
switching between 2 inputs would take between 1x and 4x (x being the time to switch to the next input) depending if it is from A to B or B to A.
Even the cheap HDMI switches all come with a remote so you can jump from input 2 back to 1.
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.