### System info

- Omarchy 4.0.2 · Hyprland 0.56.2 (`efb50993`) · Aquamarine 0.14.0 · kernel 7.1.9-arch1-2
- MSI Optimus laptop: i7-6700HQ — **Intel HD Graphics 530** (`8086:191b`, i915) + **NVIDIA GTX 1060 Mobile** (`10de:1c20`, GP106M, Pascal)
- Driver: AUR `nvidia-580xx-dkms` 580.178.04 (the branch Omarchy correctly selects for non-GSP Pascal)
- Outputs: internal panel on **i915** (`eDP-1`); two external monitors on **nvidia** (`HDMI-A-1`, `DP-1`)
- RTD3 already pinned off (`NVreg_DynamicPowerManagement=0x00` + udev `power/control=on`, cf. #3242) — this is a **different, distinct failure mode**

### Symptom

- Internal panel only: **fully stable for hours**
- Externals connected but idle: stable
- **Actively using the externals** (moving a window there, launching an app there): Hyprland aborts with the recovery screen (`recoverycfg.lua` banner). Happened twice in one afternoon, identical signature both times.

### Evidence

Kernel journal at the exact second of each crash:

```
i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
i915 0000:00:02.0: [drm] Hyprland[<pid>] context reset due to GPU hang
i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:85dffffb, in Hyprland [<pid>]
Hyprland has crashed :( Consult the crash report at ~/.cache/hyprland/hyprlandCrashReport*.txt
```

Crash report: signal 6 (ABRT) — assertion inside `Render::GL::CHyprOpenGLImpl::begin(...)`, reached via `IHyprRenderer::renderMonitor` ← `CMonitorFrameScheduler::onFrame` (DRM frame event). **Identical ecode both times** → deterministic code path, not flaky hardware.

### Mechanism

Hyprland's render context was on the **Intel** GPU (default primary). Every frame displayed on the NVIDIA-driven outputs therefore required i915→nvidia dmabuf copies. The buffer-fence handshake with the legacy 580xx driver stalls, i915 misses its preemption deadline, the kernel hangs + resets the engine, Hyprland's EGL context dies with the reset, and the assert aborts the compositor. Note `render:explicit_sync` no longer exists as an escape hatch (removed in 0.50), so this was not config-fixable in the obvious way.

### Workaround that fully fixed it (verified)

Keep **both** GPUs, but make NVIDIA the render-primary — using boot-order-proof by-path device names:

```
env = AQ_DRM_DEVICES,/dev/dri/by-path/pci-0000:01:00.0-card:/dev/dri/by-path/pci-0000:00:02.0-card
```

Result: Hyprland's GL context moves to the dGPU (visible in `nvidia-smi`: Hyprland ~145 MiB VRAM vs ~1 MiB before), externals render natively with **no cross-GPU copies in the hot path**, and i915 is left with scanout duty for the internal panel. A 10-minute monitored run (1 sample/10 s) of the exact crash workload: **zero GPU hangs, zero NVRM/i915 errors**. Multi-hour stable since.

⚠️ On hybrid, `AQ_DRM_DEVICES` must always list **both** cards — a single-GPU value kills the other GPU's outputs.

### Suggestions for Omarchy

Omarchy already detects non-GSP Pascal (`omarchy-hw-nvidia-without-gsp` → `NVD_BACKEND=egl`). For hybrid (i915 + nvidia) systems it would help to either auto-apply an **NVIDIA-first `AQ_DRM_DEVICES`** or document this prominently in the NVIDIA guidance: with Intel primary, this hardware class crashes exactly as described, and the diagnosis (an Intel GPU hang causing what looks like random compositor crashes) took days. Even a doc line about the `i915 ... GPU HANG ... in Hyprland` + `CHyprOpenGLImpl::begin` signature and the AQ-ordering fix would shortcut it for the next person.

Related: #3242 — RTD3 freezes on the same hardware class (different failure mode; fixed by pinning RTD3 off, which this system also has).