I personally analyzed the QK Alice Duo v1.0.6 firmware architecture and real-device behavior and developed this macOS sleep-behavior firmware. I traced the original sleep, USB resume, HID report, Pod LED, and keyboard-half communication paths, then reproduced DarkWake on an actual QK Alice Duo using Find My to identify the cause and verify the modified behavior.

Even while a MacBook lid is closed or its display is off, macOS may briefly wake the system to handle Find My, network connections, and system maintenance. macOS calls this behavior DarkWake. It is a normal background wake that does not fully restore the display and regular user session.

During this process, however, the QK Alice Duo may resume its USB connection, turn on the LEDs on the Pod and both keyboard halves, or send a key signal even though no physical key was pressed. If macOS treats that signal as user activity, it can promote the MacBook from DarkWake to a full system wake, or FullWake. In some environments, this can also cause resident services such as Logi Options+ to crash or enter an error state, requiring the service to be restarted or the Mac to be rebooted.

This firmware does not disable DarkWake or physically cut power to the keyboard. It preserves normal background connectivity, MCU operation, communication links, key scanning, and real-key wake behavior while restricting unnecessary LED illumination and phantom keyboard reports.

During DarkWake, the Pod and both keyboard-half LEDs remain off, and 6KRO/NKRO reports that were not caused by a real physical keypress are blocked. The same guard remains active through repeated DarkWake and reconnect events. When a real physical key is pressed, the first key is passed normally to the Mac. If the LEDs were enabled before sleep, the Pod and both keyboard halves restore their saved enable, effect, color, and brightness settings. If the LEDs were disabled before sleep, they remain off while real key input still works normally. No macOS agent, LaunchAgent, or background application is required.

The QK Alice Duo has three physical parts—Pod, Left, and Right—but requires four firmware files because the Pod contains two MCUs with separate roles. Master is the USB/VIA/HID device directly visible to the Mac and handles keyboard reports and the Pod LED. Host does not refer to macOS, WindowServer, or the computer itself; it is the second MCU inside the Pod and relays packets, wake commands, and LED configuration between the two keyboard halves. Left and Right handle their respective key matrices and LEDs. A Master-only modification cannot fully control the LEDs on both keyboard halves, so Master, Host, Left, and Right must work together under the same policy.

When a real physical key is pressed while the lid is closed, the firmware passes the first key as a normal HID wake input and releases the LED guard. If the Mac meets the macOS closed-display or clamshell requirements, including the required external-display and power configuration, that keypress can wake the Mac normally. If those conditions are not met and the Mac returns to sleep, that behavior is controlled by macOS power-management policy rather than the firmware.

The firmware does not completely remove USB or keyboard power. During DarkWake, the MCU, communication link, and key-scanning circuitry may briefly wake and then return to the stock firmware’s low-power idle or sleep state. In magnetic-cable mode, a small amount of standby power is supplied by the Mac and Pod. In wireless mode, standby power comes from the keyboard batteries. An exact power figure cannot be claimed without direct measurement, but the standby consumption of the control circuitry is substantially lower than leaving the LEDs continuously illuminated.

The analysis was based on the current real-world setup in which the Pod and both keyboard halves are connected with magnetic cables. Wired and wireless data converge on the same Host command and keyboard-half dispatcher path after passing through the cable or radio transport. The patch operates on that shared path and does not modify cable detection or the radio driver, so it is designed to enforce the same policy in wired magnetic-cable and wireless modes. Real-device wireless timing for the complete four-component set must still be checked after the complete set has been applied.

Use the following four UF2 files together as one coordinated set.

qk_alice_right_v1.0.6_EXPERIMENTAL_complete_darkwake_guard.uf2

qk_alice_left_v1.0.6_EXPERIMENTAL_complete_darkwake_guard.uf2

qk_alice_master_v1.0.6_EXPERIMENTAL_complete_darkwake_guard.uf2

qk_alice_host_v1.0.6_EXPERIMENTAL_complete_darkwake_guard.uf2

Only these four UF2 files should be applied to the device. Do not mix them with older Master-only builds or files from another version.

The required application order is Right → Left → Master → Host. Apply one component at a time. After each step, confirm that the device reconnects, boots, and accepts key input normally before proceeding. If any component update fails, do not continue with the remaining updates.

Before updating, back up the VIA keymap and keep the original v1.0.6 Master, Host, Left, and Right UF2 files available for rollback. Double-check the filename and target component before every update. Never cross-flash Left and Right because their Family IDs and role data differ even though their code is similar. Use a stable USB connection, update only one component at a time, and do not disconnect the cable during an update. Never use mass erase or chip erase because these UF2 files do not include the resident bootloader region.

The previous Master v2 was tested on an actual QK Alice Duo by reproducing Find My DarkWake. That real-device test confirmed that the Pod LED remained off, QK-originated phantom FullWake was suppressed, and normal operation was preserved. It also proved that a Master-only modification could not control the keyboard-half LEDs that the Host turned back on.

The complete Master in this package is byte-for-byte identical to that hardware-tested Master v2. The new Host, Left, and Right images have passed official-source UF2, Family ID, target-range, exact patch-site, code-cave, deterministic-rebuild, Cortex-M4 Unicorn emulation, repeated DarkWake, LED ON/OFF preference, physical-key state-transition, and Left/Right packet-delivery-path verification.

The complete Master, Host, Left, and Right set has not yet been applied together on physical hardware. Static analysis and CPU emulation have passed, but real radio timing, magnetic-contact behavior, and the bootloader update process must still be verified on the actual device in both wired and wireless modes.