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

Still getting stuck modifiers. #1593

Closed
dwrz opened this issue Aug 18, 2017 · 3 comments
Closed

Still getting stuck modifiers. #1593

dwrz opened this issue Aug 18, 2017 · 3 comments

Comments

@dwrz
Copy link
Contributor

dwrz commented Aug 18, 2017

I'm still getting stuck modifiers with my keymap on the Planck, piemod.

I have #define PREVENT_STUCK_MODIFIERS in my config.h. Despite that, my Ctrl, Alt, and Meta keys are getting stuck on layer changes.

Two examples:

Actual Behavior
Holding A will create a temporary arrow layer. If I want to move by word in a text editor, I will press and hold Ctrl and A, then tap S and T to move left and right. This works fine. However, upon releasing both Ctrl and A, the former remains activated (stuck), despite the layer change (back to the default layer).

Expected Behavior
As above, but after releasing A, Ctrl should be disabled.

Actual Behavior
Pressing and holding E will create a temporary number layer. I use Meta and a number to switch desktops in i3wm. To switch to desktop 1, I press and hold Meta + E, then tap W (which acts as 1 on the layer). This also works fine. However, upon releasing Meta and E, the former is stuck as active. Thus, if I happen to press L after a desktop switch, I activate i3-lock and lock my desktop (which is bound to Meta + L).

Expected Behavior
After letting go of E, Meta should not be active. Pressing L after the layer is deactivated should just output an l, and not Meta + L.

Code
For the above, the following creates the momentary layers in my keymap:

  [1] =  ACTION_LAYER_TAP_KEY(1, KC_A),     // FN1 = Momentary Arrow layer on A.
  [3] =  ACTION_LAYER_TAP_KEY(3, KC_E),     // FN3 = Momentary numbEr layer on E.

These functions are referenced on the default layer:

    [DVORAK] = {
        {KC_ESC,  KC_QUOTE,  F(7),  KC_DOT,  KC_P,  KC_Y,  KC_F,  KC_G,  KC_C,  KC_R,  KC_L,  KC_DELETE},
        {KC_TAB,  F(1),  F(2),  F(3),  F(4),  KC_I,  KC_D,  KC_H,  KC_T,  KC_N,  KC_S,  KC_ENTER},
        {KC_LSHIFT,  KC_SCOLON,  F(5),   KC_J,   KC_K,  KC_X,   KC_B,   KC_M,   KC_W,  KC_V,  KC_Z,  KC_MINUS},
        {F(10), F(6),  KC_MENU, KC_LALT,  KC_LGUI,  KC_BSPACE,  KC_SPACE,  KC_RCTRL,  KC_LEFT,  KC_DOWN,  KC_UP, KC_RIGHT},
  },

Further Info
The issue is more pronounced on my Plancks than on my Let's Splits. It happens consistently on the Planck, but only erratically on a Let's Split. My guess is this is because of latency on the Let's Split, but I'm not sure.

@jackhumbert
Copy link
Member

Have you tried using KC_TRNS instead of KC_NO in the spots you have mods at on the higher layers? This should allow the mods' key-up events to be sent.

@dwrz
Copy link
Contributor Author

dwrz commented Aug 23, 2017

Thanks so much, Jack! That was it. Everything seems to be working.

@dwrz dwrz closed this as completed Aug 23, 2017
@jackhumbert
Copy link
Member

Awesome :)

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