Two Hours of NixOS Config I Didn't Need

Docks are basically plug-and-play, right? So if the monitor isn’t working, there must be a setting that’s off somewhere. This will be easy.

(narrator voice: it would not, in fact, be easy)

The hardware path is simple: ThinkPad T14 Gen1 (Intel) connects via USB-C to a Lenovo dock, dock connects via HDMI to a TESmart 4K@60Hz 4:4:4 KVM, KVM connects to a monitor. When I plug the laptop directly into the KVM via HDMI, video works perfectly. When that same HDMI cable runs through the dock, the laptop doesn’t detect any external monitor at all. Keyboard and mouse on the dock work fine. This is the worst kind of partial failure — where I seriously wondered if the problem was me all along.

The correct diagnosis would have taken five seconds. I did not find it in five seconds.

The Reasonable Wrong Answer

USB-C dock on a Thunderbolt-capable laptop, video not working. The obvious suspect is Thunderbolt authorization. Linux requires Thunderbolt devices to be explicitly authorized before they can pass video — the bolt daemon handles this, and the security level on most systems defaults to user or secure, which means unrecognized devices are blocked until approved. USB peripherals (keyboard, mouse) work because they’re enumerated through the USB controller, not the Thunderbolt controller. DisplayPort Alt Mode video goes through Thunderbolt. If bolt isn’t running, or if the device hasn’t been authorized, it would look exactly like what I saw.

Turns out, that reasoning is entirely correct. For a Thunderbolt dock.

My T14-specific NixOS profile (nixos/profiles/laptop/t14.nix) looked like this before I touched it:

{inputs, ...}: {
  imports = [
    ./.
    ./power.nix
    inputs.nixos-hardware.nixosModules.lenovo-thinkpad-t14-intel-gen1
  ];
}

Sensible. Minimal. I made it worse:

services.hardware.bolt.enable = true;
boot.kernelParams = ["i915.enable_dp_mst=1"];

The bolt line enables the Thunderbolt daemon and, because KDE Plasma ships plasma-thunderbolt, you get a little system tray widget to authorize devices. The i915.enable_dp_mst=1 was purely speculative — I threw it in because some docks have an internal DisplayPort Multi-Stream Transport hub that needs MST support from the GPU driver, and I figured it couldn’t hurt. (I was correct here, it didn’t hurt. More precisely, the only thing it accomplished was “not hurting”).

Build was clean. nh os build added bolt 0.9.8 and plasma-thunderbolt 6.6.4. After just switch and a reboot:

$ systemctl status bolt
● bolt.service - Thunderbolt system service
     Active: active (running)
        ...
May 05 17:59:24 wendigo boltd[5619]: udev: found 0 domain
May 05 17:59:24 wendigo boltd[5619]: udev: enumerating devices
May 05 17:59:44 wendigo boltd[5619]: power: setting force_power to OFF

$ boltctl list
# (no output)

udev: found 0 domain. The kernel isn’t exposing any Thunderbolt domains at all. boltctl list is silent. The dock isn’t showing up because, from the kernel’s perspective, there is no Thunderbolt controller talking to anything. This wasn’t a configuration problem; the hardware wasn’t what I assumed it was.

I reverted both changes and went to look at what was actually there.

lsusb. Obviously. Run lsusb “First”

The diagnostic I should have started with:

$ sudo dmesg | rg -i "thunderbolt|usb4|tbt"
[    0.015200] ACPI: SSDT 0x00000000A652D000 001F15 (v02 LENOVO WHL_Tbt_ ...)
[    6.155008] ACPI: bus type thunderbolt registered

Only ACPI table entries — the firmware knows Thunderbolt exists as a bus type, but no actual controller was probed, no domain registered. Then:

$ sudo dmesg | rg -i "i915|drm|displaylink"
[    4.119714] usb 2-2.2: New USB device found, idVendor=17e9, idProduct=6015, bcdDevice=31.04
[    4.119719] usb 2-2.2: Manufacturer: DisplayLink

Hmm… Manufacturer: DisplayLink. Let’s just dig in there a little deeper:

$ lsusb
Bus 002 Device 003: ID 17e9:6015 DisplayLink ThinkPad Hybrid USB-C with USB-A Dock

There’s the dock’s full product name: ThinkPad Hybrid USB-C with USB-A Dock. The word “Hybrid” is doing a lot of work there, and I’d completely missed it. Lenovo designed this dock to connect to hosts via either USB-C or USB-A — because USB-A has no DisplayPort Alt Mode capability at all, they couldn’t build it around native video passthrough. Instead, the dock contains a DisplayLink USB graphics chip that compresses the framebuffer, ships it over USB, and decompresses it in the dock. The graphics chip doesn’t care whether the host connected via USB-C or USB-A; it just needs USB bandwidth.

The architecture difference matters enormously for driver requirements:

A native DP Alt Mode dock just works on Linux. A Thunderbolt dock needs bolt for authorization but otherwise just works. A DisplayLink dock needs a proprietary kernel module (evdi) and a closed-source userspace daemon from Synaptics. I had the wrong dock for the thing I wanted — zero-config Linux compatibility.

Was this clear from the product name? In retrospect, absolutely. Would I have noticed it without the lsusb output slapping me in the face? Shmaybe?

In Which I Briefly Try to Make DisplayLink Work

Look, I knew this was unlikely to go well – but I already had several browser tabs open.

The DisplayLink Linux package lives in nixpkgs under pkgs/os-specific/linux/displaylink/default.nix. It uses requireFile because Synaptics’s license prohibits redistribution — you have to manually download the installer and nix-store --add-fixed it yourself. The NixOS module lives at nixos/modules/hardware/video/displaylink.nix. I should have read it before trying anything. I skipped reading it before trying anything.

Easy enough to activate: services.xserver.videoDrivers = ["displaylink"]. The module keys off that list to decide whether to load evdi and start the dlm.service daemon.

After finding the correct option name, I actually opened the module source. Here’s the relevant piece:

let
  enabled = lib.elem "displaylink" config.services.xserver.videoDrivers;
in {
  config = lib.mkIf enabled {
    boot.extraModulePackages = [ evdi ];
    boot.kernelModules = [ "evdi" ];
    services.xserver.externallyConfiguredDrivers = [ "displaylink" ];
    environment.etc."X11/xorg.conf.d/40-displaylink.conf".text = ''
      Section "OutputClass"
        Identifier  "DisplayLink"
        MatchDriver "evdi"
        Driver      "modesetting"
        ...
      EndSection
    '';
    services.xserver.displayManager.sessionCommands = ''
      ${lib.getBin pkgs.xrandr}/bin/xrandr --setprovideroutputsource 1 0
    '';
    ...
    systemd.services.dlm = {
      description = "DisplayLink Manager Service";
      ...
    };
  };
}

/etc/X11/xorg.conf.d/. externallyConfiguredDrivers. xrandr --setprovideroutputsource. Every single piece of this module is X11 plumbing. The laptop profile defaults to Wayland. KDE Plasma 6 on Wayland ignores xorg.conf.d entirely, doesn’t use xrandr for output management, and doesn’t load the Xorg modesetting driver at all.

DisplayLink on Wayland is an unresolved upstream problem. Synaptics has been working on it, but it’s not production-ready in 2026, and nothing in this NixOS module moves that needle. The community workaround is forcing the session back to X11, which trades away Wayland features/improvements in exchange for getting a dock working — a dock that, by the way, introduces CPU overhead for every frame rendered, because all of that framebuffer compression happens on the host CPU.

Well… crap. The hardware problem may not be something with a software solution afterall. I’m as shocked as you are.

Actually Solving It

My requirements aren’t too complicated:

1. HDMI 2.0 output (the TESmart KVM does 4:4:4 chroma at 4K@60Hz; HDMI 1.4 won’t do it)
2. Gigabit Ethernet
3. 65W+ Power Delivery (T14 and X1 Carbon charging)
4. USB-C host connection
5. DP Alt Mode — explicitly not DisplayLink (see everything above)

The easiest way to verify #5 before buying is lsusb output from someone who already owns the dock. That is a level of planning and thoroughness that I am clearly not going to start doing now.

The Plugable USBC-7IN1E landed at the top of the shortlist. Plugable explicitly documents 4K@60Hz HDMI support and maintains a USB-C Alt Mode explainer that makes the architecture clear. Around $40–45, driverless, and they explicitly list Linux compatibility. The Anker 555 (A8383) is a credible alternative in the same price range, though Anker doesn’t officially support Linux (it works in practice). The Targus DOCK430USZ and refurbished Lenovo 40AY0090US are both solid options if you want something closer to enterprise-grade, at roughly $60–100.

The Arch Linux forums have a useful thread on T14 + USB-C + 4K that confirms the chroma subsampling behavior and validates that native DP Alt Mode docks just work without touching the kernel or xorg config.

Note the naming pattern: the dock I don’t want is the Hybrid USB-C with USB-A dock. The dock I do want is the Universal USB-C Dock, the USB-C 7-in-1, the straightforward naming that doesn’t require a compatibility matrix. “Hybrid” means “we needed it to work with USB-A hosts, so we put a DisplayLink chip inside.” That’s a real engineering constraint Lenovo solved reasonably well — it’s just not compatible with what I’m trying to do.

What I Should Have Done

lsusb. That’s it. Five seconds.

$ lsusb | grep -i lenovo
Bus 002 Device 003: ID 17e9:6015 DisplayLink ThinkPad Hybrid USB-C with USB-A Dock

17e9 is DisplayLink. The word “Hybrid” is in the name. Everything else that followed — the Thunderbolt hypothesis, the bolt daemon, the speculative i915.enable_dp_mst=1, the X11-only module audit — all of it was downstream of not checking what hardware was actually present before starting to theorize.

The second thing I should have done: one change at a time. I added bolt and the kernel parameter together, which meant when the fix didn’t work, I had two things to unwind and no signal about which (if either) had done anything. Each hypothesis gets one change, one rebuild, one test. This is obvious advice that I ignored because I was confident in my diagnosis. That confidence was misplaced.

The third thing: read the module source before enabling it. nixos/modules/hardware/video/displaylink.nix has xrandr in the sessionCommands. That’s an immediate tell — xrandr doesn’t manage Wayland outputs. I would have known in thirty seconds that this path was going nowhere.

Hardware problems shouldn’t have software solutions. A DisplayLink dock on a Wayland system in 2026 is not a NixOS configuration gap; it’s an upstream compatibility gap that no amount of declarative config can paper over. The right response is a $45 dock with native Alt Mode support, not a creative workaround for a proprietary graphics protocol designed to run over USB 3.0. To be fair, I could just switch away from Wayland and I’d be fine. Apparently I’ve decided that I want the small dopamine hit from buying something shiny instead.

t14.nix is back to its original five lines. Nothing changed. The new dock is in the mail.