Issue:
After a cold boot, none of the 4 USB-C DisplayPort outputs (DFP-1 through DFP-4) are detected, even when a monitor is connected via USB-C→VGA adapter and powered on before or during boot. The only working output at boot is HDMI-0. Physically unplugging and reconnecting the USB-C cable immediately triggers detection and the display comes up correctly (confirmed via journalctl showing EDID read: “LG Electronics LG FULL HD (DFP-1): connected”).
What I’ve verified:
/sys/class/typec/ is empty — no typec-class controller exposed for these ports
/sys/bus/thunderbolt/devices/ is empty — not a USB4/TBT tunneling issue
nvidia-settings -q dpys and xrandr --query both consistently report all 4 USB-C outputs as disconnected, polled repeatedly over several minutes post-boot (not just once at boot)
Software re-probe attempts do NOT resolve it: xrandr --output USB-C-0 --off followed by --auto has no effect; state remains disconnected
Firmware is fully up to date (fwupdmgr get-updates shows Embedded Controller and UEFI Device Firmware both at latest available version)
journalctl confirms the driver polls DFP-1 status repeatedly (12:05, 12:06, 12:09, 12:14) always returning “disconnected” until physical replug at 12:19, at which point EDID is read successfully
Conclusion: This looks like an HPD/sink-detection issue at the PD controller or mux level on the USB-C ports specifically, occurring during power-on/boot sequencing, not something the OS/driver can recover from without a physical reconnect event. No software-level workaround (xrandr toggle, nvidia-settings re-query) has been able to force a re-detection.
Question: Has anyone else seen this specific behavior? Is there a known fix planned, or a lower-level way (EC command, different firmware capsule) to force PD/HPD re-negotiation on these ports without physically unplugging?
Yes - same effect here (Lenovo Thinkstation PGX, also at all latest updates on OS and firmware level) and I mentioned it already in another thread but it is worth adressing this in a dedicated thread.
This is particularly a problem, when you run the updates, as they contain several reboots and firmware-updates (some of them taking minutes). Here you are completely “blind” without any feedback what’s happening or if they already died…
As long, as this is not fixed, I strongly recommend to run the updates only with a monitor attached via HDMI port.
I own both an ASUS and an MSI, and I haven’t encountered any DP-Alt mode problems with either. Just to be clear, I’m connecting them directly to a portable monitor via a USB-C to C cable, without using any intermediate adapters.
@helge — good to know it’s not isolated to my specific unit, and the reboot-blindness point during firmware updates is a really good call-out. I’ll keep an HDMI monitor attached during future updates too.
@Mkei88 — that’s an interesting data point, though I’d treat it as a working theory rather than confirmed, since it’s not a controlled comparison on the same machine. In my case I’m always going through a passive USB-C to VGA adapter, never a direct USB-C to USB-C connection to a native DP/USB-C monitor.
One additional data point that narrows this down further: if I power on the monitor before or during boot, detection works fine, no replug needed. The problem only happens if the monitor is powered on after the GB10 has already booted — and the window seems quite narrow: if I press the GB10 power button and then power on the monitor even a few seconds too late (i.e. not in time to catch the boot process), it shows nothing at all, confirming the detection window closes early in the boot sequence, not sometime later during OS startup. This makes me think it’s less “USB-C doesn’t work with adapters” and more that the GB10’s sink-detection only runs once, in a narrow window very early in boot — if the adapter/monitor isn’t already up and negotiated by then, the query is never repeated, and only a physical replug (which re-triggers CC-line detection) forces a re-check.
If anyone has a USB-C to VGA/HDMI adapter they could test with — as opposed to a native USB-C monitor — that would help confirm whether the adapter’s negotiation latency is the deciding factor, or whether native USB-C displays would show the same issue if powered on late.
For reference, my setup consistently reproduces the issue: DFP status stays “disconnected” indefinitely post-boot (confirmed via repeated nvidia-settings -q dpys polling over several minutes) until either a physical USB-C replug, or having the monitor already powered on at boot time.
To add a data point: My monitor(s) are directy connected via USB-C (no adapter), they also get their power from the Spark’s USB-C port. It makes no difference, when I power them seperately.
Can you share the exact model of the LG display you are connecting? I assume from your description of the issue that you are going straight USB-C to USB-C?
Hi @ManuelGuzman, thanks for looking into this!
To clarify — I’m not going USB-C to USB-C directly. I’m using a passive USB-C to VGA adapter between the GB10 and an LG 22M38A-B (2017 model, VGA-only input, no native DisplayPort/HDMI/USB-C).
The adapter is a generic/no-name brand (“Thzzhnno”, sold on Amazon), described as: USB-C to VGA cable, 1.8m, USB-C to VGA conversion, 1080p @ 60Hz, marketed for laptops/phones/tablets/HDTVs/monitors/projectors. Not sure which conversion chip it uses internally, so I can’t rule out it being a factor here.
Given the timing-related behavior I described — works fine if the monitor is powered on right at boot, fails if powered on even a few seconds late, with detection resuming only after a physical USB-C replug — I suspect the adapter’s DP-to-VGA conversion chip needs some time to initialize and negotiate before it can respond to the GB10’s sink-detection query, and that query isn’t retried after the initial boot window closes.
Happy to provide any further logs or run additional tests if useful.
Hi @ManuelGuzman,
For reference, I found a similar (but not directly applicable) case on AMD GPUs: AMD-GPU-DP-Hotplug-Fix. Same root cause pattern — DP requires an active AUX-channel handshake + link training (unlike HDMI, which is more passive), and if the monitor/adapter isn’t ready fast enough during the driver’s connector probe, detection fails and is never retried, only fixed by a power-cycle or replug.
Their fix relies on forcing a re-scan via /sys/class/drm/card*-DP-*/status, which works because amdgpu is open-source and exposes per-connector sysfs nodes. On my system, the open kernel module (nvidia-drm/nvidia-modeset) doesn’t expose this: ls /sys/class/drm/ only shows card0-Unknown-1 (tied to the simple-framebuffer, not the actual GPU) — card1 (the NVIDIA GPU) has no per-connector status nodes at all. So the same soft-rescan approach isn’t available here, and I’ve confirmed xrandr --output USB-C-0 --off / --auto (the userspace equivalent) has no effect either.
This does suggest it’s a known class of DRM/DP bug across drivers though — might be worth checking if nvidia-drm has an internal equivalent to force a connector re-probe without a physical replug.
Follows some details from xrandr
Manufacturer: GSM (LG)
Product ID: 0x5AB9
Model: LG FULL HD / 703NTWGFX113
Raw EDID: 00ffffffffffff001e6db95ab9410800 031b01036c301b78ea3135a5554ea126 0c5054a54b00714f81809500b300a9c0 810081c09040023a801871382d40582c 4500e00e1100001e000000fd00384b1e 530f000a202020202020000000fc004c 472046554c4c2048440a2020000000ff 003730334e54574746583131330a008a