### System details

- Device: Apple MacBookPro11,3
- CPU: Intel Haswell
- GPUs:
  - Intel Crystal Well integrated GPU (`i915`)
  - NVIDIA GK107M / GeForce GT 750M Mac Edition (`nouveau`)
- Internal display: eDP-1, 2880×1800
- Omarchy: 4.0.0-1
- Hyprland: 0.56.2
- Kernel: 7.1.8-arch1-3
- Mesa Gallium: 26.1.8
- Filesystem: encrypted Btrfs root with a disk-backed hibernation swapfile

### What happens

Running `systemctl hibernate` powers the machine down successfully. On resume, the original graphical session crashes and UWSM restarts Hyprland using its autogenerated recovery configuration.

The resulting screen says that the lockscreen application died. The lockscreen message is secondary: the process that first fails is Hyprland itself.

This was reproduced in a controlled test with AC power connected before hibernation.

### Expected result

The restored Hyprland session and lock screen should remain usable after hibernation.

### Reproduction

1. Boot into a normal Omarchy/Hyprland session.
2. Connect AC power.
3. Run `systemctl hibernate`.
4. Wait for power-off.
5. Power the machine back on.
6. The hibernation image restores, but Hyprland crashes immediately and restarts in recovery mode.

### Kernel evidence

During S4 resume, nouveau reports a BAR2 page-table write fault and kills GPU channels belonging to Hyprland:

```text
nouveau 0000:01:00.0: fifo: fault 01 [WRITE] ... engine 05 [BAR2] ... reason 02 [PTE]
nouveau 0000:01:00.0: fifo: ... [Hyprland[1097]] errored - disabling channel
nouveau 0000:01:00.0: Hyprland[1097]: channel 2 killed!
nouveau 0000:01:00.0: Hyprland[1097]: channel 3 killed!
```

It subsequently kills channels belonging to Xwayland and
`xdg-desktop-portal-hyprland`.

### Hyprland core dump

Hyprland aborts in Mesa Gallium while rendering the first restored frames:

```text
Signal: SIGABRT
Executable: /usr/bin/Hyprland
Command Line: Hyprland --watchdog-fd 4

libgallium-26.1.8-arch1.1.so
Render::GL::CHyprOpenGLImpl::renderRectWithDamageInternal
Render::GL::CHyprOpenGLImpl::renderRect
Render::IElementRenderer::drawRect
Render::CRenderPass::render
Render::GL::CHyprGLRenderer::endRender
Render::IHyprRenderer::renderMonitor
Monitor::CMonitorFrameScheduler::onFrame
```

Quickshell also crashes in `libgallium` immediately afterward. Its other aborts are crash-relaunch fallout after the Wayland compositor disappears.

### Checks already completed

- The hibernation image is created and restored successfully.
- The kernel command line has a valid `resume=/dev/mapper/root` and `resume_offset`.
- Swap is 31 GiB and sufficient for 16 GiB RAM.
- No OOM event occurred.
- Hyprland has no configuration errors on a normal boot.
- No `AQ_DRM_DEVICES` override is active.
- NVIDIA PCI runtime power management is already forced `on`; `nouveau.runpm=0` would not materially change the current state.
- An attempted Intel-first `AQ_DRM_DEVICES` configuration was removed because the Intel eDP output failed and Hyprland could not initialize a renderer.
- An old `i915 disable_power_well=0` experiment remains disabled.

### Related but different reports

- #5720 concerned an Intel-only MacBook deep-sleep crash and was reported fixed with Hyprland 0.55.
- #4259 concerns missing hibernation resume parameters and coredump resource usage. This machine has valid resume parameters and restores the image.
- #6888 concerns Omarchy shell lock recovery without a Hyprland crash. Here, Hyprland crashes first after nouveau kills its GPU channels.

### Request

The immediate fault appears to be in the kernel nouveau/Mesa path rather than the lock screen itself. Could Omarchy maintainers advise whether:

1. this hardware/driver combination needs an Omarchy-supported hibernation workaround;
2. Omarchy should detect or document affected nouveau MacBook configurations; or
3. this should be routed directly to nouveau/Mesa/Hyprland upstream, and if so, which component should receive the complete journal and core details?

Contact is available through the GitHub account filing this report.

Filed by GPT-5 via Codex.