MFC r304735 and r331692:
Fix key delay and repeat, part 2.
Use sbintime_t timeouts with precision control to get very accurate
timing. It costs little to always ask for about 1% accuracy, and the
not so new event timer implementation usual delivers that, and when
it can't it gets much closer than our previous coarse timeouts and
buggy simple countdown.
The 2 fastest atkbd repeat rates have periods 34 and 38 msec, and ukbd
pretended to support rates in between these. This requires
sub-microsecond precision and accuracy even to handle the 4 msec
difference very well, but ukbd asked the timeout subsystem for timeouts
of 25 msec and the buggy simple countdown of this gave a a wide range
of precisions and accuracies depending on HZ and other timer
configuration (sometimes better than 25 msec but usually more like 50
msec). We now ask for and usually get precision and accuracy of about
1% for each repeat and much better on average.
The 1% accuracy is overkill. Rounding of 30 cps to 34 msec instead of
33 already gives an error of +2% instead of -1%, and ut AT keyboards on
PS/2 interfaces have similar errors.
A timeout is now scheduled for every keypress and release. This allows
some simplifications that are not done. It allows removing the timeout
scheduling for exiting polled mode where it was unsafe in ddb mode. This
is done. Exiting polled mode had some problems with extra repeats. Now
exiting polled mode lets an extra timeout fire and the state is fudged
so that the timeout handler does very little.
The sc->time_ms variable is unsigned to avoid overflow. Differences of
it need to be signed. Signed comparisons were emulated by testing an
emulated sign bits. This only works easily for '<' comparisonss, but
we now need a '<=' comparison. Change the difference variable to
signed and use a signed comparison. Using unsigned types here didn't
prevent overflow bugs but just reduced them. Overflow occurs with
n repeats at the silly repeat period of [U]INT_MAX / n. The old countdown
had an off by 1 error, and the simplifications would simply count down
1 to 0 and not need to accumulate possibly-large repeat repeats.
PR: 226968
Sponsored by: Mellanox Technologies