## What happened

On a ThinkPad X1 Carbon Gen 8 (Intel Alpine Ridge JHL6540 Thunderbolt 3 controller), an external monitor connected through a USB-C→DisplayPort adapter gets stuck reporting `connected` but with a `0x0` (no valid mode) in `hyprctl monitors`, after a suspend/resume cycle or a physical replug. Only a full reboot recovers it.

Filing this as a compat/documentation note, not a request to fix — I traced it down to the kernel/firmware level and it's outside anything Omarchy, Hyprland, or `omarchy-hyprland-monitor-watch`'s recovery logic can reach. Full write-up and everything tried below.

## System

- ThinkPad X1 Carbon Gen 8 (20U9006HMX), BIOS N2WET48W
- Alpine Ridge JHL6540 Thunderbolt 3 controller
- Omarchy 4.0.4-1, kernel `7.2.5-3-omarchy`

## What was tried, in order

1. `hyprctl reload` — no effect
2. Forcing a DRM reprobe via `/sys/class/drm/.../status` (`detect`, and `off`+`detect`) — no effect
3. Physical unplug/replug of the adapter — no effect, same `EDID` / `Unexpected DP dual mode adaptor ID` kernel errors reappear
4. Suspend/resume — no effect; `xhci_hcd 0000:2d:00.0: xHC error in resume, USBSTS 0x401, Reinit` logs on every resume
5. PCI-level reset of just the TB3 xHCI USB function (`remove` + `rescan` on `0000:2d:00.0`) — controller cleanly re-enumerates (new BDF), but DP-2 stays `0x0`
6. Full PCI-level reset of the entire TB3 hierarchy from the root bridge (`0000:05:00.0` `remove` + `rescan`) — the whole controller (bridges, NHI, xHCI, typec ports) re-enumerates from scratch, essentially a live power-cycle of the controller as far as the PCI core goes — DP-2 **still** stuck at `0x0`
7. Only a real reboot (ACPI S5) recovers it

## Why I'm not asking for an Omarchy fix

Step 6 rules out anything Omarchy-reachable: even a full software teardown/re-probe of the whole Thunderbolt PCI hierarchy didn't recover the DP tunnel, meaning the alt-mode negotiation state almost certainly lives in EC/PMC firmware or a board-level redriver/mux that only clears on an actual platform power cycle. `omarchy-hyprland-monitor-watch`'s existing modeless-recovery loop (which retries `hyprctl reload` on a backoff) correctly can't fix this class of failure either, since there's no DRM-level state to recover — the link genuinely never comes back up until reboot.

I've also filed this against the upstream kernel (`thunderbolt`/`xhci_hcd`), since that's the actually appropriate owner. Posting here purely so anyone else hitting a black-screen external monitor on this exact chip (Alpine Ridge / JHL6540) after suspend or replug knows: it's not your Omarchy config, `omarchy-hyprland-monitor-watch` is doing the right thing already, and the only known workaround right now is a full reboot.

## Full technical write-up

Kernel log excerpts, exact commands run, and analysis: happy to attach on request — kept this issue to a summary since it's not actionable on Omarchy's side.