Fixing Intel HD Graphics on Haswell and Broadwell Hackintoshes

Intel HD Graphics on Haswell and Broadwell Hackintoshes is notoriously finicky. Unlike discrete GPUs, where a single injection flag or framebuffer patch can resolve most issues, the iGPU demands precise alignment between the platform ID, framebuffer layout, connector mapping, and the version of macOS you intend to run. This guide covers HD Graphics 4200, 4400, 4600, 5000, 5200, 5300, and 5500 — the seven iGPU variants in Haswell (4th-gen Core) and Broadwell (5th-gen Core) processors. It does not cover HD 2500, 4000, or Iris Pro models; those are addressed in the separate guide on Clover Injection Level 4: Fixing GPU Issues on Legacy Hackintosh Systems.

Identifying Your iGPU Generation and Device ID

First, confirm the exact model of your iGPU. The four most common Haswell device IDs are 0x0412 (HD 4600, mobile), 0x0416 (HD 4600, desktop), 0x0A16 (HD 4400), and 0x0D22 (HD 4200). Broadwell iGPUs use IDs starting with 0x16, 0x26, or 0x46, depending on the SKU. A quick check in Windows Device Manager (under Display adapters) or in macOS System Information after a failed boot can reveal the hardware ID. Write this down; you will need it to select the correct framebuffer kext patch or platform injection in your bootloader configuration.

Platform IDs and Their Framebuffer Layouts

In Clover or OpenCore, the iGPU is configured via the ig-platform-id property. Each platform ID corresponds to a specific framebuffer layout that defines the number and type of display outputs (LVDS, HDMI, DP, eDP), the memory allocation for the GPU, and the connector order. Using the wrong platform ID can cause black screen, kernel panic on boot, or broken sleep/wake. Below is a table of tested platform IDs for the seven iGPUs covered here, with the macOS versions where they are known to work without auxiliary patches.

All platform IDs above are given in hexadecimal. In Clover’s config.plist, they go under Devices/Properties or Graphics/Inject/Intel depending on your bootloader version. In OpenCore, they are set via DeviceProperties/Add with the key ig-platform-id as a data value (four bytes, little-endian).

Common Symptoms of Misconfigured iGPU

A wrong platform ID typically manifests as one of three failure modes: a black screen immediately after the Apple logo (iGPU initialized but display output not connected), a boot loop with a panic mentioning “AppleIntelFramebuffer” (framebuffer mismatch), or a perfectly booting system that wakes from sleep to a garbled or frozen screen. The last symptom is especially common with HD 5000 and HD 5200 when using a platform ID designed for a different connector arrangement. If you see any of these, switch to a different platform ID from the table or try a framebuffer patching kext.

Using WhateverGreen for Modern Compatibility

For macOS 10.13 High Sierra through 10.15 Catalina, the combination of Lilu and WhateverGreen (both open-source kernel extensions) makes iGPU configuration much easier. Instead of manually editing framebuffer connectors, you can inject the correct platform ID and let WhateverGreen apply automatic patches for common issues like black screen on HDMI hot-plug, broken sleep, and wrong connector type. The kext reads your hardware’s device ID and applies a built-in mapping table. For HD 4600 on Mojave, for example, you can set ig-platform-id to 0300220D (the byte-swapped version of 0x0D220003) and let WhateverGreen handle the rest. Always test without the kext first to isolate hardware-specific problems; then add Lilu + WhateverGreen as the last resort for stubborn systems.

If you are building a system that combines an iGPU with a discrete GPU for compute tasks (e.g., using the iGPU only for display and a Radeon for rendering), you must also inject disable-external-gpu or enable-gpu properties. This is covered in depth in the article on GPU Injection for macOS Sonoma: Keeping Kepler and GCN 1.0/1.1 Cards Alive, but the principle applies to older macOS versions as well: the iGPU must be told to ignore the discrete GPU, or vice versa, to avoid resource conflicts.

Connector Patching for Dual-Monitor and Laptop eDP

Desktop users often connect two monitors via HDMI and DVI or DisplayPort. The framebuffer layout for a given platform ID may have only one connector mapped to an active output, leaving the second monitor dark. To fix this, you need to patch the connector type or index in the framebuffer kext. Tools like Hackintool (macOS) or a manual hex edit of the AppleIntelFramebuffer kext can reassign a disabled connector (type 0x0400) to an enabled one (type 0x00080000 for HDMI, 0x00040000 for DP). Always make a backup of the kext before modifying it, and verify the checksum after patching. On laptops with eDP (embedded DisplayPort), the internal panel is usually on connector index 0. If the screen remains black after boot, swap connector indices 0 and 2 in the framebuffer to match the hardware wiring.

Boot Arguments and NVRAM Settings

Three boot arguments frequently rescue a stuck iGPU configuration:

• -igfxvesa — Forces the iGPU into VESA compatibility mode, disabling hardware acceleration. Use this only to reach the desktop and diagnose the correct platform ID; do not leave it active for normal use.
• igfxonln=1 — Forces the iGPU to treat all connected displays as online, bypassing the detection logic. Helpful for HD 4400/4600 on 10.13+ where one monitor stays black.
• -disablegfxfirmware — Disables the graphics firmware loading on Broadwell iGPUs (HD 5300/5500). Required for macOS 10.15 Catalina if you see a hang at “IOConsoleUsers: gIOScreenLockState”.

Set these in your bootloader’s boot-args (NVRAM or config.plist). Remove them one by one after the system stabilizes to confirm which fix is essential.

Sleep/Wake Reliability with iGPU

Sleep/wake failures are the second most common complaint after black screen. The root cause is often the framebuffer not reinitializing the display after the iGPU enters a low-power state. On Haswell systems, the darkwake boot argument can help: darkwake=0 (disable dark wake), darkwake=1 (enable dark wake), or darkwake=8 (force full wake). Experiment with these values while also ensuring that your ACPI tables (DSDT/SSDT) have proper _WAK methods. A corrupted or missing _WAK can prevent the iGPU from restoring its framebuffer. If you are using a custom SSDT for USB power management, verify that it does not conflict with the iGPU’s power domain.

For a deeper dive into ACPI patching for sleep, refer to the existing blog posts on hardware configuration; the same DSDT fixes that resolve USB wake also stabilize iGPU sleep.

Backup Strategy Before Patching

Before you modify any framebuffer kext, inject a platform ID, or add a boot argument, create a full backup of your current boot drive (using Time Machine or a disk image) and a separate backup of your EFI partition. A wrong iGPU patch can render the system unbootable even in single-user mode, leaving you with no way to revert except by booting from a USB installer. Keep a known-good EFI folder on a USB stick that you can plug in at any time. This precaution is especially important when experimenting with connector patches on laptop eDP, as the internal display may never come back without a hardware reset.

One final practical tip: if you are dual-booting Windows and macOS on the same machine, disable the iGPU in the Windows boot entry (via bcdedit or the BIOS) to prevent Windows from loading a driver that alters the iGPU’s firmware state. A Windows driver update has been known to corrupt the GOP driver on Haswell iGPUs, leading to a black screen in macOS on the next reboot. Keep the iGPU enabled in BIOS but ensure that Windows does not claim it as a primary display device.