Skip to content
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

Stuck modifier after layer switch #579

Closed
am opened this issue Jul 28, 2016 · 5 comments
Closed

Stuck modifier after layer switch #579

am opened this issue Jul 28, 2016 · 5 comments

Comments

@am
Copy link
Contributor

am commented Jul 28, 2016

I saw this have been raised before, but since I'm experiencing a similar problem on the current version here is a new issue.

Using a plank when I hold ctrl and then hold the raise layer to access a symbol if I release first the ctrl key and then the raise layer the modifier gets stuck.

I notice this using emacs, for a brief moment I thought I was using vim on visual mode 😜

@y4le
Copy link
Contributor

y4le commented Jul 28, 2016

I'm seeing a similar issue.

reproduction steps:
Create a keyboard with 2 layers. The bottom layer should have a MO(1) key and the top layer should have a modifier key
Press the MO key
Press the modifier key on the top layer
Release the MO key
Release the modifier key

You will now be stuck with that modifier key active until you press MO->press modifier->release modifier->release MO

It seems like the modifier key triggers the modifier state on keydown and removes it on keyup, but when you press then change layers then release you are now keyup-ing the key on the bottom layer, which won't turn the modifier off

@y4le
Copy link
Contributor

y4le commented Jul 28, 2016

One possible fix would be to trigger keyup on all keys when leaving a MOmentary layer, but that could have some weird side effects.
Ideally if you pressed a key on a particular layer it would remain that key until you released it regardless of layer changes, but that could be difficult to implement

@y4le
Copy link
Contributor

y4le commented Jul 28, 2016

I found a solution to my problem in #182. There is already a framework in place to make modifiers 'weak' so that they will be cleared on a layer change. This is a better version of my first suggestion above.

@y4le
Copy link
Contributor

y4le commented Jul 28, 2016

Even better, 182 got merged. From the readme:

Prevent stuck modifiers

Consider the following scenario:

Layer 0 has a key defined as Shift.
The same key is defined on layer 1 as the letter A.
User presses Shift.
User switches to layer 1 for whatever reason.
User releases Shift, or rather the letter A.
User switches back to layer 0.
Shift was actually never released and is still considered pressed.

If such situation bothers you add this to your config.h:

#define PREVENT_STUCK_MODIFIERS
This option uses 5 bytes of memory per every 8 keys on the keyboard rounded up (5 bits per key). For example on Planck (48 keys) it uses (48/8)*5 = 30 bytes.

@am
Copy link
Contributor Author

am commented Jul 28, 2016

Thank you @lordchair this completely solves my problem. Added that to my keymap config and it works as expected.

@am am closed this as completed Jul 28, 2016
BlueTufa pushed a commit to BlueTufa/qmk_firmware that referenced this issue Aug 6, 2021
* add dz60rgb_ani;dz60rgb_wkl default keymap

* Create kbdfans_kbdmini_default.json
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants