DocHub
Three-monitor configuration, USB-C DisplayPort issues, and how the layout persists across reboots

Display Setup

Three-Monitor Layout

┌──────────────────┐┌─────────────────┐┌────────────┐
│                  ││                 ││            │
│    HDMI-0        ││   eDP-1-1      ││  DP-1-x    │
│   3840x2160      ││  2880x1620     ││ 1920x1080  │
│    (left)        ││  (center)      ││  (right)   │
│                  ││   PRIMARY      ││            │
│                  ││                 ││            │
└──────────────────┘└─────────────────┘└────────────┘
pos: 0,0            pos: 3840,214       pos: 6720,754
Output Monitor Resolution Connection GPU
HDMI-0 External 4K (BOE) 3840x2160 @60Hz HDMI cable NVIDIA
eDP-1-1 Laptop screen (SDC) 2880x1620 @120Hz Internal NVIDIA
DP-1-1 to DP-1-4 Portable USB-C (DZX Z12-2) 1920x1080 @60Hz USB-C Intel

USB-C Monitor — Important Notes

The portable USB-C monitor (DZX Z12-2) connects via USB-C which carries both power and DisplayPort Alt Mode signal. Key issues:

Connector varies by port

The USB-C monitor can appear on any of DP-1-1, DP-1-2, DP-1-3, or DP-1-4 depending on which physical USB-C port is used. All configuration files account for this.

“No signal” on boot

The USB-C DisplayPort Alt Mode negotiation sometimes fails at boot (kernel error: typec_displayport probe failed with error -17). The monitor gets USB power but no video signal.

Fix: Unplug the USB-C cable, wait 5 seconds, plug back in. If that fails, try the other USB-C port.

UCSI timeout errors

The USB Type-C controller occasionally times out:

ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-110)

This is a known Linux kernel issue with UCSI. Replugging resolves it.

Persistence — How Layout Sticks Across Reboots

Two mechanisms ensure the correct layout:

1. GNOME monitors.xml

File: ~/.config/monitors.xml

Contains pre-configured layouts for every possible combination of connector names. GNOME’s mutter reads this at login and applies the matching configuration.

As of 2026-03-15, contains 5 configurations:

  • 3-monitor layout with USB-C on DP-1-1, DP-1-2, DP-1-3, or DP-1-4 (4 configs)
  • 2-monitor layout with HDMI + laptop only (1 config)

2. xrandr autostart script (fallback)

File: ~/.config/monitor-setup.sh Autostart: ~/.config/autostart/monitor-setup.desktop

Runs at login, detects which DP port the USB-C monitor is on, and applies the correct xrandr layout:

# Finds whichever DP-1-x is connected
for dp in DP-1-1 DP-1-2 DP-1-3 DP-1-4; do
    if xrandr | grep -q "^${dp} connected"; then
        USB_DP="$dp"
        break
    fi
done

Handles all combinations: 3 monitors, HDMI + laptop, USB-C + laptop, or laptop only.

GPU Driver and Video Decode

nvidia-vaapi-driver (installed 2026-03-15)

Chrome uses VA-API for hardware video decode. On NVIDIA Optimus laptops, the default VA-API drivers (Intel iHD) don’t work because Chrome renders through the NVIDIA GPU. The nvidia-vaapi-driver package bridges VA-API to NVIDIA’s NVDEC hardware decoder.

Without it: Chrome reports “Video Decode: Hardware accelerated” but every decode fails silently:

Could not get a valid VA display
failed initializing VaapiWrapper for profile av1/h264/vp9

Videos fall back to CPU software decode, pinning a full core per video.

With it: Hardware decode works. YouTube/video offloaded to RTX 4060’s NVDEC engine.

Package: sudo apt install nvidia-vaapi-driver

Verifying video decode works

  1. Open chrome://gpu in Chrome
  2. Check “Video Decode: Hardware accelerated”
  3. Scroll to “Log Messages” at the bottom — should be empty
  4. If you see Could not get a valid VA display errors, the driver is missing or broken