It handles all the switching at the hardware level and thus has no perceptible lag for video or anything else. I'm able to connect a single set of peripherals, in my case, two monitors, a keyboard, a trackball, and a USB audio interface, to both my Linux desktop and a CalDigit Thunderbolt dock connected to my laptop. The L1T KVM has hotkeys[2] that let me switch between systems, with only a 1–2 second delay.
The benefit, for me, of this extra box now mounted under my desk is that when I upgrade my monitor, I only care about how good a display it is, not whether there's some perfect confluence of KVM, refresh rate, aspect ratio, display technology, etc. I find the monitor I want and let a separate IO routing layer.
--
[1]: https://www.store.level1techs.com/products/p/14-kvm-switch-d...
[2]: https://forum.level1techs.com/t/official-l1techs-kvm-faq-ult...
One connects with Thunderbolt only. The other connects with Display Port for video and USB-C for the rest of the built-in dock.
It's OK most of the time with the nipple switch. My one piece of advice is *avoid HDMI*. I learned after getting this monitor that the HDMI protocol is a petulant unstable little shit that does not tolerate renegotiation well. Get yourself a USB-C to DisplayPort cable.
I use Synergy as part of my desk setup already, but needed a way to view the UI of a normally headless machine. The solution I built was a small shell script that terminated the active Synergy session and started a new one with a different config file (so keyboard/mouse input would map to the normally-headless machine), and fired off a DCC command to the monitor to change its input. The same script ran with a different argument would switch back to the normal display/control configuration. This solution worked pretty well until I was able to retire the headless machine early this year.
I have a Dell U4323QE in the office and look forward to trying this out. I wondered if it was the same DDC commands so I googled a little and found this gist (concerning DDM):
https://gist.github.com/nebriv/cb934a3b702346c5988f2aba5ee39...
Which has the very useful comment:
https://gist.github.com/nebriv/cb934a3b702346c5988f2aba5ee39...
Which states:
#define LUMINANCE 0x10 #define CONTRAST 0x12 #define VOLUME 0x62 #define MUTE 0x8D #define PBP 0xE9 #define SWAP_USB 0xE7 #define SWAP_INPUT 0xE5 #define INPUT 0x60 #define SUB_INPUT 0xE8 #define INPUT_ALT 0xF4 // alternate address, used for LG exclusively? #define STANDBY 0xD6
I much prefer simple DDC commands over using something like Synergy or Barrier. I think it is a much cleaner solution.
Deskhop has been a lifesaver https://github.com/hrvach/deskhop
It does tend to be finicky - sometimes it just refuses to connect, and won't tell me why, and sometimes it'll forget the arrangement. And it requires you to be signed into one account on two machines, which some people may not want to do on corporate laptops.
The monitor is fantastic though. I’ve had no issues yet, knock on wood.
Thus I have 2 computers and 3 displays, and I can do sentences like "displays 13", which uses only displays 1 and 3 and sends ssh-command "displays 2" to the other computer.
You can add this .ahk script to run at startup:
^F4::
Run C:\Users\YourNameHere\Documents\AutoHotkey\ControlMyMonitor /SwitchValue Primary 60 17 3
Return
Where the file path is where you've put ControlMyMonitor.exe, "Primary" means the main Windows display, the "60" means input select, and the "17" and "3" are the values you observe in ControlMyMonitor when each display you want to switch between is enabled.You can now press Ctrl+F4 to toggle inputs.
If someone wants to know I have an MSI MPG 491C QD-OLED.
I tried very unsuccessfully to do something with DDC/CI when the KVM would switch between systems. The idea being when the OS detect the presence of the keyboard/mouse because the KVM had switched to them they'd send a change source command but DDC/CI is such a disaster in terms of support.
We need someone like Framework to make a "monitor for hackers" that actually has robust, well documented, DDC/CI support and I'd be all over it.
No, no, no. They need to modify their laptops so I can use the laptop's monitor and keyboard with e.g. a RPi without networking. Using the laptop IO for headless computers flipping a switch, or better ad-hoc streaming into some virtual environment would be such a win!
> And there you have it. A KVM solution that doesn’t require an external KVM device to pass inputs through, and a switch that can be triggered using a keyboard alone.
It's supported by the relatively old HDMI 2.1/DisplayPort 1.4 standards - it shouldn't be that hard to find a KVM that can do this.
IME even high-end KVM switches experience occasional signal interruption or, more often, failure to synchronize at all on output switch.
Do what OP did.
I'll pursue this when "they" decide to get real and make this not suck. Until then, I have sufficient alternatives.
I appreciate the writeup. It convinces me that integrated KVM stuff ~~ except for fewer wires ~~ isn't much better than the mess that's prevailed for years now, and I'm not missing much.
Why does video input source switching suck so much?
Back in the old analog CRT days I could forgive the switching latency. With today's all-digital signal paths I feel like video input switching should be pretty close to instant.
Is the technology in a broadcast switcher really so exotic and expensive?
No. My characterization of the problem was precision flippancy; the demand for this is niche enough that optimizing for it is a low priority, so "they" simply don't. That failure is stack-wide; the specifications around display negotiation would need extension to manage the additional state necessary for the "agile" KVM use case, and then the hardware+firmware would need to exist and become cheap, somehow despite Imaginary Property laws, so that one could hope to find it in real products.
There is regulatory friction here as well: it would complicate power management. Not infeasibly so, but enough that unless a need appears of such import that it motivates people to dare to disturb that writhing ball of copulating tapeworms, it simply won't happen.
So don't hold your breath. Unless you're relatively young, you won't live to see it. More likely, some other paradigm will obviate the problem first.
I guess everything old is new again?
This would be easy to set up the other way around, too: having a gaming rig on your desk with Moonlight, and running Linux on another machine somewhere in the network with Apollo to host the development setup.
No KVM (or KVM-equipped monitor) or other special hardware needed.
Also, OT but I have the same keyboard as OP and love it :) I want to hack a TouchID key from the Magic Keyboard I bought into the chassis. But it can't traverse the Screen Sharing hack, so I do still think about this from time to time.
I wish a KVM switch was a standard component of normal priced monitors these days. Especially one that also routed through all your peripherals, speakers, and everything.
The monitor with the specs I wanted was $201[2]
Lower prices are always nice. But such things can be found at reasonable prices. I think awareness is a larger problem.
I am happy enough with the built-in speakers. But I do agree that line level aux out on the back would be nice.
I just have the monitors auto-switch on (lack of) input when I put one machine to sleep. The single click buttons on the monitor also switch.
I do worry that would just add more trouble / race conditions / issues around this stuff. I feel like nvidia + linux + monitors doing anything other than staying on + attached all the time causes some headaches.
m1ddc works fine on my Mac, but why isn't there a single multiplatform cli tool that can be ran on Mac/Linux/Windows?
I need a Windows one for this to be useful for me.
Level1Techs are the best but also cost double or triple.
I agree that the industry hates its consumers and likes to mess things up. CEC never always quite the same. Not supported on many GPUs etc.
I do not want to appear to condone LG. But actually (sorry!) some supoort[0] it using DDC side channels (0x50 rather that 0x51). But I agree it is painful. Yet I prefer it over my cable spaghetti.
[0] https://github.com/rockowitz/ddcutil/wiki/Switching-input-so...
Personally I just run the USB devices into a $5 USB A/B switch and manually change the inputs on the monitor.