[Midnightbsd-cvs] [MidnightBSD/src] e5858e: Fix key delay and repeat, part 1.

[Lucas Holt]

  Branch: refs/heads/master
  Home:   https://github.com/MidnightBSD/src
  Commit: e5858e1979e08b468b50070abb70e829ec7aae2e
      https://github.com/MidnightBSD/src/commit/e5858e1979e08b468b50070abb70e829ec7aae2e
  Author: Lucas Holt <luke at foolishgames.com>
  Date:   2020-11-15 (Sun, 15 Nov 2020)

  Changed paths:
    M sys/dev/usb/input/ukbd.c

  Log Message:
  -----------
  Fix key delay and repeat, part 1.

kbdcontrol -r fast is documented to give a non-emulated atkbd's fastest
rate of 250.34, but is misimplemented to request this as 0.0.  ukbd
supports many nonstandard rates, although it is currently too inaccurate
by a factor of several hundred for non-huge nonstandard rates to be
useful.  It mapped 0.0 to 200.0.  A repeat delay of 0 means a rate of
infinity which is quite fast, but physical constraints limit this to
a few MHz and the inaccuracies made it almost usable.

Convert 0.0 to the documented 250.34.

Also convert negative args and small args to the 250.34 minimal ones,
like atkbd does.  This is for KDSETREPEAT -- the 2 versions of the
deprecated KDSETRAD have bounds checking.  Keep not doing any bounds
checking or conversions for upper limits since nonstandard large
delays are useful for testing.

The inaccuracies are dependent on HZ and the timeout implementation.
With the old timeout implementation and HZ = 1000, 200.0 probably
worked better to emulate 250.34 than 250.34 itself.  HZ = 100 gives
roundoff errors that accidentally reduce the inaaccuracies, and
event timers reduce the inaccuracies even more, so 200.0 was giving
more like itself (perhaps 215.15 on average but sometimes close to
10 msec repeat which is noticebly too fast).  This commit makes 0.0
noticeably too slow, like 250.34 always was.