Wake on Bluetooth on a Hackintosh: Hardware, Kexts, and ACPI Patches for macOS 10.10–10.13

Wake on Bluetooth (WoB) lets a Hackintosh exit sleep when a paired Bluetooth keyboard, mouse, or trackpad sends a connection request. On genuine Macs, this behavior is native to the Broadcom Bluetooth controllers Apple uses. On a custom PC, achieving reliable WoB requires a specific combination of hardware, kexts, and ACPI configuration — and the process differs between macOS versions. This guide covers the requirements for macOS Yosemite 10.10 through High Sierra 10.13, with emphasis on the limitations you must respect.

<>

Hardware Requirements

The only Bluetooth modules that support WoB reliably on a Hackintosh are those that present a native Apple HCI interface. The most common candidates are:

• Broadcom BCM94360CD (Apple 802.11ac + Bluetooth 4.0) — used in iMac Late 2013 and MacBook Air Mid 2013. This is the gold standard; it works out of the box with macOS.
• Broadcom BCM94360CS2 (Bluetooth 4.0) — found in MacBook Air Mid 2012. Requires a PCIe adapter.
• Broadcom BCM94331CD (Bluetooth 4.0) — older, but still functional.
• AzureWave AW-CB160H (rebranded BCM94360CS2) — same chipset.

Cards based on Intel Bluetooth chips (e.g., Intel 8260, 9260) do not support WoB on macOS because macOS lacks the necessary driver for their firmware. Similarly, USB Bluetooth dongles using the CSR chipset (common in cheap adapters) rarely support wake from sleep without dirty hacks and are not recommended.

Firmware and macOS Version Considerations

Bluetooth 4.0 (Bluetooth Low Energy) support in macOS began with OS X Mountain Lion 10.8, but WoB over BLE was only fully exposed in the UI starting with Yosemite 10.10. On El Capitan 10.11 and later, the system preferences pane includes a checkbox “Allow Bluetooth devices to wake this computer”. On Yosemite, you may need to enable it via the command line:

sudo defaults write /Library/Preferences/com.apple.Bluetooth.plist BluetoothAutoWakeOnHost 1

On High Sierra 10.13, the setting is in System Preferences → Bluetooth → Advanced. If the checkbox is missing, your Bluetooth module is not recognized as a native Apple HCI device.

For macOS Mojave 10.14 and later, the Bluetooth stack changed significantly and many legacy Broadcom cards require additional patches. This guide explicitly covers only 10.10 through 10.13.

Required Kexts

Even with a native Apple Broadcom card, you may need a few kexts to ensure proper handoff between the Bluetooth controller and the system’s sleep management:

1. BrcmPatchRAM2.kext (or BrcmPatchRAM3.kext for older cards) — injects firmware into the Bluetooth chip. Without it, the card may not initialize correctly after wake.
2. BrcmFirmwareRepo.kext — companion kext that stores the firmware blob.
3. BrcmBluetoothInjector.kext — injects personality data into IORegistry so macOS recognizes the card as Apple.

These kexts are loaded from the bootloader (Clover or OpenCore) in the EFI/OC/Kexts or /EFI/CLOVER/kexts/Other folder. For older macOS versions, you may need to use the BrcmPatchRAM.kext (the original version).

ACPI Patches for Wake on Bluetooth

Even with the correct hardware and kexts, WoB may fail because the USB port to which the Bluetooth controller is connected is not set to wake the system. The Bluetooth module on a Broadcom card is usually a USB device inside the card (e.g., USB address 05ac:828d). The operating system’s ACPI tables must declare the wake capability for that USB port.

On most Z77, Z87, and Z97 motherboards, the port is hardwired to a USB 2.0 root hub. You can create an SSDT that sets the _PRW (Power Resource for Wake) method on that port. A typical SSDT snippet looks like this:

Scope (_SB.PCI0.XHC)
{
    Device (BRCM)
    {
        Name (_ADR, 0x00140000)  // Address of the USB port
        Method (_PRW, 0, NotSerialized)
        {
            Return (Package (0x02)
            {
                0x0D,  // GPE number, varies by board
                0x03   // Deepest sleep state from which wake is allowed
            })
        }
    }
}

The exact GPE number and the USB port address vary by motherboard. For a detailed guide on creating such SSDTs, refer to the article on Custom SSDTs for Legacy Hackintosh: Fixing EC, Ethernet, and CPU Power Management — the same principles apply to Bluetooth wake.

If you are using a PCIe adapter for the Bluetooth card, the USB controller is often the Chipset’s EHCI or XHCI, and the Bluetooth device appears as a child of the USB controller. Use IORegistryExplorer to locate the correct _ADR. The blog already has extensive guides on using IORegistryExplorer, such as How to Set Up iMessage and iCloud on a Legacy Hackintosh (Clover/OpenCore) — the same registry scanning technique applies to finding Bluetooth device paths.

Diagnosing Wake Failures

When WoB does not work, the problem is usually one of the following:

• Bluetooth module not recognized as Apple HCI. Check IORegistry — the IOClass should be IOBluetoothHCIController or AppleBroadcomBluetoothHostController. If you see IOBluetoothHCIController with a vendor ID other than 0x05AC, the personality injection failed.
• Sleep state mismatch. Some motherboards do not correctly wake from S3 (Suspend to RAM) on USB signal. Try setting the BIOS sleep mode to S3 only, and disable “Wake on LAN” if it conflicts with USB wake.
• USB port power delivery. After sleep, the USB port may lose power entirely. Check if the Bluetooth module’s LED turns off. If it does, you need to adjust the _PRW method to supply a higher power resource or use a different USB port.
• Bluetooth controller firmware not re-loaded. If the firmware does not persist after sleep, the card stops responding. This is why BrcmPatchRAM kexts are essential.

<>

Risks and Data Integrity

Modifying ACPI tables carries a risk of system instability. A malformed SSDT can prevent the system from booting, cause kernel panics on wake, or corrupt the NVRAM if the bootloader misapplies the patch. Always create a backup of your current EFI folder before adding any SSDTs. Keep a bootable USB installer with a known-good EFI partition so you can recover if the system fails to boot.

Test WoB with a single Bluetooth device (e.g., Apple Magic Mouse) before connecting multiple peripherals. Some third-party Bluetooth keyboards and mice do not send the correct wake-up signal, even if the Hackintosh side is properly configured.

Concrete Example: Z97X-UD5H + BCM94360CD

On a Gigabyte Z97X-UD5H motherboard with a Broadcom BCM94360CD card installed in a PCIe x1 slot, the Bluetooth device appears at USB address _ADR = 0x00140000 under the XHC controller. The GPE for USB wake on this board is 0x0D. The SSDT that enables WoB is:

DefinitionBlock ("", "SSDT", 2, "HACK", "BTWAK", 0x00000000)
{
    External (_SB.PCI0.XHC, DeviceObj)
    Scope (_SB.PCI0.XHC)
    {
        Device (BT00)
        {
            Name (_ADR, 0x00140000)
            Method (_PRW, 0, NotSerialized)
            {
                Return (Package (0x02) { 0x0D, 0x03 })
            }
        }
    }
}

Compile this with iasl to a .aml file and place it in EFI/OC/ACPI (OpenCore) or EFI/CLOVER/ACPI/patched (Clover). After rebuilding the kext cache and rebooting, the system should wake when the Bluetooth mouse is moved or a key is pressed on the Magic Keyboard.