Intel HD Graphics Hackintosh Guide: Fixing Black Screen, Framebuffer Injection for Sandy Bridge to Haswell

If you are building a Hackintosh around a Sandy Bridge, Ivy Bridge, or Haswell CPU and plan to rely solely on the integrated GPU, you have likely encountered the frustrating black screen after boot, the kernel panic at IOGraphicsFamily, or the system booting to a blinking cursor on a grey background. These symptoms are almost always caused by missing or incorrect framebuffer data for the Intel HD Graphics IGP. Unlike discrete GPUs, which can often be injected with a simple device-id override, Intel integrated graphics require a precise combination of ig-platform-id, device-id, and sometimes a patched framebuffer kext. This guide covers the supported HD Graphics models from 2000 through 5200, detailing the correct injection values, common pitfalls, and version-specific limitations for macOS 10.8 through 10.15.

Before proceeding, confirm that your CPU generation matches the GPU model. Sandy Bridge (2nd Gen Core) includes HD Graphics 2000 and 3000, but only HD 3000 has any real support in macOS. Ivy Bridge (3rd Gen) offers HD 2500 and 4000. Haswell (4th Gen) covers HD 4200, 4400, 4600, 5000, and 5200. The HD 4200 is almost never worth the effort — it lacks proper Metal support and exhibits severe graphical corruption in anything newer than 10.10. The same applies to HD 2500, which requires a separate framebuffer patch that disables the HDMI output entirely. For a stable system with acceleration, stick with HD 4000, 4400, 4600, 5000, or 5200.

Identifying Your GPU and Required Injection Values

The first step is to determine the exact PCI device ID of your IGP. Boot into your existing OS (or a Linux live USB) and run lspci -nn | grep VGA. You are looking for something like 8086:0162 (HD 4000) or 8086:0412 (HD 4600). Write this down — it will be needed for the device-id injection property if the default framebuffer does not load. The following table lists the most common models and their corresponding ig-platform-id values for Clover and OpenCore:

The ig-platform-id values above are the ones I have tested across dozens of builds. Do not blindly copy them — verify that your framebuffer connector map matches your display output. For example, HD 4600 with 0x0D220003 expects a single display on port 0x05 (usually the first HDMI or DVI port). If you are using a VGA monitor, you will need a different framebuffer or a patched connector map. VGA is not natively supported by any Intel framebuffer in macOS, and requires a FakePCIID injection that often breaks acceleration — avoid VGA entirely if possible.

Configuring Clover or OpenCore for Intel Graphics

The injection method differs slightly between bootloaders. In Clover, navigate to Graphics section in config.plist and set ig-platform-id as a Data value. Also set Inject Intel to true. Do not use GraphicsEnabler — that is a legacy Chameleon-era property that does not work for Intel IGPs. In OpenCore, the injection is done via DeviceProperties — add a PciRoot(0x0)/Pci(0x2,0x0) dictionary with ig-platform-id (Data, 4 bytes) and optionally device-id (Data, 4 bytes) if you are using a non-standard device ID. For example, for HD 4400 on a desktop board that reports 0x0A16, you may need to inject device-id = 0x0A260000 to match the laptop framebuffer that macOS expects.

One of the most common mistakes is using a laptop framebuffer on a desktop board, or vice versa. Desktop HD 4600 boards typically work with 0x0D220003, but some ASUS Z87 boards require 0x0D220002 (a laptop framebuffer) to get audio over HDMI. If you have audio but no video after injection, try the other framebuffer. If you have video but no HDMI audio, you need to add a hda-gfx property set to onboard-1 in the same Pci(0x2,0x0) section, and ensure your audio codec is correctly injected via AppleALC.

Dealing with Black Screen After Boot

A black screen immediately after the Apple logo usually means the framebuffer is loading but the connector map does not match your monitor. Boot with -igfxvesa boot argument to force VESA mode (no acceleration) — this confirms the GPU is alive. Then experiment with different ig-platform-id values for your generation. For HD 4000, the most compatible framebuffer is 0x01660003 (desktop, single link). For HD 4600, 0x0D220003 is the safest start. If you still get black screen, add enable-backlight-registers-fix (for laptops) or check if your BIOS sets the IGP as primary display — on some Z77 boards, you must set Initial Display Output to IGFX in BIOS, and disable CSM (Compatibility Support Module) entirely.

Kexts and Patches Required

On macOS 10.13 and newer, the WhateverGreen.kext is essential. It handles framebuffer patching, connector fixes, and backlight control automatically for most Intel IGPs. Do not use the old IntelGraphicsFixup.kext — it has been merged into WhateverGreen. For macOS 10.12 and earlier, FakePCIID_Intel_HD_Graphics.kext plus FakePCIID.kext may be needed if your device ID is not natively recognized. For example, HD 2500 requires FakePCIID to spoof as HD 4000, but this disables HDMI audio and can cause glitches in Quick Look. I strongly recommend avoiding HD 2500 unless you have no other option — the effort-to-stability ratio is poor.

For HD 5000 and 5200 (found in Iris and Iris Pro laptops), you also need AppleBacklightFixup.kext or the built-in backlight fix in WhateverGreen. Without it, the screen may be stuck at maximum brightness or completely dark. Add boot argument -igfxblr to enable backlight registers fix. If your laptop has a dual GPU (Intel + discrete), you must also disable the discrete GPU via -wegnoegpu or by injecting disable-gpu property in DeviceProperties for the discrete GPU's PCI path. Otherwise, macOS may try to switch to the unsupported discrete GPU and crash.

Version-Specific Limitations

Intel HD Graphics 4000 loses full Metal support starting in macOS 10.14 Mojave — you will get the login window and basic UI, but transparency effects will be missing, and some apps (Photos, Maps) will show a black window. This is a driver limitation that cannot be patched. HD 4400, 4600, 5000, and 5200 retain Metal 1.2 support through macOS 10.15 Catalina, but lose it entirely in Big Sur and newer. If you need a fully accelerated desktop, stay on 10.13 High Sierra or 10.15 Catalina. For HD 2500, macOS 10.13 is the last version with any real support — on 10.14 and 10.15, the GPU causes random kernel panics under memory pressure.

For a detailed walkthrough of configuring each of these IGPs with specific BIOS settings, boot arguments, and device properties, see the dedicated article on Configuring Intel HD Graphics 2500, 4000, 4400, 4600, 5000, and 5200 on Legacy Hackintosh. That guide covers the exact plist entries for Clover and OpenCore, with verified connector maps for common motherboards.

Diagnosing Sleep and Wake Issues

Intel IGPs often break sleep/wake on desktop boards. After wake, you may get a black screen or a corrupted image. The root cause is usually the framebuffer failing to reinitialize the display after the GPU enters a low-power state. Add boot argument igfxonln=1 to force the framebuffer to re-detect displays after wake. If that does not help, try igfxfw=2 (forces firmware loading) for Haswell IGPs. On Ivy Bridge, igfxfw=1 works better. For persistent wake failures, you can patch the DSDT to set _PRW to 0x0D for the PEGP device, but that is a last resort — the simpler fix is to disable sleep entirely in Energy Saver preferences and rely on display sleep only.

Backup Before You Experiment

Every time you change framebuffer values or inject new device properties, you risk a boot failure. Always keep a backup of your working config.plist on a separate USB drive. If the system fails to boot, boot from the USB installer or another working boot drive and replace the plist. For OpenCore users, keep a copy of the OC folder on an EFI partition backup. A single wrong byte in ig-platform-id can cause a kernel panic at IOGraphicsFamily that requires NVRAM reset or a bootable USB to recover. Do not skip this step — I have lost count of the number of users who overwrote their only working EFI without a backup and ended up rebuilding from scratch.

If you are running a Fusion Drive setup on a legacy Hackintosh, be especially careful when updating graphics kexts — a failed boot on a Fusion Drive can complicate recovery because the logical volume group may not mount from the recovery environment. The article on Fusion Drive on Legacy Hackintosh: The Definitive Guide explains the recovery steps for such a scenario.

For HD 4000 users who also have a legacy NVIDIA GeForce 8 or 9 series card installed as a secondary GPU, be aware that macOS may try to use the NVIDIA card for rendering, causing conflicts. Either remove the discrete GPU or inject disable-gpu for it. The guide on Getting NVIDIA GeForce 8 and 9 Series GPUs Working in a Hackintosh covers the injection properties needed to keep both GPUs functional, though I recommend sticking with a single GPU for simplicity.