There are two "scan" rates: the rate at whitch keyboard matrix is scanned by whatever electronics is inside keyboard (that is probably independent of the outside interface) and the rate at which the interface is able to process input events, which for PS/2 means faster that the keyboard can produce them (as keyboard is essentially bus master on the AT/PS2 keyboard "bus") and for USB means as fast as the *HCI pools keyboard for interrupt events (old Apple's ADB works the same way and is in fact to some extent inspiration for USB <3.0 and Firewire "one big bus" high level model).

Edit: then there is third approach: simple keyboard/input devices with serial interfaces, where host provided clock is used to both clock the interface and keyboard scan logic. In essence the whole keyboard then looks like one big shift register. Keyboards that works this way includes original Macintosh, most Wyse and DEC terminals and MIT/LMI/Symbolics Lisp machines (and probably pre-sun4 Suns, sun4 and later have rs232-derived ionterface), also this is the way how controllers for Nintendo consoles before Wii work (IIRC Nintendo calls that "EXI bus") and how PlayStation 1/2 controllers work. IMHO this is to some extent where the idea behind SPI comes from.

A more recent video claims that the PS/2 advantages are negligible even for serious gamers (around 3:40) https://www.youtube.com/watch?v=AWkvzycD5PE

I've gotten a FTDI down to 2 ms RTT, so if done right (using isochronous transfer) you can get USB down to 1 or max 2 ms. Looking at the latencies quoted here and in the article it's certainly not the problem.

Notice that just getting a thread scheduled every 2 ms is already impossible for Windows, certainly one running a game. You'll get a bunch of outliers within the second. So even if you got your keyboard down to 5 ms, great, but you are not running an operating system that can reliably do something within that timespan!

PS/2 supports lots of RGB, I'm using one, because using the USB costs CPU where as the PS/2 does not, and PS/2 gives NKRO and lower latency, however insignificant they are.

It's entirely a preference based thing, the most relevant factor would be whether or not you need to hot swap it.

Pro gamers are paid to use whatever their sponsors want them to use. And if their new fancy keyboard is good enough not to negatively affect their game, I don't see why they would turn down the money.

True. But that is throughout, not latency. Key presses are latency limited, not bandwidth limited.

Yes, they want freesync or g-sync monitors with high refresh rates.

Of course, they've turned to gsync or leave vsync off.

Pro gamers in highly competitive, reaction-based games (such as most first-person shooters) usually disable it, yeah.

And I'm not an expert in this either, but I'm pretty sure double buffering is the norm, whether you use V-Sync or not.

One buffer in which your graphics card works on frames (I'll call this "graphics card buffer") and then a buffer into which finished frames are moved, so that your screen can read them out in peace (I'll call this "pre-screen buffer").

There's also "triple buffering", which introduces another one of those graphics card buffers, so that when a finished frame is being transferred from that first graphics card buffer to the pre-screen buffer, then your graphics card doesn't have to wait for that transfer to finish and can instead start working in the second graphics card buffer right away. (And then it transfers frames from those graphics card buffers in alternating fashion.)

So, the delay that V-Sync introduces is not that. What V-Sync does, is that instead of transferring finished frames from the graphics card buffer(s) into the pre-screen buffer as soon as the frame is finished, it waits with the transfer until your screen has finished with reading out the previous frame.

If you don't wait (have V-Sync disabled), your screen will read out some part of the previous frame and then read out the rest from the new frame. On the screen, you'll see this break between previous and new frame as screen tearing.

So, assuming your screen can display 120 frames per second and your graphics card happens to finish 120 frames in a second, then V-Sync will not introduce a delay. It'll wait once with transferring the first frame, but then they'll be in sync and no further delay should occur.

However, if your graphics card is able to calculate 240 frames per second (and your screen still does 120 frames per second), then with V-Sync, the graphics card buffer will be transferred into the pre-screen buffer only 120 times per second, making the graphics card slow down to 120 frames per second as well.

Without V-Sync, the graphics card buffer will be transferred 240 times per second, regardless of how often your screen can read it out from the pre-screen buffer. This means a frame will get loaded into the pre-screen buffer as your screen is reading it out. As a result, you'll get screen tearing and one half of your screen will be from the new frame, with a 1/240 s = 4.167 ms delay, the other half is still from the previous frame with a 2/240 s = 1/120 s = 8.33 ms delay.

So, a few numbers:

120 FPS with 120 Hz screen = 8.33 ms delay.

240 FPS with 240 Hz screen = 4.167 ms delay.

240 FPS with 120 Hz screen = ½8.33 ms + ½4.167 ms = 6.25 ms delay on average.

480 FPS with 120 Hz screen = ¼(1/480) + ¼(1/360) + ¼(1/240) + ¼(1/120) = 4.34 ms delay on average.

960 FPS with 120 Hz screen = 2.83 ms delay on average.

960 FPS with 240 Hz screen = 2.17 ms delay on average.

Doesn’t the micro controller in the keyboard still scan, and then send a ps/2 signal?