Wake on Bluetooth on a Legacy Hackintosh: A Practical Guide

You close the lid on your Hackintosh laptop or let your desktop idle overnight. Next morning, you click a Bluetooth mouse or tap a key on your wireless keyboard. Nothing. The system is still asleep, and no amount of clicking will bring it back. Wake on Bluetooth—the ability to rouse a sleeping system from S3 (suspend-to-RAM) using a paired Bluetooth device—is something Apple hardware handles without a second thought. On a custom PC, it depends on a fragile chain: the Bluetooth controller, its USB connection, the XHCI/EHCI hand-off, and a set of ACPI power states that must be correctly negotiated. For legacy Hackintosh builds (pre-2017 hardware, older macOS versions), the situation is even more delicate because the Bluetooth stack in macOS 10.13 and earlier relies on Broadcom and CSR chips that are no longer officially supported. This guide walks you through the practical steps to get wake-on-Bluetooth working, or at least to diagnose why it refuses to cooperate.

How Wake on Bluetooth Works in macOS

Unlike wake-on-LAN, which is handled by the Ethernet controller and the motherboard's firmware, wake-on-Bluetooth is a host-side feature. The Bluetooth controller is a USB device; when the system enters sleep, the USB bus is powered down, but the root hub may still provide a small amount of current to keep the controller alive. The controller listens for a specific wake pattern—usually a connection request from a paired device—and signals the host via a remote wake-up event on the USB bus. The ACPI subsystem then wakes the CPU and resumes the system.

For this to work, three conditions must be met:

• The Bluetooth controller must support remote wake-up (most Broadcom and CSR controllers do).
• The USB port to which the controller is attached must be configured to allow wake-up in the ACPI tables.
• macOS must have the appropriate Bluetooth stack loaded and the device must be paired as a trusted device.

On a real Mac, the firmware (EFI) and the SMC handle these details transparently. On a Hackintosh, you are responsible for recreating them with ACPI patches and USB port configuration.

Common Obstacles on Legacy Hardware

The most frequent reason wake-on-Bluetooth fails on a Hackintosh is that the Bluetooth adapter is plugged into a USB port that is not marked as “wake-capable” in the ACPI tables. Many motherboard manufacturers mark only the top-left rear USB port as wake-enabled (for keyboard/mouse wake), and Bluetooth adapters are often plugged into a different port. Even if the port supports wake, the XHCI (USB 3.0) controller may not forward the remote wake signal correctly unless the _PRW (Power Resource for Wake) method is present in the ACPI namespace.

Another issue is the Bluetooth driver itself. In macOS 10.11 through 10.13, the IOBluetoothFamily kext expects the controller to be attached to an internal USB port (often labeled Internal or 0 in the port mapping). If the controller is on a regular external port, macOS may not enable the wake feature even if the hardware supports it. This is why many Hackintosh users have success with a Bluetooth card that connects to an internal USB header (like the BCM94360CD or BCM94331CD) rather than a USB dongle.

Step-by-Step Configuration

1. Identify Your Bluetooth Controller

First, confirm the exact model of your Bluetooth adapter. On a legacy Hackintosh, the most reliable chips are Broadcom BCM20702 (found in many Apple-compatible cards) and CSR 4.0 dongles. You can check with ioreg or the System Information app under the Bluetooth section. If you see “Apple Broadcom” in the vendor string, you are in good shape. If you see a generic “Cambridge Silicon Radio” or worse, an Intel chip, wake-on-Bluetooth may not be supported at all—Intel Bluetooth controllers were never supported by macOS until very recent versions, and even then only on Apple Silicon.

2. Map Your USB Ports

USB port mapping is critical. On legacy systems (especially with Intel 8/9-series chipsets), you can use a custom SSDT to rename the USB controllers and define the port capabilities. If you have not already created a USB port map, do that first. The goal is to assign the Bluetooth controller to an internal port (type 0xFF or Internal) and ensure that the port has the _PRW method pointing to the correct GPE (General Purpose Event).

For example, on a Gigabyte Z97 board, the Bluetooth header is often on the F_USB30 connector. In your SSDT-USB, you would define a port with UsbConnector=10 (internal) and add a _PRW that references GPE 0x0D (the typical wake GPE for USB on that platform). This is not a one-size-fits-all; you must check your motherboard's ACPI tables to find the correct GPE.

3. Patch ACPI for Wake Support

If your Bluetooth controller is on a USB port that does not have _PRW, you have two options: patch the DSDT to add the method, or use a bootloader-level ACPI patch (Clover or OpenCore) to inject a fake _PRW for that port. The latter is safer because it does not modify the firmware. In Clover, you can use the DSDT → Patches section to find and replace the _PRW for the specific USB port. However, this approach is brittle because the port numbering can change if you move the adapter.

A more reliable method is to create a custom SSDT that defines a _PRW for the Bluetooth device's parent port. You can load this SSDT with Clover or OpenCore. Here is a minimal example for a Broadcom adapter on port PR11:

DefinitionBlock ("", "SSDT", 2, "HACK", "BT_WAKE", 0x00000001)
{
    External (_SB.PCI0.XHCI.RHUB.PR11, DeviceObj)
    Scope (_SB.PCI0.XHCI.RHUB.PR11)
    {
        Method (_PRW, 0, NotSerialized)
        {
            Return (GPRW (0x0D, 0x04))
        }
    }
}

This SSDT assumes your motherboard uses GPE 0x0D and that the port is under the XHCI root hub. You will need to adjust the path and the GPE number based on your own IORegistry dump. If you are not comfortable writing ACPI tables, consider using a pre-built SSDT from a repository that matches your motherboard model—but always verify the GPE number with a tool like acpidump before relying on it.

4. Ensure the Bluetooth Kext Is Loaded

On macOS 10.13 and earlier, the Bluetooth stack is part of the system. You do not need extra kexts for a Broadcom adapter, but you may need to inject BrcmPatchRAM if you are using a BCM20702 that requires a firmware upload. That kext is not related to wake, but it ensures the controller is fully functional. For CSR dongles, the situation is trickier: some CSR 4.0 dongles work out of the box, but wake support is inconsistent. If you have a CSR dongle and wake does not work, the hardware likely does not support remote wake—there is no software fix for that.

5. Configure macOS Power Settings

Even with the correct ACPI setup, macOS must be told to allow Bluetooth wake. In System Preferences → Energy Saver, there is a checkbox “Allow Bluetooth devices to wake this computer.” On a Hackintosh, this option may be greyed out or missing if the Bluetooth controller is not recognized as an internal device. If it is missing, you can try forcing the feature with a defaults write command:

sudo defaults write /Library/Preferences/com.apple.Bluetooth.plist ControllerPowerState -int 1

But this is not a reliable fix; the real solution is to make the adapter appear as internal in the USB port map.

Testing and Diagnostics

After making changes, reboot and test. Put the system to sleep manually (or let it idle), then try to wake it with your Bluetooth keyboard. If it does not wake, check the system log for clues:

log show --last 5m | grep -i "wake"

Look for lines that mention DarkWake or USB. If you see USB device caused wake with your Bluetooth controller's address, then the wake event was recognized but the system may have failed to fully resume—possibly due to a graphics driver issue. If you see nothing, the wake signal is not reaching the chipset.

Another diagnostic is to check the _PRW status in IORegistry. Open IORegistryExplorer and navigate to your Bluetooth device. If the device has a _PRW entry, it will appear as a property. If not, your ACPI patch is not being applied. For a detailed guide on using IORegistryExplorer for diagnostics, refer to our previous article on Custom SSDTs for Legacy Hackintosh: Fixing EC, Ethernet, and CPU Power Management—the same principles apply to USB wake.

Hardware-Specific Notes

Broadcom BCM94360CD (Apple Card)

This card is the gold standard for Hackintosh Bluetooth and Wi-Fi. It connects via a PCIe adapter and an internal USB header. When properly mapped, wake-on-Bluetooth works almost out of the box, and it supports all macOS versions up to Catalina. If you are using this card, ensure the USB header is connected to a port that is set to internal in your USB map. On some motherboards, the header shares a port with another internal device; you may need to disable the other device to avoid conflicts.

Broadcom BCM94331CD (AirPort Extreme)

This card is common in Mac Pro 2010-2012 and is also used in Hackintoshes. It works well on macOS Mojave and earlier. The wake behavior is similar to the 94360CD, but the Bluetooth chip is older and may not support wake on all systems. If you have this card and wake fails, try a different USB header—some headers have power management quirks.

CSR 4.0 USB Dongles

These dongles are cheap and often work for basic Bluetooth, but wake support is a lottery. Many CSR dongles do not implement the remote wake feature in their firmware. If you need reliable wake, do not rely on a dongle; invest in a Broadcom card. For testing, you can try plugging the dongle into a different USB port, but do not expect miracles.

Interaction with Graphics and Other Wake Sources

Wake-on-Bluetooth is often affected by graphics issues. If your system wakes from Bluetooth but the display stays black, the problem is not Bluetooth—it is the graphics card failing to reinitialize. On legacy NVIDIA GPUs, this is a common issue with macOS 10.13 and later. For Kepler cards, you may need to inject the correct framebuffer or use a boot flag like nvda_drv=1 (for older drivers). We have covered this in detail in our guide on NVIDIA Kepler GPU Configuration for macOS 13 Ventura Hackintosh, but the same principles apply to earlier versions: ensure the GPU is properly initialized before expecting any wake source to work.

Also, if you have an Ethernet cable connected, wake-on-LAN may be enabled by default and could interfere with Bluetooth wake. Disable wake-on-LAN in System Preferences → Energy Saver if you are not using it.

Preserving Your Configuration

Once you have wake-on-Bluetooth working, document every change you made: the SSDT patch, the USB port map, the GPE number. Store these files in your EFI partition and back them up. Legacy Hackintosh systems are fragile; a single update to macOS or a BIOS reset can break the ACPI patches. If you ever need to rebuild, having a clear record of your wake configuration will save hours of troubleshooting. For a comprehensive approach to archiving your build, see our guide on How to Set Up iMessage and iCloud on a Legacy Hackintosh (Clover/OpenCore)—the same backup discipline applies to ACPI tables and kexts.

Final Thoughts: When to Give Up

Not every Hackintosh can achieve wake-on-Bluetooth. If you have tried the steps above and your Bluetooth adapter still does not wake the system, it may be a hardware limitation. In that case, consider using a USB-connected keyboard or mouse that supports wake (many do), or leave the system in a power state that does not require Bluetooth wake—for example, disable sleep and use display sleep only. The energy savings are minimal compared to the frustration of an unreliable wake.

Remember to always back up your data before making ACPI or kext changes. A misconfigured SSDT can prevent your system from booting, and without a backup you may lose access to your files. Test each change incrementally, and keep a known-good EFI folder on a USB drive.

Wake-on-Bluetooth is a convenience, not a necessity. With the right hardware and a bit of ACPI work, it can be a satisfying feature to have on a legacy Hackintosh. But if it does not work, do not let it ruin your build—there are always workarounds.