[Bug] Q3 Max: Waking keyboard from sleep on Bluetooth drops first keys typed

[ottobonn]

Describe the Bug

I have a new Q3 Max and I am using it over Bluetooth. After a while of inactivity, it goes to sleep. Pressing a key will wake it up, but it takes a few seconds to reconnect.

During the time it takes the keyboard to wake up, any keys I press are ignored and not sent to the computer. Losing those key presses is annoying, because it's hard to know when the keyboard is ready for me to type.

I would like to open a discussion on how we can avoid losing the keypresses as the keyboard wakes from sleep.

Keyboard Used

Q3 Max

Link to product page (if applicable)

https://www.keychron.com/products/keychron-q3-max-qmk-via-wireless-custom-mechanical-keyboard?variant=40766137565273

Operating System

Linux Mint

qmk doctor Output

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

[ottobonn]

@lokher It looks like you're familiar with the relevant code branch. For what I gather, the Q3 Pro uses the wireless_playground branch? I am happy to help investigate this issue, but I want to make sure I am looking in the right place.

First, it's worth asking if you can confirm this behavior. Do the initial key presses to wake the computer get dropped on the Q3 Max?

If this issue is due to how the firmware is written and not a hardware / OS issue, I think it would be worth investigating a fix. Here are some ideas that I wanted to ask if you have considered:

1. Queuing the key presses until reconnected to Bluetooth
2. Keeping Bluetooth connection active with HID over GATT
3. Changing the sleep mode to keep Bluetooth active

[lokher]

I have tried adding key buffer before, the problem is bluetooth chip get a reset on wakeup from low power mode(in connection or disconnection), then sends a disconnection event to USB chip, and code clear the key buffer on a disconnection event.
I need to think more aobut it.

[PeterMortensen]

I have a setup where this does not happen (also Linux), including using a 'Max' keyboard (V6 Max). The Bluetooth firmware version does not seem to play a role for this particular aspect (it worked equally well both before and after the update to version 0.2.1, except for one annoyance (but it is probably not a problem with later versions of the operating system (versions of BlueZ?))).

Keystrokes are never missed, and the reaction time is about 200 ms. It is noticeable, but it is close to instant.

[ottobonn]

@PeterMortensen just to make sure I understand, do you mean that, starting with the keyboard asleep from inactivity, you can begin typing, and it will connect to Bluetooth and capture all of the keys you have typed as it wakes up and connects? I have been testing it on various host operating systems, and in each test, with the keyboard asleep, it misses the first keypresses as it wakes up.

[PeterMortensen]

Re "starting with the keyboard asleep from inactivity you can begin typing, and it will connect to Bluetooth and capture all of the keys you have typed as it wakes up and connects?": Yes. And in less than 0.3 seconds.

Though I don't know if the keyboard (and/or the Bluetooth module) is actually in sleep mode. Allegedly, it only goes to real sleep after 2 hours (of inactivity). But from a user perspective it definitely is (the RGB light is off, after the period set by CONNECTED_BACKLIGHT_DISABLE_TIMEOUT (default value 600. 600 seconds = 10 minutes)).

I have reduced the sleep time from 10 minutes to 30 seconds, because key strokes are never missed.

For instance, I started typing this sentence on a K5 Pro in sleep mode. The firmware on the K5 Pro was from after 2024-03-30 (close to the latest in fact, 2025-01-17 (3FD443)).

Today, I also tested it on another computer (with another motherboard) with another Bluetooth adapter (without a fake chip inside): Under LMDE 6 and using the Asus BT500 Bluetooth adapter. The result was the same: No missed keystrokes and less than 0.3 seconds latency/reaction time. And it worked equally well with the K5 Pro and V6 Max. Both regular typing and invoking macros worked from keyboard sleep (but the latter positively requires firmware based on source code from after 2024-03-30).

Sleep may or may not have to be prevented on the host side (of the Bluetooth adapter).

What keyboard firmware versions do you use (both main firmware and Bluetooth firmware)? Keychron's official main firmware may not have caught up yet.

Or perhaps the following is the key (no pun intended)?

options btusb enable_autosuspend=0

(Not a rhetorical question; I don't know at this point in time; some controlled experiments would be required.)

My guess is that "enable_autosuspend" is not important. I have "cat /sys/module/btusb/parameters/enable_autosuspend" return "Y" on both systems.

[PeterMortensen]

What is your host side setup? For example, which Bluetooth adapter? What Bluetooth version does it support?

What source code version is your keyboard's firmware based on? Does the behaviour change if you compile and flash firmware based on the latest source code?

References

• Q3 Max product page. A 80% (TKL) wired and wireless (both Bluetooth and '2.4 GHz')" QMK/Via-capable mechanical keyboard.
• Q3 Max default keymap
• Q3 Max source code. Note: In Keychron's fork and in that fork, in Git branch "wireless_playground" (not the default branch). No matter the Git branch, for example, "wireless_playground", it requires special setup of QMK (the standard QMK instructions and many other guides will not work (because they implicitly assume the main QMK repository and a particular Git branch)). Source code commits (RSS feed. Latest: 2025-01-17).