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.
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.
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.
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.
Deskhop has been a lifesaver https://github.com/hrvach/deskhop
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.
Level1Techs are the best but also cost double or triple.
> 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.
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.
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.
Personally I just run the USB devices into a $5 USB A/B switch and manually change the inputs on the monitor.
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...
I guess everything old is new again?
I’ve got a Mac laptop and Linux desktop, and use the same keyboard, mouse, and monitor for both. If you also work from home, I’m sure you can relate… laptop for work, desktop for hobby… but only one monitor and peripherals.
Switching between the two machines has always been a pain. It requires either fiddling around with plugging and unplugging cables at the back of the monitor, using flaky USB-C switches, or annoying dongles.
With a recent upgrade of my monitor I wanted to solve this problem for good; I wanted to be able to switch between the two machines very quickly, without any fiddling. In fact, even lifting my hands off the keyboard would be considered failure.
Well, I’ve done it. Behold:
Your browser does not support the video tag.
A couple of things have made this possible:
Let’s go into these one by one…
I won’t bury the lede. It’s the MSI MPG 321URX (affiliate link). The main draw of this thing is its absolutely beautiful QLED panel that runs 4K at 240 Hz. Good for programming, good for gaming.
(A newer version of this monitor is out now — what I’m describing should work the same for it too).
Other manufacturers like Samsung and Alienware also ship monitors with the same gorgeous panel, but the MSI is cheaper. I also appreciate that it relegates its gamer aesthetics to the back of the monitor, where only my wall has to see them. Sorry wall.
I use two inputs on the monitor:
For plugging in peripherals, the monitor’s also got a couple of USB ports, and a 3.5 mm audio jack. I use a USB hub to one of the ports to increase the number of available ports:
In reality the back of my monitor is a lot messier than the straight lines in that diagram would have you believe, but it’s only my wall that gets to see that. Sorry again wall.
The thing that makes this setup work so well is the monitor’s built-in KVM feature, which lets data from the USB ports follow the active input. So when I’m using my laptop via USB-C, the monitor’s built-in USB hub flows through USB-C, but when I’m on my desktop via DisplayPort, the USB hub goes through the USB-A connection to my desktop.
To switch between the two inputs I could reach over and fiddle with the monitor’s controls, but like I said… moving hands away from the keyboard is failure, and we won’t stand for that!
Enter DDC — which can be used to send instructions to a modern monitor via its display cable (HDMI, USB-C, DisplayPort). We can use this to tell the monitor to do things like change volume, adjust brightness and contrast, and crucially for me, change to a specified input. Without ever touching it!
Command line programs let you send commands across DDC to your monitor, and depending on your OS, different shims can be used to bind those to a keyboard shortcut.
On macOS with a machine running Apple Silicon we can send monitor DDC signals with m1ddc. If you’re running an Intel chip there are alternatives.
Here are some example commands you can run:
brew install m1ddc # install the thing
m1ddc display list # list your connected monitors
m1ddc display <id_from_prev_command> chg volume 100 # change volume
m1ddc display <id_from_prev_command> set input <input_to_switch_to> # switch inputs
m1ddc’s README contains a list of input codes. In my case, DisplayPort is input code 15 and my monitor’s ID is 381C72C8-0CDA-4B71-A1CD-F8AFE90AB0ED, so this incantation switches to DisplayPort:
m1ddc display 381C72C8-0CDA-4B71-A1CD-F8AFE90AB0ED set input 15
With the m1ddc command ready to go, I use Hammerspoon to bind it to CTRL + SHIFT + =:
-- Somewhere in ~/.hammerspoon/init.lua
-- Sends a DDC code to my MSI MPG 321URX that will switch to DisplayPort input.
hs.hotkey.bind({ "ctrl", "shift" }, "=", function()
local display_id = "" -- figure this out by running 'm1ddc display list'
local displayport_code = "15" -- input codes listed on m1ddc's readme
local command = "/opt/homebrew/bin/m1ddc display " .. display_id .. " set input " .. displayport_code
hs.execute(command)
end)
Then, on the Linux end I bind the same keyboard shortcut to switch back to USB-C:
On Linux I’ve had luck with using ddcutil for controlling the monitor.
sudo pacman -Suy ddcutil # install with your package manager
ddcutil detect # list monitors connected to your machine
ddcutil is not as user friendly as m1ddc. You’ll have to figure out the code of the setting you want to modify (e.g. input, volume, brightness) and then set the value accordingly. Luckily ddcutil makes these easy to discover. So, in my case:
ddcutil capabilities
...
Feature: 60 (Input Source)
Values:
11: HDMI-1
12: HDMI-2
0f: DisplayPort-1
10: DisplayPort-2
...
The “input” setting is Feature 60, so that’s what we need to modify to change inputs. As for the value, a bunch of options are listed but no USB-C! The monitor only has two HDMI ports, one DisplayPort, and one USB-C port, so by process of deduction we can assume the second “DisplayPort” there is actually the USB-C port. It likely identifies as DisplayPort because USB-C is running in DisplayPort Alt Mode.
So with that figured out, the command we can run to change input to USB-C is:
ddcutil setvcp 0x60 0x10
Unlike with m1ddc, I haven’t bothered specifying which display to run it on, since I only have one display connected to my desktop (whereas the laptop also has its own built-in display). If you use multiple screens, you’ll have to adapt these commands accordingly.
Since I use the KDE desktop, the easiest way to bind the CTRL + SHIFT + = shortcut there is via the built-in shortcuts manager:

Simple! Push the keys: run ddcutil!
You can also configure this on Windows. I haven’t tried it myself, but the Windows program MSI ships for controlling the monitor seems to let you assign actions to keyboard shortcuts… so you might be able to get it to change inputs without even having to invoke a separate CLI program!
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.
Thanks for reading! DDC you later.