-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Auto Mouse Layer Sticking #32
Comments
Specifically, the issue is that |
Thanks @aus10code for reporting this and @drashna for those details. As a quick possible workaround, try bypassing Achordion while the mouse layer is on: uint16_t achordion_timeout(uint16_t tap_hold_keycode) {
if (IS_LAYER_ON(MOUSE)) {
return 0; // Bypass Achordion while mouse layer is on.
}
return 800; // Otherwise use a timeout of 800 ms.
} For a deeper fix, I don't know how Auto Mouse Layer or layer caching work and need help. Achordion itself does not use or manipulate the layer state. Granted, it does recursively call Achordion appears to work as intended with other kinds of layer keys. Could you help me understand what is happening differently with Auto Mouse Layer? I see from users/drashna/pointing As a first point of troubleshooting, I suggest to confirm the Auto Mouse Layer timer is firing. I can imagine (from experience of debugging my own timers) that timer logic might get thrown off by the recursive When the timer fires, I guess it calls |
Thanks for the bypass solution, however I don't want to bypass Achordion! After some digging I think I found where the pointing_device_auto_mouse.h - line 34 also this may help: Auto Mouse Layer ReadMe As a side note, I'm available pretty much anytime to help troubleshoot. I just may need some hand holding as I'm overall pretty new to the QMK environment and C as a language itself. I'm willing to screen share and test my issues out over discord (or any other software) with you if that would be helpful. |
The problem is actually not with the layer cache, but with the recursive call to Notice that |
@sigprof thanks a bunch for this excellent analysis! That dissects what is going on and makes the root cause clear. Achordion recursively calls
AFAICT recursively calling Possible solution: Achordion could handle the press and release of "B" symmetrically, in both cases calling Possible mitigation: The keycode for "B" is likely still up to date most of the time. Achordion could compare the layer state and resort to recursively calling |
“Late” layer switches are a real problem; the tap dance code does them too, and got a special piece of code inside But this solution is available only to the core code, and can't be used by something externally plugged into
Even this might not help if the layer state had actually changed, and the original invocation of Properly fixing this may require actually plugging the feature into the core and making it run earlier, so that the issue with some other functions using wrong keycodes does not happen in the first place. |
Mostly just thinking, but it might be useful to use the |
I'm currently experiencing this issue with the sticking auto mouse layer... is there a workaround available or any other progress? Thank you! |
For reference, I'm using this ... rather invasive hack: |
Have you submitted a PR for that upstream? I'd love to not have to carry any such patches :-) |
Develop has the changes merged in, now. qmk/qmk_firmware#23144 |
Describe the bug
This is an issue I have while using @drashna's Auto Mouse Layer that I use on my 4x6 Charybdis
My mouse layer gets stuck enabled when I follow the below steps
This will then cause my mouse layer to get stuck
Information
My QMK:
https://github.com/aus10code/QMK-Keymap
This issue was originally discussed on the QMK Discord server.
https://discord.com/channels/440868230475677696/1082712746539352164/1082712746539352164
Do the keys involved use any of the following features?
The text was updated successfully, but these errors were encountered: