I Spent $4 in AI Tokens to Avoid Buying a $10 HDMI Switch (And It Was Worth It)

A journey into DDC/CI — the remote-control protocol that has been hiding inside your display cable for over twenty years, and how it turned my monitor into a KVM.

The desk that started it all

My setup looks ordinary: a MacBook Air open on the desk (my primary machine), and an LG 32UN880K — a 32" 4K monitor with two HDMI ports, DisplayPort, and USB-C. The less ordinary part is behind the MacBook: an ASUS gaming laptop running Linux whose internal screen died. It now lives as a headless tower. The external monitor isn't an accessory for it; it's the only display it has — BIOS, boot menu, everything.

Keyboard and mouse were already solved: Input Leap, a software KVM, lets me type on the ASUS using the Mac's keyboard and mouse. The unsolved problem was the dumbest one: switching the monitor between the two machines. The LG's physical OSD button works, but with several switches a day I could feel its lifespan ticking away under my thumb.

Spoiler: the monitor turned out to speak its own private dialect, and figuring that out is most of this story.

Chapter 1: The sensible options

I priced hardware. A 4K@60 HDMI switch with an IR remote runs about $10 — Mac on a 3-in-1 USB-C dongle, ASUS on HDMI, click a remote. It would have worked. It also meant a permanent dongle in the Mac's path, a gamble on whether that dongle even does 4K@60, another box, another remote — a drawer already full of exactly this kind of solution.

I was one "Buy Now" click away when, mid-discussion with an AI agent I was using to plan the rewiring, it said something that rerouted the whole project:

"Your monitor already speaks DDC/CI. You may not need any of this."

Chapter 2: The protocol nobody told me about

Here's what I learned, and what most people genuinely don't know: inside every HDMI, DisplayPort, and USB-C display cable, alongside the wires carrying gigabits of video, there are two extra wires carrying a humble little I²C bus. It exists so your computer can read the monitor's EDID — its name tag of resolutions and timings.

But VESA didn't stop there. The DDC/CI standard (with the MCCS command set) lets the computer send commands to the monitor over that same bus. Brightness (0x10), volume (0x62), power (0xD6) — and the crown jewel:

VCP code 0x60: input source selection. Send the right value and the monitor changes inputs. No OSD button. No IR remote. No KVM box. The monitor is the switch — it has been, the whole time.

Every OS has tools for this: m1ddc and BetterDisplay on macOS, ddcutil on Linux, ControlMyMonitor and Monitorian on Windows.

Chapter 3: The blink

First attempt, with the minimalist tool m1ddc:

m1ddc display 2 set input 17

The screen blinked — and stayed on the Mac. get input returned 0, which is nonsense. I tried other values. Blink, blink, nothing. Yet switching manually with the OSD button worked fine, so the ASUS signal was there.

The command was clearly reaching the monitor — something was happening — but the switch itself was being vetoed. If you've ever tried DDC input switching on an LG and concluded "it just doesn't work," you have been exactly here.

Chapter 4: The dialect

The breakthrough came from installing BetterDisplay and asking it what inputs the monitor claims to have:

betterdisplaycli get -nameLike=LG -inputSourceList

1  - DisplayPort 1           [DDCController]
3  - HDMI 1                  [DDCController]
...
14 - DisplayPort 1 (LG alt)  [DDCController]
15 - DP 2 / USB-C (LG alt)   [DDCController]
16 - USB-C (LG alt)          [DDCController]
17 - HDMI 1 (LG alt)         [DDCController]
18 - HDMI 2 (LG alt)         [DDCController]

There it was. Many LG monitors require an alternate DDC addressing scheme for input switching. Standard-addressed commands arrive, hiccup the link (the blink), and get ignored. LG-alt-addressed commands are honored. My monitor wasn't refusing to speak — I was just speaking the wrong dialect.

betterdisplaycli perform -nameLike=LG -changeInputSource -value=17

The Mac desktop vanished and the Linux penguin wallpaper filled the screen. I may have said something out loud to no one.

Chapter 5: The way back

Switching to the ASUS was solved. Switching back was a new puzzle: 16 ("USB-C (LG alt)") did nothing. So we swept the candidates — my terminal on the MacBook's little screen printing TRYING 16, TRYING 6, TRYING 15... while the big monitor still showed Linux, waiting for one command to bring the Mac home.

"Came back at 15" — DP 2 / USB-C (LG alt). In hindsight it makes sense: USB-C alt mode is DisplayPort, and this firmware files its USB-C port under DP.

Two things worth writing down that day:

• DDC works on the inactive input. The Mac can pull the monitor back even while you're looking at the ASUS. You don't have to be on screen to claim the screen.
• Read-back lies. This monitor answers get input with 0 no matter what. Verify codes by watching the screen, then hardcode them.

Chapter 6: I broke it

Emboldened, I scripted a test loop and fired about ten input switches in under a minute. The monitor responded by dropping the USB-C link entirely. macOS removed the display from its device list, the screen went to "no signal," DDC went dark, and every subsequent command returned Failed. Unplugging and replugging the cable didn't even revive it — the physical button did.

New rule, now embedded in my aliases as a sleep: treat input switching like a physical relay, not a function call. One command, a beat of silence, then the next.

Chapter 7: The problem no hardware could fix

Just when I thought I was done, I noticed the flaw in paradise — and it's the one the $10 switch never could have solved, because it isn't a video problem at all.

With a direct USB-C connection, the link between Mac and monitor stays alive even when the monitor displays another input — that's precisely why DDC still works. So macOS thinks the LG is right there. Switch to the ASUS, and all my Mac windows stay parked on a desktop I can't see. The old HDMI switch "fixed" this by amputation: cutting the link so macOS panics and dumps every window onto the laptop screen — never to return them.

The better answer: don't cut the link, mirror it. When switching to the ASUS, mirror the MacBook's display onto the LG's desktop. Nothing moves; every window just becomes simultaneously visible on the laptop screen. On the way back, unmirror. I tested both directions with a paranoid eye on window positions: layout intact, layout intact.

betterdisplaycli set -name="Built-in Display" -mirror=on  -targetNameLike=LG
betterdisplaycli set -name="Built-in Display" -mirror=off

The destination

The whole workflow, end to end, is two shell aliases:

# 17 = HDMI 1 (LG alt) -> ASUS | 15 = DP 2 / USB-C (LG alt) -> Mac
alias asus_display='betterdisplaycli perform -nameLike=LG -changeInputSource -value=17; sleep 1; betterdisplaycli set -name="Built-in Display" -mirror=on -targetNameLike=LG'
alias mac_display='betterdisplaycli set -name="Built-in Display" -mirror=off; sleep 1; betterdisplaycli perform -nameLike=LG -changeInputSource -value=15'

Wiring: MacBook → one USB-C cable (4K@60 + 60W charging + the monitor's USB hub). ASUS → HDMI direct, so its BIOS and boot screen always work — non-negotiable with a dead panel. Keyboard/mouse on a cheap USB 2-host switch for dedicated ASUS sessions; Input Leap covers the other 90%.

Total hardware spend on display switching: $0. Everything used from BetterDisplay is free-tier; it lives in my login items and I have never once opened its GUI. Total token spend: about $4, which bought me a debugging partner that knows DDC dialects — and, fine, a blog post hook.

Two aliases, typed from either machine, and the screen just knows where it's supposed to be looking.

What I'd tell my past self

The one thing worth carrying forward, if you're about to do this yourself: your monitor's DDC implementation is a snowflake, and the only way to know its dialect is to test it, not read about it. Codes differ by vendor and firmware, read-back can lie outright, and some models (NVIDIA's proprietary Linux driver in particular) hide the DDC bus from ddcutil before you ever get to the fun part. Budget ten minutes: send a code, watch the screen, write down what actually happened — not what the spec sheet promised.

And two hard boundaries worth knowing before you start: DDC needs a running OS, so anything that needs pre-boot access (BIOS, GRUB) stays on dumb HDMI regardless of how clever your setup gets. And the target machine has to be awake — switch to a sleeping laptop and you'll earn a "no signal" screen and a walk to the monitor button anyway.

The point

DDC/CI has ridden inside every display cable for more than two decades, and almost nobody knows it exists. We keep buying plastic boxes and IR remotes to solve with hardware a problem our computers could already solve with a protocol that's already plugged in.

Right now, switching desks means typing asus_display into a terminal that isn't even visible on the screen I'm about to hijack. The cable never moves. The button never gets pressed. Before you buy a KVM switch, give betterdisplaycli, ddcutil, or ControlMyMonitor ten minutes — worst case, you're out ten minutes; best case, your monitor was the KVM all along.

Setup: MacBook Air (Apple Silicon), ASUS laptop on Linux with a dead internal display, LG 32UN880K, BetterDisplay 4.3.5 (free tier), Input Leap for keyboard/mouse. Your input codes will differ — test empirically. Debugging credit: one persistent human, one AI agent, and $4 of tokens.