tuning latency / debouncing for CTL_T

[wez]

Prior to getting a hardware keyboard and programming it, I was using Karabiner to turn my capslock key into CTL_T(KC_ESC). This worked really well. Since I switched to a hardware implementation of this, I'm finding that I'm typing too fast for the firmware to register CTRL-W arrow (that's a CTRL-W followed by an arrow) which I use to navigate around in splits in vim.

I turned up debugging on the console and captured these two sequences to show what the keyboard is sending to the host system:

keyboard_report: 00 00 29 00 00 00 00 00 00 00 00 00 00 00 00 00
keyboard_report: 00 00 29 1A 00 00 00 00 00 00 00 00 00 00 00 00
keyboard_report: 00 00 29 00 00 00 00 00 00 00 00 00 00 00 00 00
keyboard_report: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
keyboard_report: 00 00 51 00 00 00 00 00 00 00 00 00 00 00 00 00
keyboard_report: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<that failed>


keyboard_report: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
keyboard_report: 01 00 1A 00 00 00 00 00 00 00 00 00 00 00 00 00
keyboard_report: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
keyboard_report: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
keyboard_report: 00 00 51 00 00 00 00 00 00 00 00 00 00 00 00 00
keyboard_report: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<that worked>

The first one of these is me typing at my normal speed, and the second is me introducing what feels like a very exaggerated delay in my typing.

I think that my ESC press is getting debounced out? I quite often end up with W being sent bare (no CTRL) or sometimes as just ESC.

The question is, what parameters are available to tune the timing around this?

[wez]

I've traced this to the ergodox_ez IGNORE_MOD_TAP_INTERRUPT define. Removing it solves this particular problem... checking to see if it causes me any others :-)

[ezuk]

Nice! How's it been so far?

[wez]

Working well for me! I have a reasonable fix in my branch (see referenced commit above) but it depends on #151

[ezuk]

@wez - I see that hasn't been submitted as a pull request here? Or am I missing something?

[wez]

I have a couple of things in my branch that I'd like to get merged here before I submit a PR for this one thing; didn't want to bomb you all with everything at once, and it is easier to submit them as bits are accepted :-)

[ezuk]

Makes sense! :)

On 23 February 2016 at 21:40, Wez Furlong notifications@github.com wrote:

I have a couple of things in my branch that I'd like to get merged here
before I submit a PR for this one thing; didn't want to bomb you all with
everything at once, and it is easier to submit them as bits are accepted :-)

—
Reply to this email directly or view it on GitHub
#142 (comment)
.

[piotr-dobrogost]

@wez
Do you still plan to submit PR for this issue?

[piotr-dobrogost]

From #366 (comment):

But I can tell you that #142 was never made into a PR, so the change isn't reflected in the keymap settings. Would you like to try playing with that constant yourself and seeing if it helps? Are you all set up with a build env?

I will try it out and report here. Build env shouldn't be a problem.
Is dual-role implementation part of tmk or did you implement it in qmk directly? What's the policy regarding bringing code from tmk project?

[eltang]

@piotr-dobrogost @ezuk As far as I know, the ErgoDox EZ's default layout needs the feature, or people will start activating Ctrl unintentionally while trying to type the Z key or the / key. The ErgoDox EZ's config.h file documents this pretty clearly.

@piotr-dobrogost However, you can use a config_user.h file, which is described here, to override the setting. Dual-role keys were grandfathered from TMK. What feature would you like to port to QMK?