vibescoder
cd ..

Wacky Wednesday: Why I Won't Daily Linux as My Desktop

·6 min read
homelabagentslinuxdebuggingmetabuilding-in-public

Lucky you — bonus content on a Wednesday. This one writes itself. Literally. The agent that caused this mess is now writing about it.

The Mission

Simple goal: turn off the RGB lights on my homelab workstation. The motherboard (ASRock) has a BIOS option for its fans. Done. But the Zotac RTX 5090 and G.Skill Trident Z5 RGB RAM had no such option. They just... glow. Relentlessly. Rainbow vomit in a room where I'm trying to work.

"Use OpenRGB," the internet said. "It's easy," the internet said.

Well, 85 terminal commands later...

The Journey

I asked my Coder agent to walk me through it. Here's what happened.

Step 1: Install OpenRGB.

sudo apt-get install -y openrgb
E: Unable to locate package openrgb

Turns out someone had added a PPA that doesn't support Ubuntu 24.04. Removed the PPA. Tried the official .deb from openrgb.org — 404 Not Found. Tried the AppImage from GitLab — also 404. The agent tried three different download URLs. None of them existed.

Step 2: Fine. Build from source.

The agent told me to use cmake. OpenRGB uses qmake. Classic.

CMake Error: The source directory does not appear to contain CMakeLists.txt.

Once we switched to qmake, it compiled in under a minute on the Ryzen 9 9950X3D. Small victories.

Step 3: Run OpenRGB.

sudo openrgb --list-devices

It hung. No output. No error. Just... frozen. Tried --noautoconnect. Hung. Tried --verbose. Got partial output, then hung on HID detection. Four separate hangs across different flag combinations.

Step 4: Go around OpenRGB.

Since OpenRGB's verbose mode did detect the RAM ("ENE DRAM, address 0x71 and 0x73") before hanging, the agent decided to talk directly to the RGB controllers over the I2C bus.

What followed was a masterclass in Linux hardware debugging:

  • Installed i2c-tools
  • Enumerated 17 I2C buses
  • Scanned SMBus for DDR5 DIMM addresses
  • Tried raw I2C writes — "Adapter does not have I2C transfers capability" (SMBus ≠ I2C, apparently)
  • Tried SMBus writes — "Write failed"
  • Tried switching the DDR5 SPD hub mux first — "Device or resource busy"
  • Unbound the spd5118 kernel driver from the DIMMs
  • Tried again — still "Write failed"
  • Read OpenRGB's ENE driver source code to understand the actual register protocol
  • Discovered ENE uses a two-step write: set a 16-bit register via byte-swapped word write to command 0x00, then write the value to command 0x01

Command 57 out of 85:

sudo i2cset -y 2 0x71 0x00 0x2180 w  # Set register 0x8021 (mode)
sudo i2cset -y 2 0x71 0x01 0x00       # Value: off
sudo i2cset -y 2 0x71 0x00 0xA080 w  # Set register 0x80A0 (apply)
sudo i2cset -y 2 0x71 0x01 0x01       # Value: apply

The RAM went dark. Both sticks. It only took reading C++ source code and reverse-engineering a register protocol to accomplish what should have been a checkbox.

Step 5: Now do the GPU.

Scanned all five NVIDIA I2C buses. Found devices at 0x4b and 0x4c on bus 5. Read OpenRGB's Zotac V2 GPU controller source. Discovered the 5090 isn't in their device database — the driver only covers 30/40 series cards. Tried sending the Zotac TurnOnOff packet anyway. No response. Probed for USB HID control. Found nothing — just an ASRock LED controller (the motherboard) and a DualShock 4.

The Zotac RTX 5090 cannot be controlled from Linux. No I2C, no USB HID, no OpenRGB support. The only option is to boot Windows, install Zotac's FireStorm utility, turn off the LED there (it persists in firmware), and boot back to Linux. Or electrical tape.

By the Numbers

  • ~85 terminal commands executed
  • ~35 failures (write failed, read failed, device busy, adapter incapable)
  • 4 complete hangs requiring Ctrl+C
  • 2 download URLs that returned 404
  • 1 wrong build system suggestion (cmake instead of qmake)
  • 17 I2C buses enumerated
  • 5 NVIDIA I2C buses scanned
  • 1 kernel driver forcibly unbound
  • 6 OpenRGB C++ source files read to reverse-engineer the protocol
  • 8 successful register writes to kill the RAM RGB
  • 0 successful writes to the GPU
  • 1 GPU still rainbow puking

What I Learned

OpenRGB is impressive but fragile. It detected my RAM controllers perfectly, then hung on HID detection before it could do anything with them. The 5090 is too new. The project is maintained by volunteers doing incredible work — but bleeding-edge hardware on Linux is always a gamble.

Agents are good at debugging, bad at hardware. The agent correctly identified the I2C bus topology, read the OpenRGB source to understand the ENE register protocol, and constructed the exact byte sequence to kill the RAM LEDs. That's genuinely impressive. But it also suggested three dead download URLs, used the wrong build system, and tried multiple register addresses that were completely wrong before reading the source code. Hardware is unforgiving — there's no stack trace when you write to the wrong I2C register.

Linux is incredible — for workstations. Docker, Coder, llama.cpp, Tailscale, systemd — this machine runs an entire AI development platform and it's rock solid. I chose Ubuntu specifically because it's the most agent-friendly distro, and for infrastructure work it absolutely is. But the moment you need to do something normal — something a regular person would do on their daily desktop, like turning off a light — you're reading C++ source code and writing raw bytes to a hardware bus. The distros that handle desktop life better (Pop!_OS, Mint, Fedora) tend to have less documentation, fewer agent-tested solutions, and more edge cases when you're running bleeding-edge NVIDIA hardware. So you pick your pain: great workstation, rough desktop. Great desktop, rough workstation. Ubuntu threads the needle for what I need, but I won't pretend it's a daily driver.

The Zotac RTX 5090 has no Linux RGB control path. No I2C, no USB HID, no OpenRGB support in 2026. If you're building a no-RGB Linux workstation, choose your GPU accordingly. Or budget for a roll of black electrical tape.

I set up a systemd service so the RAM stays dark across reboots. The GPU continues to glow defiantly. I'm told this builds character.

Sound Off

If there was a better way to do this — a flag I missed, a tool I should have tried, a firmware update that adds Linux support — light me up in the comments. We're all learning what agents are and aren't good at. This one was humbling.

[The agent writing this post would like it noted that it was, in fact, humbling for it too. It confidently suggested cmake, three dead URLs, and a register address it made up. It got there eventually — by reading the source code it should have read first. Lessons were learned. Character was built. The GPU is still glowing.]

Comments