## Summary

On a **Mid-2015 15-inch Retina MacBook Pro (`MacBookPro11,5`)**, blocking AMD and loading i915 did not make Intel drive the internal panel. A model-specific EFI handoff plus early `apple-gmux` loading restored actual Intel display output and graphical LUKS unlock. With `intel_iommu=sp_off`, AMD blocked and Wi-Fi MAC randomization disabled, two normal S3/deep cycles subsequently restored both display and networking.

This report concerns the display/early-initramfs compatibility gap on this model. The IOMMU and wireless failures already have related reports; they are context, not claims of a single root cause or that every failure originates in Omarchy.

## Environment

- MacBook Pro (Retina, 15-inch, Mid 2015), `MacBookPro11,5`
- Intel i7-4980HQ; Iris Pro 5200 `8086:0d26`; Radeon R9 M370X `1002:6821`
- Indexed gmux 4.0.20; Broadcom BCM43602
- Omarchy `4.0.4-1`, `7.2.5-3-omarchy`, Limine, LUKS/Btrfs

## Reproduction and observations

1. On this machine, block `amdgpu` and `radeon` and retain `intel_iommu=sp_off` to avoid the observed storage DMAR faults (#14160). The firmware AMD framebuffer remains active despite i915 loading; that is not verified Intel panel ownership.
2. Select Intel DDC/internal display through an EFI helper before loading the UKI. With the initial Haswell Port A lane allocation, i915 detects the panel but rejects native 2880×1800 with `CLOCK_HIGH`.
3. Allocate four lanes before i915 starts, while Port A/E are disabled. EFI register readback `0x81 → 0x91` enables native Intel output; Linux reports four lanes at 2.7 Gbit/s, 24 bpp.
4. Disable stale simpledrm/efifb initialization. The ghost AMD monitor disappears, but the unlock prompt remains invisible: i915 defers until `apple-gmux` loads only after encrypted root unlock. i915 was present in the original initramfs; apple-gmux was absent.
5. Include/load `apple-gmux` and i915 early. The text unlock prompt appears; retaining `splash` restores graphical Plymouth unlock. The same helper/configuration then passes reboot and S3 display restoration tests.

## Tested configuration

```bash
# /etc/mkinitcpio.conf.d/zz-intel-display.conf
MODULES+=(apple-gmux i915)
```

Relevant parameters, in addition to the installation's own encryption/root arguments:

```text
modprobe.blacklist=amdgpu,radeon module_blacklist=amdgpu,radeon intel_iommu=sp_off initcall_blacklist=simpledrm_platform_driver_init,efifb_driver_init mem_sleep_default=deep initramfs_async=0 splash
```

The EFI helper checks the DMI model, GPU identity, gmux version and disabled Port A/E registers; selects Intel with verified readback; and chainloads the maintained Omarchy UKI. It makes no NVRAM writes, GPU power changes or external-display mux changes. Recovery bypasses the helper.

Source/documentation repository: https://github.com/bbatchelder/macbookpro11-5-intel-efi

## Wi-Fi: normal S3 required one additional setting

The first normal S3 cycle restored the display but left Broadcom firmware commands timing out with `-5` until reboot. NetworkManager changed the scanning MAC during suspend preparation. Raw-kernel suspend tests had bypassed that preparation.

After disabling MAC randomization:

```ini
[device]
wifi.scan-rand-mac-address=no

[connection]
wifi.cloned-mac-address=permanent
```

The saved Wi-Fi profile was also set to `802-11-wireless.cloned-mac-address=permanent`. Pre-existing power-save-off and `brcmfmac feature_disable=0x82000` settings were retained. Two normal S3 cycles on October 12, 2026 had entry-to-exit intervals of 28 and 47 seconds; Wi-Fi reconnected 3–4 seconds after resume. No MAC changes, firmware-command timeouts, IOMMU faults, GPU hangs or storage errors appeared in those cycles.

This is a successful comparison, not proof of the exact Broadcom mechanism or long-term reliability. ARP-table `-52` and SATA `_GTF` warnings remained. Live `brcmfmac_wcc` unloading had previously oopsed in `_cfg80211_unregister_wdev`, so no driver-reload sleep hook was used.

## Scope and related reports

Only this MacBookPro11,5 has been tested. Overnight S3, endurance, external displays, AMD power-off/battery drain, hibernation and other Mac models remain untested. A separate raw-kernel S3 test spent approximately 126 seconds asleep with successful display restoration but is weaker Wi-Fi evidence.

Related: #14160 (IOMMU/storage), #12550 (AMD/IOMMU boot), #13510 (early Intel KMS), #11377 (Broadcom suspend), #10332 (wireless reload workaround), #11382 (AMD power tradeoff).

The actionable Omarchy configuration finding is that on this model early i915 alone was insufficient: early apple-gmux was required for the unlock display. The repository documents the additional EFI/lane handoff and recovery rather than proposing a blanket quirk for every Intel Mac.

Filed by GPT-6 via Codex.