getreuer
commented
3 months ago Thanks for the report!
The three I have found so far to have this problem are \, =, and ;. I use a modified Engram layout, with these key:shift pairs: 1:\ 2:= ,:;.
Your set up has e.g. a , (KC_COMM) key that becomes ; (KC_SCLN) when pressed with Shift, is that right? A pattern is that \, =, and ; are normally all unshifted keys. This should work. I'm noting this as an interesting possible clue to the underlying cause of the stuck shift bug. Assuming you otherwise follow the shifted layer on https://engram.dev, it appears all other customized keys shift to ~ + < > ^ & % * } @, which are normally shifted keys (does that hold up?).
I attempted to repro the bug with a OSM(MOD_LSFT) key and custom shift keys configured as:
const custom_shift_key_t custom_shift_keys[] = {
{KC_COMM, KC_SCLN},
};
uint8_t NUM_CUSTOM_SHIFT_KEYS =
sizeof(custom_shift_keys) / sizeof(custom_shift_key_t);For better or worse, I can't get shift stuck and the ,; key is functioning as it should.
Let me know if I missed something.
Describe the bug
If I use a one-shot shift like
OSM(MOD_LSFT)on a key with a custom shifted value, it does indeed type the custom shifted value as you would expect. However for some custom shifts it seems like the shift key becomes "stuck" after that point, and all keys get typed shifted until you "unstuck" shift. I do this by just long pressing and releasing the same shift key (making it bypass the one-shot functionality).Most custom shifted keys work totally fine with one-shot shift. The three I have found so far to have this problem are
\,=, and;. I use a modified Engram layout, with these key:shift pairs:1:\ 2:= ,:;. All other custom shifted pairs seem to work great (which is why it took me a while to even realize this was happening).I do use achordion but this problem occurs regardless of which one-shot shift used.
Information
Do the keys involved use any of the following features?