### System details

MacBook Pro (16-inch, 2019) — `MacBookPro16,1`, T2. Omarchy 4.0.2, kernel `7.1.8-arch1-Watanare-T2-3-t2`.
Hybrid graphics: Intel UHD 630 (`i915`) + AMD Navi 14 / Radeon Pro 5300M-5500M (`amdgpu`).

### What's wrong?

On a clean install, the machine reaches the graphical login screen, and then dies a few
seconds after the session starts: screen goes black, fans ramp to 100%, and the machine
hard powers off roughly 60 seconds later. Repeatable on every boot.

`fix-t2.sh` is doing its job — `linux-t2` is installed, the keyboard works, Wi-Fi firmware
loads, `t2fanrd` runs. The failure is specifically graphics.

### Root cause

On hybrid-graphics T2 Macs the `gmux` mux chip hands the internal panel to the **AMD dGPU**
by default. `amdgpu` initialises cleanly, so the login screen renders — but the machine
hard-hangs once an accelerated Hyprland session actually runs on it.

Evidence from the affected machine:

```
i915 0000:00:02.0: [drm] Cannot find any crtc or sizes
```

The Intel iGPU has no display attached, confirming the panel is on the dGPU.

Booting with `systemd.unit=multi-user.target` is completely stable indefinitely, which
isolates the fault to the accelerated session rather than the kernel, T2 or thermals.

`journalctl --list-boots` shows every failed boot recording only 4-5 seconds despite the
machine being alive for ~60s, i.e. the journal is truncated by the power cut. Anyone
debugging this will need `SyncIntervalSec=1s` in `journald.conf.d` to capture anything.

**Red herring worth documenting:** these machines log `mce: [Hardware Error]` for banks 12
and 13 on *every* boot, including known-healthy ones — stale banks left dirty by Apple's
firmware. They look alarming next to a hard power-off but are not related to this bug.

### Fix

Booting with `apple_gmux.force_igd=1` routes the internal panel to the Intel iGPU and the
machine is stable, and survives reboots when persisted via
`/etc/modprobe.d/apple-gmux.conf` containing `options apple-gmux force_igd=y`.
This is the documented approach on the t2linux wiki:
https://wiki.t2linux.org/guides/hybrid-graphics/

`vgaswitcheroo` confirms the panel moved to the iGPU:

```
0:DIS-Audio: :DynOff:0000:03:00.1
1:IGD:+:Pwr:0000:00:02.0
2:DIS: :Pwr:0000:03:00.0
```

After the fix, `amdgpu` logs `*ERROR* No EDID read` for `eDP-2` — it still owns the internal
panel's connector but can no longer read its EDID. Cosmetic, and expected once the mux has
moved.

Kernel version was identical (`7.1.8-arch1-Watanare-T2-3-t2`) before and after, and the fix
was verified on a boot where `force_igd` was the only thing changed, so this is not a
package-update artifact.

### Proposed patch to `install/hardware/apple/fix-t2.sh`

Gated on *both* GPUs actually being present, so it is a no-op on the 13-inch T2 models that
have no dGPU:

```bash
  # On hybrid-graphics T2 Macs (15"/16"), gmux gives the internal panel to the AMD
  # dGPU by default. amdgpu initialises fine, so a greeter renders, but the machine
  # hard-hangs once an accelerated session runs on it: fans to 100%, T2 cuts power
  # after ~60s, MCE banks 12/13 report the fault on the next boot. Hand the panel to
  # the Intel iGPU instead. See https://wiki.t2linux.org/guides/hybrid-graphics/
  if lspci -nn | grep -E 'VGA|Display' | grep -q '8086:' &&
    lspci -nn | grep -E 'VGA|Display' | grep -q '1002:'; then
    cat > /etc/modprobe.d/apple-gmux.conf <<'EOF'
# Generated by Omarchy installer for hybrid-graphics T2 Macs
options apple-gmux force_igd=y
EOF
  fi
```

### Open questions before this should land

- **n=1 so far.** This is one machine. Corroboration from other 15"/16" T2 owners would be
  good — there are several reports of the same symptom in discussion #773.
- **External displays.** On these models the external outputs are wired to the dGPU. I have
  not yet tested whether `force_igd` affects external monitor behaviour, and that is the
  main regression risk for anyone whose machine currently works.
- Should this be a default, or opt-in? Defaulting it fixes machines that are currently
  unusable, but changes the panel's GPU for anyone already working fine.
- Related: #1844 (closed) proposed a full GPU switcher for exactly this hardware. This is a
  deliberately much smaller change in the style of the existing `brcmfmac.conf` block.