How to get Super Fast keyboard repeat rate

friquant

friquant

Using kbdcontrol() the keyboard rate allows a "fast"setting

Code: 
kbdcontrol -r fast

Are there other tools that can override this to effect an even faster keyboard repeat rate? (less initial delay, and less subsequent delay?)

I'm not currently using xorg, so I'd rather find solutions that do not involve xset.
 
Negative. kbdcontrol(1) sends a command to the keyboard controller – the integrated circuit inside the keyboard – which in turn implements the typematic mechanism. The (delay, repetition rate) tuple is encoded in one byte and are indices in a look‑up table associated with pre‑set values. You cannot choose arbitrary delay and rate values.
This answer applies at least to the IBM PC BIOS era. Maybe today USB keyboards and UEFI allow for faster rates.​
 
In X.org: xset r rate 170 100
170 = start delay, 100 is repeat delay.
1 of the most important Xorg useability settings.
 
Kai Burghardt said:
Negative. kbdcontrol(1) sends a command to the keyboard controller – the integrated circuit inside the keyboard – which in turn implements the typematic mechanism. The (delay, repetition rate) tuple is encoded in one byte and are indices in a look‑up table associated with pre‑set values. You cannot choose arbitrary delay and rate values.
This answer applies at least to the IBM PC BIOS era. Maybe today USB keyboards and UEFI allow for faster rates.​
Click to expand...
What if your vt terminal program uses scanf() or some other call that allows a CLI loop that reads the total keyboard state in a given frequency? Never needed anything like it but I think it should be possible.
 
friquant said:
When using Xorg are you able to effect arbitrary delay and rate values?
Click to expand...
Not sure what you mean with that. The delays for xset are in milliseconds. I dont know what the limits are. You can set it so fast that it's impossible to get 1 character per keypress.
Anyway, it covers the full graphical X.org input. If you change the xset values in xterm, it will also be set for the input of your browser adress bar and other things with keyboard input.
 
friquant said:
When using Xorg are you able to effect arbitrary delay and rate values?
Click to expand...
This is evidently implemented by software:​
  1. Set the hardware’s typematic to its slowest setting.
    Bash: 
    kbdcontrol -r slow # invoked from the `vt`/`sc` terminal
  2. Switch to X.​
  3. Open a terminal emulator and run as root:
    Bash: 
    hd /dev/input/event5 # event5 needs to be adjusted to your hardware
  4. Temporarily set X11’s repeat rate to an insane value.
    Bash: 
    xset r rate 1 250 ; sleep 8 ; xset r rate 500 20
  5. Press and hold any key (that produces a visible character according to the currently loaded keyboard map) while the hd(1) window is visible. You see /dev/input/event5 receives data every 500 ms, yet under X11 you get a torrent of 250 character per second.​
 
MG said:
Not sure what you mean with that. The delays for xset are in milliseconds. I dont know what the limits are. You can set it so fast that it's impossible to get 1 character per keypress.
Anyway, it covers the full graphical X.org input. If you change the xset values in xterm, it will also be set for the input of your browser adress bar and other things with keyboard input.
Click to expand...
I found the source file for kbdcontrol. I'd like to try compiling it with different possible values for the -r option.

Since MG has verified that with xset you can supply arbitrary values for initial delay and repeat rate, I am hoping there are no roadblocks in whatever it is that kbdcontrol calls. No roadblocks to getting a faster repeat rate, I mean.
 
Looking at /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c, the "fast" rates are the bottom. However, /usr/src/sys/dev/atkbdc/atkbd.c seems to set values at driver level (search word "delay" in file). Not sure how this works. It would require a world testing system on real hardware.

What I'm quite sure about is that you can work around this. There is no rate set by the hardware of modern keyboards. That's just the controller processing speed. Maybe still in 16-bit real mode but that's not relevant.
How about reading the USB-device directly with some tool and guide the data to stdin?
 
Inside sway, kbdcontrol had no effect and emitted a warning:

Code: 
$ kbdcontrol -r fast
kbdcontrol: fallback, setting keyboard rate via legacy interface (KDSETRAD), will be removed soon: Inappropriate ioctl for device
kbdcontrol: setting keyboard rate: Inappropriate ioctl for device

But this page showed me how to configure repeat rate in the sway config file:

Code: 
# /home/$USER/.config/sway/config
...
input "type:keyboard" {
    # Initial delay (milliseconds)
    repeat_delay 180

    # (characters per second)
    repeat_rate 60
}

So inside sway I now have the settings I prefer.

I'm still using kbdcontrol -r fast in the system and virtual consoles, which is not as fast as I'd like but faster than the defaults.
 
You must log in or register to reply here.
Back
Top