Disabling `tapping force hold` seems to have reduced the number of times the accidental lock happens, but didn't eliminate it.
ZSA support -- _who are awesome, BTW_ -- said that there's been some recent work in QMK that's related, but that there isn't a way to prevent locking in Oryx yet.
It seems like sometimes both the left-shift and right-shift both get locked, and unlocking the left-shift doesn't unlock the right shift.
I'm gonna try making all the modifiers "left", and see if that helps.
Yeah, it feels like "all left mods" has helped significantly, but not removed the problem entirely.
I've also noticed that it often seems like OSM Meh is what triggers the lock, and all 3 mods have to be unlocked.
I asked ZSA if there's a way to log what keys are being pressed and how the board interprets them, and they said:
>QMK has [some debugging tools](https://docs.qmk.fm/#/faq_debug) available, although I don't know if any of them will give you exactly the information you're looking for. If you'd like to check it out, though, you can download the source files for your Oryx layout and use those as the basis of a QMK layout you'd edit and compile locally (you can compile against our QMK fork if you'd like). QMK is well-documented, and they have their own [support resources](https://docs.qmk.fm/#/support) if you have questions.
I don't have time for that right now, but it might provide some helpful details in the future.
The problem here was [the QMK bug](https://github.com/qmk/qmk_firmware/issues/3963). I ended up following one of the suggested workarounds there, and [installed `qmk_firmware`](https://docs.qmk.fm/#/newbs) locally rather than using Oryx.
Once I had that working, I [integrated](https://github.com/iandunn/qmk_firmware/blob/3e40b04774497e52fe2ff40c61dcdba7e76026db/keyboards/ergodox_ez/keymaps/iandunn/keymap.c) Callum Oakley's [alternate OSM implementation](https://github.com/callum-oakley/qmk_firmware/tree/master/users/callum), and it's been working well enough. It has some quirks, but overall is much better than the native implementation.
Disabling `tapping force hold` seems to have reduced the number of times the accidental lock happens, but didn't eliminate it. ZSA support -- _who are awesome, BTW_ -- said that there's been some recent work in QMK that's related, but that there isn't a way to prevent locking in Oryx yet.
Possibly related: https://github.com/qmk/qmk_firmware/issues/3963
It seems like sometimes both the left-shift and right-shift both get locked, and unlocking the left-shift doesn't unlock the right shift. I'm gonna try making all the modifiers "left", and see if that helps.
Yeah, it feels like "all left mods" has helped significantly, but not removed the problem entirely. I've also noticed that it often seems like OSM Meh is what triggers the lock, and all 3 mods have to be unlocked.
I asked ZSA if there's a way to log what keys are being pressed and how the board interprets them, and they said: >QMK has [some debugging tools](https://docs.qmk.fm/#/faq_debug) available, although I don't know if any of them will give you exactly the information you're looking for. If you'd like to check it out, though, you can download the source files for your Oryx layout and use those as the basis of a QMK layout you'd edit and compile locally (you can compile against our QMK fork if you'd like). QMK is well-documented, and they have their own [support resources](https://docs.qmk.fm/#/support) if you have questions. I don't have time for that right now, but it might provide some helpful details in the future.
The problem here was [the QMK bug](https://github.com/qmk/qmk_firmware/issues/3963). I ended up following one of the suggested workarounds there, and [installed `qmk_firmware`](https://docs.qmk.fm/#/newbs) locally rather than using Oryx. Once I had that working, I [integrated](https://github.com/iandunn/qmk_firmware/blob/3e40b04774497e52fe2ff40c61dcdba7e76026db/keyboards/ergodox_ez/keymaps/iandunn/keymap.c) Callum Oakley's [alternate OSM implementation](https://github.com/callum-oakley/qmk_firmware/tree/master/users/callum), and it's been working well enough. It has some quirks, but overall is much better than the native implementation.