qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
17.97k stars 38.63k forks source link

[Bug] LT(layer, kc) do not work after waking up PC (Mac/Linux/Windows) on BlackPill #16406

Open DuMaM opened 2 years ago

DuMaM commented 2 years ago

Describe the Bug

I tested this on many different ways, on different devices and behavior is the same. When my computer goes into sleep mode/powers off, LT keys stop working as they supposed to, after next wake up/boot. I need to click 2 times to trigger behavior assigned to click action. I also noticed that if I click continuously and 2-3 times faster then normal it works as it supposed to.

Layers also not working.

System Information

drashna commented 2 years ago

Could you post a link to your config?

I'm using blackpills on several boards without any issues on the LT keys.

DuMaM commented 2 years ago

@drashna I'm using this keymap https://github.com/qmk/qmk_firmware/blob/master/keyboards/handwired/dactyl_manuform/6x6/keymaps/dumam/keymap.c and this config https://github.com/qmk/qmk_firmware/tree/master/keyboards/handwired/dactyl_manuform/6x6/blackpill_f411

Maybe it's hardware issue?

drashna commented 2 years ago

is there a reason to have these?

#define PAL_USE_CALLBACKS TRUE
#define PAL_USE_WAIT TRUE
DuMaM commented 2 years ago

I'm must say that i dont remember... Let me check this :)

DuMaM commented 2 years ago

@drashna I checked it out. It didn't help, but it also didn't break anything. I will create PR where this redundant code is removed. I will play I bit with hid_raw to give you some more info about it.

DuMaM commented 2 years ago

Logs from both failing and working case are the same... 😭
In this broken state, when I was writing spaces in Notepad every second key hit was missed. At the same time hid logger doesn't miss any hit... 😖

status

- 
Version - 
VID: 0x444D(tshort) PID: 0x3636("Dactyl-Manuform (6x6)") VER: 0x0001
BUILD:  (Mar 15 2022)
CHIBIOS: "develop_2021_q4", CONTRIB: "develop_2021_q3-8-gd1c212"
OPTIONS: MOUSEKEY EXTRAKEY CONSOLE COMMAND BOOTLOADER_SIZE
GCC: 8.3.1

matrix and keys

keyboard_report: 00 00 2C 00 00 00 00 00 
keyboard_report: 00 00 00 00 00 00 00 00 
keyboard_report: 00 00 2C 00 00 00 00 00 
keyboard_report: 00 00 00 00 00 00 00 00

r/c 01234567
00: 00000000
01: 00000000
02: 00000000
03: 00000000
04: 00000000
05: 00001000
06: 00000000
07: 00000000
08: 00000000
09: 00000000
0A: 00000000
0B: 00000000
0C: 00000000
0D: 00000000

r/c 01234567
00: 00000000
01: 00000000
02: 00000000
03: 00000000
04: 00000000
05: 00000000
06: 00000000
07: 00000000
08: 00000000
09: 00000000
0A: 00000000
0B: 00000000
0C: 00000000
0D: 00000000

Does it mean that USB stack is corrupted after reboot in driver? This didn't explain why this is failing on Mac/Linux/Windows...

DuMaM commented 2 years ago

Any ideas how I can debug this problem?

drashna commented 2 years ago

The matrix is reporting the correct activation but was not being sent?

Also, if you add the reboot keycode, does that help when this happens?

DuMaM commented 2 years ago

I didnt saw a reboot keycode anywhere. Could you provide any links?

klesh commented 1 year ago

I'm having the same problem with cantor(blackpill microcontroller) on linux as well.

DuMaM commented 1 year ago

@klesh I guess it's connected to bootloader. I got one before quite big changes in tiny usb for black pill. They added recently option to update it via DFU, so it's worth of checking. For now i solved this by plugin my keyboard to hub which is constantly powered.

klesh commented 1 year ago

@DuMaM Aah, I tried lowering the cpu/usb freq last night, and it seems to be working so far, would you like to try these settings in your rules.mk?

F_CPU = 8000000
F_USB = $(F_CPU)
fauxpark commented 1 year ago

Those don't do anything on ARM boards.

klesh commented 1 year ago

Those don't do anything on ARM boards.

Yes, you are correct. The keyboard works for for short sleep, and breaks when sleep like over an hour or so.

DuMaM commented 1 year ago

After windows upgrade to 2H22, this started to happen again for me. I guess new OS have some problems with thunderbolt and powermanagment because it constantly disconnect with my hub. So my workaround solution is not working anymore. 😭

Today I flashed with the latest 10.2 bootloader and qmk 0.18.13. I will post you if this helped in any way.

DuMaM commented 1 year ago

it didn't help. for Mac and Linux i have behaviour descibed in ticket. For windows 11 22h2, my keyboard doesn't work at all 😢 Now if low power event trigges itself then my hub is dying. I have a driver error and the only option to fix this is to reboot pc 😿

When I connect it directly to PC i still got the same behaviour.

DuMaM commented 1 year ago

Could you guys (@klesh @fauxpark @khoanguyen8496 @wkf) share your keyboard settings? Like:

I want to solve it, and i can even prepare fix myself but without clue it's hard to determine whats going on. So please help me to narrow down this problem, because it's pissing me more and more. 😠

DuMaM commented 1 year ago

https://github.com/qmk/qmk_firmware/issues/8259#issuecomment-596070920 When I will have some free time I will try this fix 😉

DuMaM commented 1 year ago

I guess it was resolved and then ChibiOS got upgraded and something broke there again.

klesh commented 1 year ago

Could you guys (@klesh @fauxpark @khoanguyen8496 @wkf) share your keyboard settings? Like:

  • which keyboard do you use?
  • did you change something there?
  • what type of OS do you use?
  • which QMK revision is installed on yours keyboards?
  • Do you guys have a legal BlackPills from WeAct? ( I don't know if mine was rip off or not.)
  • etc.

I want to solve it, and i can even prepare fix myself but without clue it's hard to determine whats going on. So please help me to narrow down this problem, because it's pissing me more and more. angry

Sorry, I missed the message.

  1. It happens to all my Blackpill keyboards, including cantor and one of my own design
  2. I can't think of anything special
  3. Linux/Windows, the symptom exhibited on both systems
  4. 431c92893fff5d6678b9ac6d4acd0b6a70b3ebad
  5. I'm pretty sure mine were. They were stm32f401, WeAct stopped producing them a long time ago
nolith commented 1 year ago

I have a cantor remix (36keys) flashed with miryoku layout from qmk master (flashed today).

If macOS goes into sleep mode all the homerow mod keys and the thumb cluster keys stop working.

I'll test if the double tap works as described in this issue

klesh commented 1 year ago

Hi, all, did you try the fix from https://github.com/philong/vial-qmk/commit/f98b88cf0ab0d66f0af293fb1a98b17d8edd2536 ?

image

nolith commented 1 year ago

Hi, all, did you try the fix from https://github.com/philong/vial-qmk/commit/f98b88cf0ab0d66f0af293fb1a98b17d8edd2536 ?

Thanks for the suggestion. I'll cherry-pick it later today and test.

For the double tap after sleep I'll say that it is more or less a s described, but I find it challenging to double tap quick enough to male it work.

philong commented 1 year ago

Hi,

The fix mentioned above is an old version of my workaround.

My current workaround is this in my keymap.c:

// Workaround for https://github.com/qmk/qmk_firmware/issues/16406
void suspend_wakeup_init_user(void) {
    NVIC_SystemReset();
}

It basically just resets the keyboard after waking up from suspend. Although it works for me, it does not fix the real cause of the issue.

nolith commented 1 year ago

Hi, all, did you try the fix from https://github.com/philong/vial-qmk/commit/f98b88cf0ab0d66f0af293fb1a98b17d8edd2536 ?

Thanks for the suggestion. I'll cherry-pick it later today and test.

With this commit applied the keyboard is completely dead after a sleep.

I did some extra testing and I found that if I wake the computer using the keyboard, it will freeze completely, but if I utilise another device for waking up the computer it works.

I'll try to utilise the suspend_wakeup_init_user workaround to see if changes something.

nolith commented 1 year ago

Hi,

The fix mentioned above is an old version of my workaround.

My current workaround is this in my keymap.c:

// Workaround for https://github.com/qmk/qmk_firmware/issues/16406
void suspend_wakeup_init_user(void) {
    NVIC_SystemReset();
}

It basically just resets the keyboard after waking up from suspend. Although it works for me, it does not fix the real cause of the issue.

This seems to be working for me as well 🎉

Thank you

klesh commented 1 year ago

Hi,

The fix mentioned above is an old version of my workaround.

My current workaround is this in my keymap.c:

// Workaround for https://github.com/qmk/qmk_firmware/issues/16406
void suspend_wakeup_init_user(void) {
    NVIC_SystemReset();
}

It basically just resets the keyboard after waking up from suspend. Although it works for me, it does not fix the real cause of the issue.

Thanks for the update.

@drashna Does it help for a more general fix?

nolith commented 1 year ago

I want to report that now that I'm no longer using the NVIC_SystemReset() but only NO_SUSPEND_POWER_DOWN = yes I had another instance of this issue today.

It seems to make it more unlikely to happen, but still possible.