Programming

I bought a "gaming" mechanical keyboard from ANT eSports, which boasted 6KRO (or some number like this) Anti-Ghosting and RGB backlight written in some parts of the package, while rainbow LED was written in others.

Result:

• I learnt that "rainbow" is not RGB
• It was not anti-ghosting. In fact it failed some common key combinations that even a $2 Dell keyboard did pretty well.
• its switches started going bad at day 3, which I only realised after opening the switch and realising that the bent contact material of the Kailh Red switches were not springy and were just getting stuck in position.
  • I guess this one is my bad for asking them to just hand me the display model

As far as latency goes, there is a point that I read somewhere that it's better to connect User Input devices to USB 2 slots, which are on a separate hub from the USB 3 slots that you might have connected storage or networking devices to.

Most of my gaming related problems have come up related to nKRO (the absence of it). Be it space games like X4 and Elite: Dangerous or Hollow Knight ^[this one, I actually paused mid-game when I realised that the ghosted keys were making the play un-fun, so now I will either afford to buy/make a good nKRO keyboard or not play it and maybe not end up buying Silksong 😢].

I am usually too slow to notice latency in gaming cases. But I do in case of music, making me unable to use a keyboard on a computer as a musical keyboard (making music in realtime). Though the context was a heavily laggy game with a musical minigame, so it might be different when using proper musical software. I still expect it to make a big difference though.

keyboards use a matrix that has to be scanned instead of having a wire per-key because it saves a few bucks

Hehe, this was a fun statement. I was actually looking into making a keyboard for myself and while looking for available microcontrollers I could use, I found out that the difference between not using a scanning matrix (1 wire per key) and using one wa not being able to even make a 75% vs having enough address space for a 105 + 12 (extra fn keys F13 to F24 and more macro keys) layout.

I would have had to go with a PLCs or Ultrascale FPGAs with unnecessarily high processing power, because components are usually easily available for less I/O with higher throughput instead of greater parallel I/O.

On the other hand, by my calculation it was pretty easy to match the 1kHz overall polling rate using the polling rate available on the I/O pins available on a Raspberry Pi (or was it an Arduino I calculated it for? I forget), so key -> controller software latency shouldn't be a real problem.