[Bug] Keychron Q11 ISO not recognized after computer shutdown

[xRyuo]

Describe the Bug

The keyboard is not detected (keys not working, no backlight) after the computer is shutdown and powered on again.
It has to be disconnected and reconnected multiple times so it can work again.
It has been tested on multiple computers and usb cables.

Keyboard Used

keychron/q11/iso_encoder

Link to product page (if applicable)

https://www.keychron.com/products/keychron-q11-qmk-custom-mechanical-keyboard-iso-layout-collection

Operating System

Windows, Linux

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: C:/Users/songe/qmk_firmware
Ψ Detected Windows 10 (10.0.22621).
Ψ QMK MSYS version: 1.7.2
Ψ Git branch: master
Ψ Repo version: 0.21.6
Ψ - Latest master: 2023-07-30 00:22:39 -0400 (14e14e9ab8) -- Correct "less than" to "up to" in squeezing_avr?id=layers (#21639)
Ψ - Latest upstream/master: 2023-08-03 10:03:29 +0200 (37b62606ce) -- Add VIA layout for Dactyl Manuform 5x6 (#21649)
Ψ - Latest upstream/develop: None
Ψ - Common ancestor with upstream/master: 2023-07-30 00:22:39 -0400 (14e14e9ab8) -- Correct "less than" to "up to" in squeezing_avr?id=layers (#21639)
Ψ - Common ancestor with upstream/develop: None
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 10.1.0
Ψ Found avr-gcc version 8.5.0
Ψ Found avrdude version 7.0
Ψ Found dfu-programmer version 0.7.2
Ψ Found dfu-util version 0.11
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2023-04-15 13:48:04 +0000 --  (11edb1610)
Ψ - lib/chibios-contrib: 2023-01-11 16:42:27 +0100 --  (a224be15)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

[rpn32]

On Linux, do you get any error messages when you run the command sudo dmesg | grep usb when the keyboard is plugged in but not working after a reboot?

This command will let us know if the computer is attempting to establish a connection to the keyboard.

[xRyuo]

I have no error, it is like the keyboard is not plugged in at all.

[rpn32]

Here are a couple more things to try then:

1. Use a different USB port on the computer. Not only try a USB port next to the one you currently use, but also on the opposite side (i.e. from back panel to front panel or from right side to left side)
2. Remove the bridge cable and plug in only one half of the keyboard at a time.

[xRyuo]

Use a different USB port on the computer. Not only try a USB port next to the one you currently use, but also on the opposite side (i.e. from back panel to front panel or from right side to left side)

I have tried multiple configurations (front and back, usb2 vs usb3 controllers, usb hub vs no hub). Same results, no sides are detected once I shutdown the computer and restart it after.

Remove the bridge cable and plug in only one half of the keyboard at a time.

Same results, none of the sides are detected.

I have discovered also some interesting things when not using the bridge.
I have setup the two sides alphanumerical keys to light up red. With two dedicated usb cables, it works as expected, but it doesn't when the left is connected to the computer with the right side connected with the bridge, only the left side lights up red. Even though the lighting seems better, I have on the other side more issues:

• The keyboard seems to hang with inputs freezing (multiples inputs are sent continuously) and I need to disconnect the keyboard.

• I has the following error once from Windows:

  USB device is not recognised
  The last USB device you connected to this computer malfunctioned and Windows does not recognise it.

  It works again when replugged.
  Beside the lightning issue, left side connected to the right side with the bridge works better.

I don't know if this was intended by Keychron but it does seems strange.

[lesshonor]

Are you able/willing to test with the changes from #20863?

Techniques like https://stackoverflow.com/a/45967995 can assist with this. Do note that the branch is old, so depending on your workflow you may want to try something like git fetch upstream pull/20863/merge && git checkout FETCH_HEAD to check out the merge branch instead of head.

[xRyuo]

I just tested with #20863.
It does not improve, same behavior unfortunately.

Additionnal test: I flashed the original firmware Keychron provided and it works... It seems the repository is not in sync with the firmware they are providing. I am stuck now with Keychron firmware or I have to unplug and replug every time I shutdown my computer; I cannot use all QMK functionalities until Keychron somehow updates their files.

[rpn32]

The keyboard not being detected after reboot is a low level OS/USB problem. I had a similar problem with week (#21678) with my custom keyboard, but was able to resolve it by delaying usb initialization a bit.

The difference between your case and mine is that I was able to see an attempt of USB negotiation. That's why I asked to see if there were any usb dmesg errors.

Are you running Linux bare metal or in a VM. If it's in a VM, then Windows may be capturing the USB packets and not passing it along to see the dmesg errors.

In that case you need to use a Windows tool to capture the USB packets to see if there is an attempt of USB negotiation and where it is getting stuck.

Otherwise, the issue is elsewhere.

I've attached a patch to delay usb initialization. Perhaps it helps you.

chibios_usb_delay.patch

edit: You may also want to try to increase the other delays in the protocol_pre_init() function of the file referenced in the patch (tmk_core/protocol/chibios/chibios.c). There is a comment that says:
/* Do need to wait here!
* Otherwise the next print might start a transfer on console EP
* before the USB is completely ready, which sometimes causes
* HardFaults.
*/

[sigprof]

Can you try adding

#define SPLIT_WATCHDOG_ENABLE

to config.h (this may be done even in a keymap)?

Apparently keychron/q11 does not declare USB_VBUS_PIN (most likely the board does not actually have such hardware), and the described behavior (keyboard does not work when USB was connected before powering the computer on) is very common for such configurations; the SPLIT_WATCHDOG_ENABLE option enables a software workaround for that problem (basically, it reboots the board after SPLIT_WATCHDOG_TIMEOUT ms (default=3000) if no data was received from the master side of the split, so that the master/slave detection could be repeated instead of leaving the board stuck in the slave mode).

Also #20863 is definitely not related to this problem (Keychron Q11 uses STM32L432, not something from the WB32 family).

[xRyuo]

It does work with:

#define SPLIT_WATCHDOG_ENABLE

You are a true knowledge well sigprof!

[AmmarAbouZor]

Finally a working solution!
I've spent many hours delving into keychron branches to find the magic settings that made this problem disappear with their provided firmware only.
I'll open an Issue in their fork and link the issue here to it, so they fix it.

Very thanks for @xRyuo for opening the issue and for @sigprof for solving it ❤️

[danielweck]

Can you try adding

#define SPLIT_WATCHDOG_ENABLE

This was merged recently:

#22799