[QMK] Remapping a key to KC_TAB seems to add unwanted behaviour to the key

[AuditeMarlow]

So I'm trying to get a custom GAME layer going on, and while I've finished the layout and set up layer swaps to the GAME layer, something weird is going on with both of my KC_TAB mappings.

It seems the KC_TAB button mapping is subject to a preconfigured tap dance. Tapping the KC_TAB button properly sends the tab character once. However, when holding down the KC_TAB button, it only sends the tab character once after the configured tapping term. Additionally, when holding down the KC_TAB button, it also sends a shift tap. I was able to confirm this using a simple online keyboard tester.

What I want however is to simply have a plain KC_TAB button mapping, much like a plain KC_SPACE. Can this be done, and if so, how?

Attached below is my custom_config.h.

// Copyright 2019 Manna Harbour
// https://github.com/manna-harbour/miryoku

// This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.

#pragma once

#define MIRYOKU_LAYER_LIST \
MIRYOKU_X(BASE,   "Base") \
MIRYOKU_X(EXTRA,  "Extra") \
MIRYOKU_X(TAP,    "Tap") \
MIRYOKU_X(GAME,   "Game") \
MIRYOKU_X(BUTTON, "Button") \
MIRYOKU_X(NAV,    "Nav") \
MIRYOKU_X(MOUSE,  "Mouse") \
MIRYOKU_X(MEDIA,  "Media") \
MIRYOKU_X(NUM,    "Num") \
MIRYOKU_X(SYM,    "Sym") \
MIRYOKU_X(FUN,    "Fun")

#define XXX KC_NO

#define MIRYOKU_LAYERMAPPING_BASE( \
      K00,  K01,  K02,  K03,  K04,         K05,  K06,  K07,  K08,  K09, \
      K10,  K11,  K12,  K13,  K14,         K15,  K16,  K17,  K18,  K19, \
      K20,  K21,  K22,  K23,  K24,         K25,  K26,  K27,  K28,  K29, \
      N30,  N31,  K32,  K33,  K34,         K35,  K36,  K37,  N38,  N39 \
) \
LAYOUT_split_3x6_3( \
XXX,  K00,  K01,  K02,  K03,  K04,         K05,  K06,  K07,  K08,  K09,  DF(U_GAME), \
XXX,  K10,  K11,  K12,  K13,  K14,         K15,  K16,  K17,  K18,  K19,  XXX, \
XXX,  K20,  K21,  K22,  K23,  K24,         K25,  K26,  K27,  K28,  K29,  XXX, \
                  K32,  K33,  K34,         K35,  K36,  K37 \
)

#define MIRYOKU_LAYER_GAME \
KC_Q,    KC_W,    KC_E,    KC_R,    KC_T,              KC_Y,    KC_U,    KC_I,    KC_O,    KC_P, \
KC_A,    KC_S,    KC_D,    KC_F,    KC_G,              KC_H,    KC_J,    KC_K,    KC_L,    KC_SCLN, \
KC_1,    KC_2,    KC_3,    KC_4,    KC_B,              KC_N,    KC_M,    KC_COMM, KC_DOT,  KC_SLSH, \
U_NP,    U_NP,    KC_LCTL, KC_SPC,  KC_C,              KC_ENT,  KC_BSPC, KC_DEL,  U_NP,    U_NP

#define MIRYOKU_LAYERMAPPING_GAME( \
      K00,  K01,  K02,  K03,  K04,         K05,  K06,  K07,  K08,  K09, \
      K10,  K11,  K12,  K13,  K14,         K15,  K16,  K17,  K18,  K19, \
      K20,  K21,  K22,  K23,  K24,         K25,  K26,  K27,  K28,  K29, \
      N30,  N31,  K32,  K33,  K34,         K35,  K36,  K37,  N38,  N39 \
) \
LAYOUT_split_3x6_3( \
KC_TAB,   K00,  K01,  K02,  K03,  K04,         K05,  K06,  K07,  K08,  K09,  DF(U_BASE), \
KC_ESC,   K10,  K11,  K12,  K13,  K14,         K15,  K16,  K17,  K18,  K19,  KC_QUOT, \
KC_LSFT,  K20,  K21,  K22,  K23,  K24,         K25,  K26,  K27,  K28,  K29,  XXX, \
                      K32,  K33,  K34,         K35,  K36,  K37 \
)

[manna-harbour]

Can you test with Tab on the included Tap layer, and with the Tab on the Fun layer? Also test the same keyboard on a different host, and a different keyboard on the same host. It might be an issue with an application or setting on the host OS.

There is the layer-tap on Tab on Base, and there is a combo on that layer-tap if thumb combos are enabled. But the Tab on Fun and on Tap are basic keycodes so should behave normally.

[AuditeMarlow]

I've tested my keyboard on a different host, with which I'm experiencing the same problem. I've also tested a different keyboard on the same host, which Tab key functions as expected.

Even the Tab on Fun and on Tap layers have the same problem. I'm very confused by this, as you explained these layers have the basic Tab keycode, and additionally so does my GAME layer.

I'll test the Tab keycode on a non-Miryoku layout and report whether or not the problem persists in an attempt to isolate the problem a bit more.

Edit: I've tested the Tab keycode on a non-Miryoku layout and the Tab key behaves as expected there. The problem seems Miryoku related.

[manna-harbour]

Actually, there's also a combo on basic Tab (for the Fun layer) if you have thumb combos enabled. Those combos need to be restricted by layer, so that is an issue at the moment (#56). Do you have thumb combos enabled? What keyboard are you using? That thumb combo also applies to basic Space, so I'd expect the same behaviour there, and it also doesn't explain the Shift issue.

You could try a workflow build from an unmodified branch, and also try merging QMK master and try merging QMK develop.

[AuditeMarlow]

I do not have thumb combos enabled. I'm using an Aurora Corne keyboard from SplitKB. The basic space key behaves like expected.

I'll try your suggestion to merge the QMK branches and report back once I have.

Edit: I've tested the basic Tab key after having merged the QMK master branch into the qmk_miryoku repository, to no avail. The issue persists. :(

[manna-harbour]

Here are builds from miryoku, miryoku + QMK master, and miryoku + QMK develop: https://github.com/manna-harbour/miryoku_qmk/actions/runs/6221317867. You could also try erasing the flash.

[AuditeMarlow]

Those builds will unfortunately not work for my keyboard as I'm using Elite-Pi's. I don't think these boards feature clearing the EEPROM or flash, unless I am mistaken.

Below is the flash command I'm using if that helps to shine some light on the problem:

qmk compile \
  -kb splitkb/aurora/corne \
  -km manna-harbour_miryoku \
  -e CONVERT_TO=liatris \
  -e MIRYOKU_ALPHAS=QWERTY \
  -e MIRYOKU_EXTRA=COLEMAKDH \
  -e MIRYOKU_TAP=QWERTY \
  -e MIRYOKU_NAV=VI

[AuditeMarlow]

I finally took the time to debug this issue and found the problem. The issue was resolved by setting AUTO_SHIFT_ENABLE = no in the rules.mk file. This is on by default in the Miryoku users directory. Enabling this feature will automatically apply the shift modifier when a key is held. This also explains why holding the tab key would additionally send the shift key. By disabling this feature I'm able to hold the tab key without the shift modifier.

For reference: https://github.com/qmk/qmk_firmware/blob/master/docs/feature_auto_shift.md

[manna-harbour]

Glad you found the issue!

It's intended for auto shift to only be enabled for numbers and symbols, so NO_AUTO_SHIFT_TAB should also be set at least. Auto shift should also be disabled on the Tap layer. There should also be an option to enable/disable via custom_config.h.