### System details

- Omarchy: **4.0.4-1** (installed before the recorded September 26/28 incidents)
- Laptop: Lenovo **20UN0084CD**; BIOS **N2TET92W (1.70)**
- CPU: 11th Gen Intel Core **i5-1130G7**
- GPU: Intel Tiger Lake-UP4 GT2 / Iris Xe Graphics, PCI **8086:9a40**, driver **i915**
- Running kernel at the recorded incidents and currently: **7.2.3-arch1-3** (`linux` package, not `linux-omarchy`)
- Hyprland: **0.56.2-2**; Aquamarine: **0.15.0-2**; Mesa: **26.2.2-1**
- Connection: **USB-C to DisplayPort**. Adapter/cable model has not been recorded.
- External monitor: LG Ultra HD, normally **DP-3**, **3840×2160 at 30 Hz**, scale **2**
- Internal panel: **eDP-1**, **2160×1350 at approximately 59.74 Hz**
- Available suspend mode: `s2idle`. This does not establish that system suspend occurred during these incidents.

### What's wrong?

After the displays have been idle/asleep for a long period, waking the displays and returning to the desktop can leave the external LG monitor without an image. The internal panel remains usable. A full system reboot restores the external monitor.

The failure has occurred repeatedly. Retained kernel journals contain the same warning in the Intel Type-C/DisplayPort link-reset worker on **September 26 and September 28, 2026**. This is evidence of a failed recovery operation, not proof that the GPU, adapter, monitor, or Omarchy itself is the underlying cause.

### Steps to reproduce

1. Connect the LG external monitor through USB-C to DisplayPort and use it alongside the internal panel.
2. Leave the session idle with the displays asleep for a long period.
3. Wake the displays and return to/unlock the session.
4. The external monitor can remain black while the internal panel works.
5. Reboot the computer; the external monitor displays an image again.

The problem is intermittent; a minimum idle duration has not been isolated. The original symptom was described as occurring after a long sleep, but the retained September 27–28 boot journal contains **no matching system suspend/resume entries**. Long idle / monitor power save is therefore a more accurate reproduction description than confirmed system suspend.

**Expected:** The external monitor resumes displaying the desktop after waking.

**Actual:** The external monitor has no image. Unplugging and reconnecting the USB-C-to-DisplayPort cable was tested and **does not restore video**. A full system reboot restores video. On October 6, a connector off/on/detect sequence followed by DPMS and monitor disable/re-enable restored a normal desktop **without rebooting, at 1920×1080/60 Hz**. Returning to 3840×2160/30 Hz produced a vertical strip rather than a normal image; the output was rebuilt at 1080p/60 Hz and the owner confirmed normal video again. See the October 6 follow-up for the captured failed state and exact sequence. Monitor power cycling and alternate-kernel recovery have not been documented as tested.

### Relevant kernel evidence

All timestamps below are local time, UTC+08:00.

```text
2026-09-26T09:09:46+08:00 kernel: i915 0000:00:02.0: [drm] drm_WARN_ON(ret)
2026-09-26T09:09:46+08:00 kernel: WARNING: drivers/gpu/drm/i915/display/intel_tc.c:1837 at intel_tc_port_link_reset_work+0x445/0x4a0 [i915]
2026-09-26T09:09:46+08:00 kernel: Workqueue: events_unbound intel_tc_port_link_reset_work [i915]

2026-09-28T10:05:55+08:00 kernel: i915 0000:00:02.0: [drm] drm_WARN_ON(ret)
2026-09-28T10:05:55+08:00 kernel: WARNING: drivers/gpu/drm/i915/display/intel_tc.c:1837 at intel_tc_port_link_reset_work+0x445/0x4a0 [i915]
2026-09-28T10:05:55+08:00 kernel: CPU: 5 UID: 0 PID: 2503321 Comm: kworker/u32:13 Not tainted 7.2.3-arch1-3
2026-09-28T10:05:55+08:00 kernel: Hardware name: LENOVO 20UN0084CD/20UN0084CD, BIOS N2TET92W (1.70 ) 03/12/2026
2026-09-28T10:05:55+08:00 kernel: Workqueue: events_unbound intel_tc_port_link_reset_work [i915]
2026-09-28T10:05:55+08:00 kernel: RIP: 0010:intel_tc_port_link_reset_work+0x452/0x4a0 [i915]
```

For the September 28 incident, the session unlocked at **10:05:37**, the warning was logged at **10:05:55**, and the next boot began at **10:07:09**. The exact moment the external image first failed was not captured. An Omarchy update was also initiated shortly before this warning, during the period before reboot, so the warning's timestamp alone does not establish the initial trigger.

The warning is in the kernel's Type-C DP link-reset recovery path. Upstream source shows this worker warning when the reset operation returns an error: [Linux i915 intel_tc.c](https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/i915/display/intel_tc.c). No known fixed version or hardware defect has been established for this machine.

### Configuration and diagnostic limitations

- During the original incidents, `monitors.lua` contained a custom workspace migration callback registered with `hl.on("monitor.added", ...)` and `hl.on("monitor.removed", ...)`. A top-of-screen warning mentioning that callback was also observed; its exact error text was not retained.
- On September 30, `monitors.lua` was restored to the shipped default. On October 1, only ordinary workspace rules were added: workspaces 1–9 on the external display and workspace 10 on eDP-1. The custom event callbacks remain removed; `hyprctl configerrors` is empty after reload.
- **Update, October 6:** The failure recurred with the custom monitor event callbacks still removed. Ordinary workspace rules and scale 2 remain configured, so this is not a reproduction with an entirely default configuration. A limited recovery at 1080p/60 Hz was confirmed without rebooting; 4K recovery remains unresolved.
- After reboot, Hyprland identifies both panels, including DP-3 at 3840×2160/30 Hz. Failed-state connector and EDID data were not captured during the September incidents. **On October 6**, they were captured before recovery: Hyprland omitted DP-3, DRM reported `disconnected` despite `enabled` / DPMS `On`, and EDID was empty. Forced re-detection restored metadata before physical video; the follow-up documents both stages.
- No screenshot of the original warning is available.
- The `omarchy debug` CLI route is unavailable on this installation. Diagnostics were collected using the existing `omarchy-debug --no-sudo --print` executable, package versions, and retained journals. Relevant excerpts are included above rather than the unrelated current-boot journal and full package inventory.

### Related reports

- #13211: i915 display re-detection failure after USB-C dock reconnect on the same kernel version; different GPU and reconnect trigger.
- #11909: Intel DP display has no video after long idle and recovers via DPMS; that report captured a logically connected output and did not find an i915 warning.

These reports have related symptoms, but matching root causes have not been established. This report adds the repeated `intel_tc_port_link_reset_work` warning on Tiger Lake with a USB-C-to-DP connection.