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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Because I have not subjected myself to this technology<\/a> enough times.<\/a><\/p>\n\n\n\n This went about as well as I could have expected.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The idea is to use the network to stream the display. Sunshine<\/a> 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.<\/p>\n\n\n\n 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<\/em> 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<\/a> at a constant rate (at the time of writing the computer is worth $3000). <\/p>\n\n\n\n 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<\/a> on how to make that happen.<\/p>\n\n\n\n Strix Halo advertises a lot of ports, but doesn’t seem to use most of them:<\/p>\n\n\n\n So I just assigned the virtual display to DP-8. <\/p>\n\n\n\n This created some problems, but I’ll detour for a moment to explain what did work.<\/p>\n\n\n\nVirtual Display?<\/h2>\n\n\n\n
qwe@strength:~$ for p in \/sys\/class\/drm\/*\/status; do con=${p%\/status}; echo -n \"${con#*\/card?-}: \"; cat $p; done\nDP-10: disconnected\nDP-11: connected\nDP-1: disconnected\nDP-2: disconnected\nDP-3: disconnected\nDP-4: disconnected\nDP-5: disconnected\nDP-6: disconnected\nDP-7: disconnected\nDP-8: disconnected\nDP-9: disconnected\nHDMI-A-1: disconnected\nWriteback-1: unknown<\/code><\/pre>\n\n\n\nA Success Story<\/h2>\n\n\n\n