[Bug] m256wh (Mode Envoy hotswap PCB) KC_CALC and KC_SLEEP stop working after PC wakeup from sleep

[ForsakenRei]

Describe the Bug

After PC wake up from sleep, KC_CALC and KC_SLEEP will stop working, unless reconnect the keyborad. Tested on a desktop PC and a laptop and both have the same issue so I assume it's not an issue from the host side.

There were probably one or two times it still works after PC wake up from sleep but most of the times it won't work. I only noticed those two key codes but there might be others. If there are more data points it will be great.

My keymap and config https://github.com/ForsakenRei/qmk-mode-envoy

Keyboard Used

mode/m256wh

Link to product page (if applicable)

No response

Operating System

Win10 22H2, Win11 22H2

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: C:/Users/%USERNAME%/qmk_firmware
Ψ Detected Windows 10 (10.0.19045).
Ψ QMK MSYS version: 1.7.2
Ψ Git branch: develop
Ψ Repo version: 0.22.12
⚠ Git has unstashed/uncommitted changes.
Ψ - Latest develop: 2023-10-16 22:44:27 +0000 (20cefe254d) -- Merge remote-tracking branch 'origin/master' into develop
Ψ - Latest upstream/master: 2023-10-17 09:43:50 +1100 (f6c70c40af) -- Allow for disabling of parallel processing of qmk find and `qmk mass-compile`. (#22160)
Ψ - Latest upstream/develop: 2023-11-02 14:31:09 +1100 (5d58534a8c) -- LED drivers: use `PACKED` define from util.h (#22380)
Ψ - Common ancestor with upstream/master: 2023-10-17 09:43:50 +1100 (f6c70c40af) -- Allow for disabling of parallel processing of qmk find and `qmk mass-compile`. (#22160)
Ψ - Common ancestor with upstream/develop: 2023-10-16 22:44:27 +0000 (20cefe254d) -- Merge remote-tracking branch 'origin/master' into develop
Ψ 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-07-17 11:39:05 +0200 --  (da78eb37)
Ψ - 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)

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

[ForsakenRei]

Can confirm a hot reboot won't fix the issue, only re-connect works.

[ForsakenRei]

It seems the issue was not fixed in qmk 0.23.1, but quite random.

[ForsakenRei]

It seems there is also some problems with ACTION_TAP_DANCE_DOUBLE, the inital tap won't be registered, but tap&hold will.
Soft reset QK_RBT solves both of them.

[taylorthurlow]

I can also confirm that I have an issue with layer tap functionality with this board, also triggered by sleep. I have a layer tap (LT) binding on spacebar and it stops working after sleep wake.

Here's a demo: https://streamable.com/0ak987

As @ForsakenRei mentions, the symptom is basically that the initial tap is not registered, but A second successive tap will trigger the key one time. The board console correctly shows that the key is pressed two times. Tap and then hold works with no issues.

Some extra details about my setup:

• macOS Sonoma 14.2.1, Mac Mini M2 Pro
• I use Karabiner, but for the above tests I have closed the software.
• my keymap and config

QMK doctor output:

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.2
Ψ QMK home: /Users/taylor/Code/qmk_firmware/Code/qmk_firmware
Ψ Detected macOS 14.2.1 (Apple Silicon).
Ψ Testing userspace candidate: /Users/taylor/Code/qmk_userspace -- Valid `qmk.json`
Ψ QMK userspace: /Users/taylor/Code/qmk_userspace
Ψ Userspace enabled: True
Ψ Git branch: master
Ψ Repo version: 0.23.7
Ψ - Latest master: 2024-01-23 10:02:03 +0000 (b7468f4785) -- Workaround for dfu-programmer on Fedora 39 (#22945)
Ψ - Latest upstream/master: 2024-01-23 10:02:03 +0000 (b7468f4785) -- Workaround for dfu-programmer on Fedora 39 (#22945)
Ψ - Latest upstream/develop: None
Ψ - Common ancestor with upstream/master: 2024-01-23 10:02:03 +0000 (b7468f4785) -- Workaround for dfu-programmer on Fedora 39 (#22945)
Ψ - Common ancestor with upstream/develop: None
Ψ CLI installed in virtualenv.
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 8.5.0
Ψ Found avr-gcc version 8.5.0
Ψ Found avrdude version 7.2
Ψ Found dfu-programmer version 1.1.0
Ψ 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-07-17 11:39:05 +0200 --  (da78eb37)
Ψ - 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

[taylorthurlow]

@Gondolindrim - Any chance this kind of issue is something you've seen before? Sorry to ping you, but you're listed as this board's maintainer.

[ForsakenRei]

Finally someone with the same issue lol. Have you tried if KC_CALC and KC_SLEEP still working after resume from sleep? It not always happen though, but for my case if tap dance didn't work, those keycodes didn't work either. Currently I put a QK_RBT on higher layer to soft reset the keyboard so I don't need unplug the cable everytime.

I thought Envoy has a relative large user base but surprised not a lot of people are having issue, probably the majority of users is not compling firmware.

[taylorthurlow]

I thought Envoy has a relative large user base but surprised not a lot of people are having issue, probably the majority of users is not compling firmware.

Yeah, I was surprised to only see this issue - you're probably right about being a small subset of normal users bothering to self-compile and use the affected keys.

Have you tried if KC_CALC and KC_SLEEP still working after resume from sleep? It not always happen though, but for my case if tap dance didn't work, those keycodes didn't work either. Currently I put a QK_RBT on higher layer to soft reset the keyboard so I don't need unplug the cable everytime.

I don't use them but I just gave them a try, and I kept trying random things and it led to some potential new discoveries. KC_CALC worked for me when I added it, then I did sleep/wake, and it didn't, but now it straight up doesn't work for me at all. I'm not sure what the deal is here. KC_SLEP works for me in both normal and broken-after-sleep state.

However, to my discovery - I use a thunderbolt 4 hub (caldigit element 4), and I only have this issue when the keyboard is attached through the hub. I have run 6+ other QMK keyboards with complex keymaps on this hub and never encountered an issue before, but after 5 or 6 sleep/wake cycles I can't get the issue to trigger when plugged directly into a USB 3 port on my Mac Mini.

Now that's certainly not a solution as plenty of machines (read: laptops) have a much bigger need for hubs like this, but surely this would help narrow things down if you also happen to be using a USB hub of some sort. This would also go a long way to explaining why the problem is less common than expected.

[ForsakenRei]

Hmm, the USB hub discovery is interesing. My keyboards will always connect to my PC directly without hub. Currently Envoy occupied one USB port on the back of my motherboard, I tried my laptop as well(direct connection and hub) but it seems it doesn't really matter, it still happens randomly sometimes it works sometimes not, about half half. I'm not sure if it has anything to do with USB power, since modern PCs and laptop might still provide power to the USB port even after entering sleep state? Sometimes my PC went to sleep but RGB will still be on for the timeout period I setup then off. I should probably keep some records and see if they are related.

All my other QMK keyboards(heck, we all have too many keebs lol) didn't have this issue on the same machine so I'm guessing it's a board specific problem. I still remeber VIA need to be disabled to control RGB from keymap for Envoy.

[taylorthurlow]

Ok, consider me back at square one - I just had it happen again and I am not plugged into the hub. Seems like the hub makes it far more likely to occur, though.

[Gondolindrim]

@Gondolindrim - Any chance this kind of issue is something you've seen before? Sorry to ping you, but you're listed as this board's maintainer.

I am the keyboard maintainer and PCB designer. I will take a look into all of this. I will say that this issue is altogether new to me. The prototypes never showed that issue.

[Gondolindrim]

So I was not able to replicate issue. Not on Linux nor Windows.

What I would try would be the suggestions in the documentation, and here too. About the USB HUB issue, this might be of help

Second I would try to erase EEPROM and recomplie from scractch using the most modern master commit and play with the sleep options.

[ForsakenRei]

So I was not able to replicate issue. Not on Linux nor Windows.

What I would try would be the suggestions in the documentation, and here too. About the USB HUB issue, this might be of help

Second I would try to erase EEPROM and recomplie from scractch using the most modern master commit and play with the sleep options.

I will give it a try on the latest master this weekend. I'm using it on a USB 2.0 port since I knew there were some issue about USB 3.0 and keyboards so just wantto be safe, as @taylorthurlow 's video showed, in configurator https://config.qmk.fm/#/test it simply didn't register any key when those keys stop working.
Another thing I noticed is, if the keyboard go to sleep immediately(mine has RGB on, immediately means the RGB turned off when the PC goes to sleep) then this issue will happen, but if the keyboard wait for 10min inactive and turned off RGB usually the keys will still work after PC wake up. Not 100% sure if keyboard really go to sleep this way though.

BTW does anything changed about VIA need to be disabled if we want to control RGB in keymap?

[taylorthurlow]

Thanks for making an attempt at replication. Still having the issue after some things I've tried:

• Clear EEPROM
• Update QMK to latest master commit and rebuild/flash from scratch
• COMMAND_ENABLE, SLEEP_LED_ENABLE, CONSOLE_ENABLE, and LTO_ENABLE set to no

I have no USB 2.0 ports so that's not an option for me. All of this testing was done without connecting through my USB hub, and the issue happens consistently for me. I'm not sure what the deal was when I was having more luck, I suppose it's possible I wasn't waiting long enough for true sleep.

I'll have to dig into what you mean by "sleep options", I assume the docs will shed light there. Or perhaps you mean OS-level sleep options, in which case macOS doesn't provide any options for that, my understanding is that it provides USB power during sleep by default.

I'll also test on my Windows machine at the earliest opportunity. I also have an Intel-based Mac I can try on as well.

[john-z-yang]

I ran into the exact issue that @taylorthurlow was having. I noticed that there is a pr updating ChibiOS' behaviour for STM32F3s STM32F4s microcontroller (which is the one the envoy pcb is using). (Edit: updated microcontroller name)

This pr landed in develop about 3 weeks ago and it's not in master yet. Checking out this hash and compiling my keymap seems to fix the problem for me.

[ForsakenRei]

This pr landed in develop about 3 weeks ago and it's not in master yet. Checking out this hash and compiling my keymap seems to fix the problem for me.

Thank you for this, I will give it a try and hopefully it will fix all the issues. Being in develop and missed last breaking change means we probably won't see it in master till May or June, but dev branch is pretty usable based on my own experience.

[taylorthurlow]

Awesome - just flashed it, will report back. If this works then maybe we can keep this open until the fix is in master.

[taylorthurlow]

Yeah I'm no longer having any issues with this, super happy to confirm.

[Gondolindrim]

This is nice. Maybe we can wait for QMK to merge the new Chibi changes into master and release a new version of the firmware with the fix. And just for the record: Envoy does not use STM32F3, instead it uses STM32F4.

[KarlK90]

Thanks guys for testing the async endpoint PR and that it apparently solves the issues it was meant to solve. If you happen to run into any regressions in functionality please ping me.

[ForsakenRei]

Thanks guys for testing the async endpoint PR and that it apparently solves the issues it was meant to solve. If you happen to run into any regressions in functionality please ping me.

Thank you for the great work. I didn't really have time to test it recently but will close this issue once I tried the develop branch since it's already merged.

[ForsakenRei]

I can confirm the PR fixed it for me, might still be a while till it is merged to master but we can close this issue.