Closed manyfew closed 5 years ago
Yes, this is normal.
It's handled this way, because the new layer may not be on the new layer. So .... if you let go of it on the new layer, it wouldn't be registered and you'd have a stuck key.
As for remembering, yes, that would be nice, but many of the controller have very limited RAM, making storing it very tricky.
Can we revisit this issue? Heres a perfect use case:
Holding W to walk in a game and using fn+1 for f1 and you stop moving until you re-hit w.
this is less then ideal and to my knowledge no other firmware has this limitation.
thanks,
Is this really because of limited RAM? From a users respective, the way this works ATM is wrong---If the key is physically down, key up should not be sent automatically for me.
This has been fixed now. Update your repo, and it should be the default behavior.
You can revert by defining STRICT_LAYER_RELEASE
.
Hi. Nice to option but old builds could do with the old behaviour. As games and industrial process control systems have different ideas about safety of unexpected stuck keys. Any plans for a source build date #define?
Full disclosure: I'm a newbie using an Ergodox EZ here, haven't actually built my own firmware (yet). I have a key configured as Ins on Layer 0. I also have another key mapped to MO(1). If I press and hold Ins, as soon as I press the layer toggle key Ins up is sent, but the key is still being physically held down. Wouldn't it be useful if QMK could remember the layer where key-down occurred, and preserve the context through to key-up?