Controlling Wake on Bluetooth 3 on Legacy Hackintosh Builds

Building a Hackintosh with a Broadcom BCM94360CS2 or similar Bluetooth 3.0 module often means dealing with random wake-from-sleep issues. The Bluetooth controller is the usual suspect: macOS treats it as a valid wake source, so any incoming packet — a mouse twitch, a keyboard press, or even a stray signal from a nearby device — can yank the system out of sleep. On a genuine Mac, Apple's firmware handles this. On a custom PC, you either replicate that logic yourself or kill the feature entirely. This guide walks through the practical options for controlling Wake on Bluetooth 3 on legacy Hackintosh builds, from simple system settings to ACPI-level patches.

Understanding the Wake Source

Wake on Bluetooth isn't a single toggle. It involves several layers:

• USB stack: The Bluetooth adapter usually connects via an internal USB header. macOS sees it as a USB device, and USB wake is enabled by default for most devices.
• ACPI power state: The _PRW (Power Resources for Wake) method tied to the USB port or Bluetooth device decides whether the system can be woken by that device.
• macOS power management: The pmset command exposes settings like womp (Wake on Magic Packet) and powernap, but Bluetooth wake is controlled by the IOKit power plane, not directly by pmset.

On a real Mac, the firmware and SMC filter which Bluetooth events can wake the system. On a Hackintosh, that filtering is often missing, so any Bluetooth activity can wake the machine.

Step 1: Check Your Current Wake Sources

Before changing anything, find out what's actually waking your system. Open Terminal and run:

pmset -g log | grep -i "wake from" | tail -20

This shows the last few wake events and their causes. If you see ECD or USB entries, that points to the Bluetooth adapter. You can also use pmset -g assertions to see if any process is holding a wake assertion.

Step 2: Disable Bluetooth Wake via System Preferences

The simplest fix is to tell macOS not to allow Bluetooth devices to wake the computer. Open System Preferences > Bluetooth > Advanced (or on newer versions, System Settings > Bluetooth > Advanced). Uncheck "Allow Bluetooth devices to wake this computer". This works on most Hackintosh builds, but not all. If the option is missing or greyed out, proceed to the next steps.

Note that this setting only affects the Bluetooth stack's own wake behavior. It does not prevent a USB-level wake if the adapter's port is configured as a wake source in ACPI.

Step 3: USB Port Mapping and Wake Control

On legacy Hackintoshes (especially those running macOS 10.13 or earlier), USB port mapping is critical. If your Bluetooth adapter is on a port that is not correctly mapped, macOS may treat it as an internal device with wake enabled by default. Use Hackintool or IORegistryExplorer to identify the port and its capabilities.

In your USB port map (often in a SSDT or a kext like USBInjectAll.kext), you can set the UsbConnector type to 255 (internal) and remove the _PRW method for that port. This prevents the port from being a wake source. If you are using a custom SSDT for USB, you can also add a _PRW that returns 0x0D (wake disabled) for the Bluetooth port.

For a detailed walkthrough of creating custom SSDTs for USB and other devices, see our SSDT Creation Guide for Legacy Hackintosh: DSDT Disassembly and Hotpatch Basics.

Step 4: ACPI _PRW Patching

If the Bluetooth adapter is enumerated as a separate device in ACPI (e.g., RP05.PXSX or USB2), you can patch its _PRW method to disable wake. The _PRW method returns a package with two elements: the wake resource and the wake enable bit. Setting the second element to 0 usually disables wake.

For example, if your Bluetooth device has a _PRW that returns 0x0D, you can create a SSDT that overrides this method with Return (Package () { 0x0D, 0x00 }). This tells the system that the device cannot wake the machine.

Be careful when patching _PRW — a mistake can prevent the system from sleeping at all. Always test with a single change and keep a backup of your current ACPI tables.

Step 5: Using the DarkWake and PowerNap Settings

Sometimes the wake is not a full wake but a DarkWake (the system wakes briefly to perform background tasks). If you see DarkWake in your logs, you can disable PowerNap:

sudo pmset -a powernap 0

This stops scheduled network and maintenance wakes. However, it does not affect Bluetooth-triggered wakes directly.

Step 6: Hardware-Level Options

If software solutions fail, you can disable Bluetooth wake at the hardware level. On some Broadcom modules, you can cut the WAKE# pin from the USB header. This pin is used to signal a wake event to the chipset. If you disconnect it, the Bluetooth module cannot request a wake. This is a permanent modification, so only do it if you are comfortable with soldering and have a spare module.

Another option is to use a USB hub that has per-port power control, but that is often impractical for internal Bluetooth.

Step 7: Testing and Logging

After making changes, test sleep and wake manually:

sudo pmset sleepnow

Then wake the system with a keyboard or mouse and check the log:

pmset -g log | grep -i "wake from" | tail -5

If the wake source still shows USB but you have disabled the port's _PRW, double-check that your SSDT is loaded and that there are no conflicting patches.

Common Pitfalls

• Multiple Bluetooth devices: If you have both an internal and an external Bluetooth adapter, disable wake on the one you are not using.
• USB port mapping conflicts: A misconfigured port map can re-enable wake on a port you intended to disable.
• ACPI patch order: If you are using Clover's ACPI patching, make sure your _PRW override is applied after the original table is loaded.

Bluetooth 3.0 vs 4.0 and Later

Bluetooth 3.0 modules (like the BCM94331PCIEBT) use a different power management scheme than Bluetooth 4.0. On 3.0, the controller is often a separate USB device, while on 4.0 it is integrated into the Wi-Fi card. The wake behavior can differ. If you are using a Bluetooth 3.0 card, the steps above are more likely to work because the USB port mapping is straightforward.

For Bluetooth 4.0 and later, macOS often uses the BluetoothHCI driver which has its own wake handling. In that case, you may need to use a kext patch or a kernel flag, but this guide focuses on the older 3.0 standard, which is common in legacy builds.

Final Thoughts on Wake on Bluetooth 3

Wake on Bluetooth 3 can be convenient, but on a Hackintosh it often causes more headaches than it's worth. The most reliable approach is to disable it entirely and rely on the power button or a wired keyboard to wake the system. If you need to keep it, the combination of disabling the system preference and patching the _PRW method is the most robust solution.

Before making any ACPI changes, always back up your current EFI partition and your DSDT/SSDT tables. A single mistake can make your system unbootable. For a comprehensive overview of ACPI patching, refer to the SSDT Creation Guide mentioned earlier.

If you are also dealing with graphics issues on your legacy build, you might find our Kepler GPUs on macOS Mojave: The Complete Hackintosh Guide useful, as it covers similar pitfalls with power management.