Cool, I will try to disable everything else to minimise possible issues with other shortcuts and/or apps and will send it then. Thank you so far!
I still regularly see this bug. The problem is there is some factor which causes this to vary, like every 10 times I see this one or two times, it feels like some kind of race condition that depends on some other processing.
My screen recording from 2022 is still the behaviour I see today:
I attach my hyper key setup:
exported_triggers-hyper.bttpreset (6.3 KB)
exported_triggers-F18.bttpreset (26.3 KB)
I also sent my debug data to you @Andreas_Hegenberg , thanks as always for such a great tool!
Has this issue ever been resolved? I now run into the same issues.
Granted in my case there are some elements that can pose a challenge, but any information on a solution would be appreciated.
I have set ⇧⌃⌥⌘F12 as a global sleep shortcut via System Settings > Keyboard > Keyboard Shortcuts
And in BTT I have enabled Capslock as hyper key
When I press Capslock + fn (because I have the Apple default functionality for the F keys enabled) + F12 it goes to sleep as expected.
So far so good.
The problem however is that upon waking, I cannot log in by entering my password. It's essentially as if the keyboard is unresponsive.
The suspicion was that ⇧⌃⌥⌘ were still registered as held down because I noticed on a different device that the default screenshot could folder I use would accumilate screenshots if I happen to press 4 (which screenshot shortcut is ⇧⌘4).
Pressing just the capslock didn't fix the issue, pressing the same combination (Capslock + fn + F12) again to see if that helped didn't resolve the issue either, it just put the machine back to sleep and upon waking I still couldn't enter my password.
Via a workaround I managed to log in without needing to enter my password and I could confim my suspicion by doing a bunch of tests.
⇧⌃⌥⌘ (i.e. the capslock in hyper key state) essentially remains pressed down. Since then I've learned that intermittently, after being logged in, I can make that stop by pressing capslock again.
I suspect this might just be an unfortunate combination of secure input state of login window + fn related finickyness + it being a shortcut via System Settings?
Is there any more information known about sticky hyperkey issues in general or under specific circumstances?
Sleep is possibly tricky. I'll make sure to reset hyper key state on sleep with the next release.
For now you could configure it in BTT. I think triggering on key up and adding a small delay should also workaround the issue:
1 Like
Yeah I figured sleep made things a bit trickier.
But this a good solution, didn't even know there was an async option, now all we need is an await option 