-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Prevent Stuck Modifiers #441
Comments
I'd like to make a better layer switch function instead (I have an issue on that here). A temporary layer switch that restores modifier states on release would be ideal for my purposes, and wouldn't lead to an overhead per key like QMK's solution does. Or just an optional option for the existing layer switches. |
If I could figure out how to have it release CTRL when I release FN0, that would actually solve my problem. I'm not adept enough to program a function to do this though. |
Can anyone port this PR to TMK and test it? |
Is that a good fix though? I'm not sure I understand it entirely, but it seems that they store every pressed key which uses up a lot of memory. Surely there must be better ways of handling modifier jam? (Some are suggested in the comments, I think?) This happens when using temporary layer switching, mostly (I suppose layer toggles too could be affected). Why not just clean the modifier state when releasing a layer? I can imagine that someone might want to first press a modifier and then switch to a layer and expect the modifier to be still active, but is it a problem if the modifier is deactivated when releasing that layer again? At that point I'd think that you'd be ready for new presses. Alternatively, let a layer switch store the modifier state and restore it upon layer release. That'd be safe, wouldn't it? |
@DreymaR I think the PR seems to me be ideal and straight solution for the key stuck problem and what I've wanted for long time. Yes, you are right, it costs more memory and time in return. But if the cost is acceptable I want to merge it. I need universal solution and don't want ad hoc solution moreover for the problem. |
I still don't see the rationale for this solution. In my head: |
- Idea form qmk/qmk_firmware#182 - Define NO_TRACK_KEY_PRESS to get old behaviour - This should resolve #105, #248, #397, #441 and FAQ entry: https://github.com/tmk/tmk_keyboard/wiki/FAQ-Keymap#modifierlayer-stuck
Fixed at ba2883f |
- Idea form qmk/qmk_firmware#182 - Define NO_TRACK_KEY_PRESS to get old behaviour - This should resolve tmk#105, tmk#248, tmk#397, tmk#441 and FAQ entry: https://github.com/tmk/tmk_keyboard/wiki/FAQ-Keymap#modifierlayer-stuck
- Idea form qmk/qmk_firmware#182 - Define NO_TRACK_KEY_PRESS to get old behaviour - This should resolve tmk#105, tmk#248, tmk#397, tmk#441 and FAQ entry: https://github.com/tmk/tmk_keyboard/wiki/FAQ-Keymap#modifierlayer-stuck
I am experiencing an issue where a modifier key gets stuck when switching from a momentary layer back to the base layer. The key in question is mapped to A on Layer0 and LCTRL on Layer1.
I'm using a GH60 Satan on a Mac where CTRL+ARROW switches virtual desktops around. I use Caps Lock as my FN0 key which switches to the momentary Layer1 where the arrow keys are located. Instead of holding LCTRL and Caps Lock down to get CTRL+ARROW, I wanted to be able to hold Caps Lock+A (LCTRL) and use the arrow keys, which I have as IJKL.
Would it be possible to get a PREVENT_STUCK_MODIFIERS option like QMK? Is this the answer?
It is referenced:
qmk/qmk_firmware#579
qmk/qmk_firmware#182
The text was updated successfully, but these errors were encountered: