I woke up and decided this morning that I would figure out how to use my ThinkPad X1 Yoga as a KVM (keyboard, mouse and video) for my Framework Desktop.

The reasoning behind this is simple– the Framework Desktop is quite small and packs quite a punch within its volume. I figured if there was ever a reason I needed an extreme excess of computing performance on the go, say, for a LAN party, I could use a laptop that was already in my bag as the display and input device.

Sadly this did not work out, and given that I time boxed this to one day I don’t have any interest in pursuing it further. I’m mostly posting this to see if anyone smarter than me out there knows what my problem is.

The Plan

So the idea was that Thunderbolt supports a peer to peer network connection, which means that I would only need one small cable to both charge the laptop and provide more than enough networking bandwidth for a fully uncompressed 1080p video stream.

Because I have not subjected myself to this technology enough times.

This went about as well as I could have expected.

A USB-C to USB-C cable connected to the Desktop and to the Yoga yielded no connection at all. Nothing. Nada. Zip. Nothing in journalctl at all. No logs. No indication that nothing had happened.

So I tried a few other connections. Between my Framework Laptop (Ryzen 7040) and the Yoga? Working network. Between my Framework Laptop and my Framework Desktop? Working network.

Framework Desktop to a ThinkPad Thunderbolt Dock, with a Thunderbolt daisy-chain out to the Yoga? That yielded a working network, because of course it did. I guess an intermediary is enough to beat some sense into this thing. Of course this is pointless when the idea is to pack a small bag with no extras; it’s a big, heavy dock. If I wanted to pack that I might as well pack a good USB-C to Ethernet adapter and a fairly bulky Ethernet cord.

Virtual Display?

The idea is to use the network to stream the display. Sunshine will be our host for this, and we’ll use Moonlight on the client side. Sunshine does not support automatically creating virtual displays on Linux, so we will have to do it ourselves.

Some people use an HDMI Dummy Plug– a small trinket that advertises various available resolutions and refresh rates to a “display” that doesn’t actually exist, in order to inform the graphics card that it should be outputting to a display. I was worried about losing this, or worse yet, having it damage the port on a computer that is continuing to appreciate at a constant rate (at the time of writing the computer is worth $3000).

There’s a theoretically better solution. You can just take an unused port on your machine and force the amdgpu kernel driver to have that port “connected” to an EDID file that represents a display. Here’s the best post I found on how to make that happen.

Strix Halo advertises a lot of ports, but doesn’t seem to use most of them:

qwe@strength:~$ for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done
DP-10: disconnected
DP-11: connected
DP-1: disconnected
DP-2: disconnected
DP-3: disconnected
DP-4: disconnected
DP-5: disconnected
DP-6: disconnected
DP-7: disconnected
DP-8: disconnected
DP-9: disconnected
HDMI-A-1: disconnected
Writeback-1: unknown

So I just assigned the virtual display to DP-8.

This created some problems, but I’ll detour for a moment to explain what did work.

A Success Story

The Steam Deck does not support Thunderbolt, but it does support acting as a USB device. There’s a script floating around the internet that will take advantage of that functionality to advertise it as a USB Ethernet gadget. This works! I even tried using it earlier this year to serve my games to my Desktop in order to avoid duplicating space. (This also works, and isn’t TOO slow, but is somewhat silly. Just mount your games directory with SFTP and sshfs.)

This network came up just fine! And with Moonlight on the Deck, and the EDID perfectly matching the Steam Decks display, I was able to get a fully peer to peer network stream going!

But Not Really

See, the problem with that is that it was working in a Wayland session.

I have to use X11, due to some accessibility software that does not, and likely never will, work on Wayland. (A separate article on this will come out whenever I get around to it.) Of course, X11 is an ancient decrepit mess, and I’m trying to use it on 2025 hardware. Even so, it’s surprising that Xorg completely refuses to start with the virtual display connected.

It breaks so hard, it doesn’t even write to /var/log/Xorg.0.log! The session exits immediately. When starting a session from the login manager (SDDM), I get a permanent black screen with no opportunity to switch to a TTY. When calling startx from a TTY, the session simply exits after a few seconds with no errors printed to the console.

Why? I have no idea. The internet has no references to this kind of issue, or at least ones that I could find. I guess everyone trying to do this is just using Wayland these days? It’s a real shame I’m left behind.

Lessons Learned?

IDK. ¯\_(ツ)_/¯

Maybe that I’m not smart enough to debug these kinds of weird ass issues? Maybe that I’m smart enough to know not to?

If someone out there has an inkling of what’s wrong, please reach out! My email address is in the “about” page.