### System details

- Dell XPS 16 DA16260, BIOS 1.8.2; Intel Core Ultra X7 358H.
- Intel Panther Lake Arc B390, PCI ID `8086:b080`, `xe` driver.
- Internal panel: LG Display `0x07C5`, eDP-1, 3200×2000 at 120 Hz, scale 2, VRR off.
- External: ASUS PA27JCV on DP-1, 5120×2880 at 60 Hz through a Thunderbolt dock.
- Omarchy `4.0.3-1`; `linux-ptl 7.2.3.arch1-1`, running `7.2.3-arch1-1-ptl`; Hyprland `0.56.2-2`; Intel firmware `20260810-2`.
- Aquamarine is a **locally patched** `0.15.0-2.1`: disables KMS on connector disconnect (https://github.com/hyprwm/aquamarine/pull/395). Also have a local Omarchy external-monitor detection override excluding FALLBACK, and a cloned monitor panel using Lua-compatible toggles. These address earlier disconnect/toggle issues; stock userspace reproduction of this new failure has not been tested.

### What's wrong?

The internal laptop panel went black during an existing session. Connecting an external display gave a working desktop, but disconnecting it left the laptop panel black. The normal internal-display toggle did not recover it. The laptop should continue displaying the desktop, and recover when enabled or when the last external screen disconnects.

This is one observed incident with a confirmed recovery, **not yet a deterministic reproduction**. The exact initiating action is unknown. Suspend exited at 12:16 CEST; the first PSR errors appeared at 17:28:59, so this is not established as an immediate resume failure. Later dock reconnects at approximately 18:15 occurred after the errors had already begun.

While physically black, both Hyprland and DRM reported eDP-1 enabled/connected, Hyprland reported DPMS on and 120 Hz, brightness was 28%, and the lid sensor reported open. The external screen remained usable.

The kernel repeatedly logged:

```text
xe 0000:00:02.0: [drm] *ERROR* Timed out waiting for PSR Idle for re-enable
xe 0000:00:02.0: [drm] *ERROR* Timed out waiting PSR idle state
```

#### Recovery tested in the same desktop session

1. Explicit DPMS disable/enable of eDP-1, with three seconds between: commands returned `ok`, but the PSR timeouts continued and the panel did not recover.
2. Fully disable eDP-1, wait three seconds, then enable at its supported 60 Hz mode:

```sh
hyprctl eval 'hl.monitor({ output = "eDP-1", disabled = true })'
sleep 3
hyprctl eval 'hl.monitor({ output = "eDP-1", disabled = false, mode = "3200x2000@60", position = "0x0", scale = 2 })'
```

The user confirmed the laptop panel became visible. The last PSR timeout in the captured journal was at 18:22:31 during recovery.

3. Restore 120 Hz:

```sh
hyprctl eval 'hl.monitor({ output = "eDP-1", disabled = false, mode = "3200x2000@120", position = "0x0", scale = 2 })'
```

Hyprland reported 120 Hz and enabled/DPMS on; no subsequent PSR errors were present at the follow-up check. No reboot or compositor restart was needed. No persistent PSR or refresh-rate workaround was installed.

This does **not** establish that 120 Hz is the cause: full disable/re-enable and refresh-rate change were combined, and direct reinitialization at 120 Hz has not been tested.

#### Investigation status

The symptoms and errors suggest a stuck Intel display self-refresh state, but the exact driver/firmware/compositor cause is unconfirmed. Module parameters `enable_psr` and `enable_panel_replay` both read `-1` (automatic defaults). There are no PSR/Panel Replay overrides on the kernel command line.

After recovery at 120 Hz, `/sys/kernel/debug/dri/0000:00:02.0/eDP-1/i915_psr_status` reports:

```text
PSR mode: Panel Replay Selective Update enabled (Early Transport)
Source PSR/PanelReplay ctl: enabled [0x40000000]
Source PSR/PanelReplay status: SLEEP [0x30200011]
Busy frontbuffer bits: 0x00000000
PSR2 selective fetch: enabled
```

The debug override reads `0`. This is a **working-state** capture; SLEEP alone is not evidence of the failure.

Related: #11016 has the same GPU and affected PTL kernel with a demonstrated Panel Replay-dependent lag regression on an XPS 14, but a different panel/symptom. #5573 is an older XPS 14 frozen-panel report with different errors. This report does not claim either is the same underlying bug.

Next useful checks are capturing `eDP-1/i915_psr_status` while failed, then controlled PSR/Panel Replay comparisons and a compatible kernel comparison. Failed-state debugfs data was not captured before recovery, and no kernel bisect or stock Aquamarine comparison has been performed.