Port keystroke delay.

[kareltucek]

Closes #353.

[kareltucek]

(This, if set to non-zero value, currently slows down all firmware scancode actions such as macros or caret mode. Atm., I consider it a feature...)

[mondalaci]

I set the delay to 300. The first character appeared instantly, then rapidly typed characters afterward appeared with significant delay. The delay wasn't 300 ms, but more like a second, and shortly, some of the keys behaved as they got stuck.

[kareltucek]

I set the delay to 300. The first character appeared instantly,

This is correct.

then rapidly typed characters afterward appeared with significant delay. The delay wasn't 300 ms, but more like a second, and shortly,

300ms is interval between report changes. Since every keystroke consists of two such changes (keydown and keyup) or more (extra modifier reports), the observed delay should be 600ms. Give or take 30% on inaccuracies of the firmware timer.

some of the keys behaved as they got stuck.

The postponer's queue is 32 events deep, which is 16 keystrokes. If it gets almost filled, it will usually start replaying keys one by one even if the postponing mode is kept active, except for the keystroke delay which is honored in all situations.

So if you set this ridiculously long delay and overfill the buffer, then I guess loosing some of he events is an almost correct behaviour. Except that having keys stuck is not good -> fixed.

[mondalaci]

The stuck keys issue got resolved, indeed, but

1. When I use the 300ms value, type "asdf" quickly, and don't hold the "f" key, I get "asdffffffffffffffffff".
2. When the postponer kicks in, module pointer movement becomes jaggy.

I'm unsure whether the above is considered normal, but they're not ideal.

[kareltucek]

The stuck keys issue got resolved, indeed, but

1. When I use the 300ms value, type "asdf" quickly, and don't hold the "f" key, I get "asdffffffffffffffffff".

Standard "autorepeat" delay of most operating systems is 400ms. Which means that yeah - by definition the behaviour is correct. (And at 5ms resolution is a non-issue.)

2. When the postponer kicks in, module pointer movement becomes jaggy.

I'm unsure whether the above is considered normal, but they're not ideal.

This is again specific to the keystroke delay, not to the postponer. Since I never move cursor while writing heavily at the same time, I consider it a non issue. Of course the situation can be improved, but would probably need some refactors and would make the code more complex.

[mondalaci]

I've been testing more in the meantime. Even a 10ms delay interferes with the caret mode substantially, as caret navigation becomes slower, and I often change lines in the IDE inadvertently.

[kareltucek]

Sorry for the delay - this inquiry needed a bit testing and thinking on my part... unfortunately while testing the 10ms delay + caret mode, I have ran into strange problems (namely caret mode getting stuck) that so far withstanded all my debugging attempts.

But to the point:

I've been testing more in the meantime. Even a 10ms delay interferes with the caret mode substantially, as caret navigation becomes slower, and I often change lines in the IDE inadvertently.

The keystroke delay inherently does slow down the caret navigation. That is known since by definition it is supposed to make firmware send at most one usb state change per the delay interval. After looking into the code, I am afraid I am not able to make an exception for the caret mode in a simple manner.

Also, axis locking breaks due to the keystroke delay, since over the 10ms chunks of time, much larger deltas are fed into the algorithm - namely sufficiently large to override current lock. I can deal with this by resetting the module deltas over the delayed time. This is also likely to solve the problem which I mentioned in the beginning, but unfortunately without uncovering the root cause.

The question is whether such solution is desired.

[mondalaci]

@kareltucek Thanks for your PR and for addressing the pointer delta issue!