You are right it is more risky than doing it in software. Something similar as what you describe is how it was done in the older computers like the Commodore machines and the BBC Micro I have looked at how they did it. Perhaps I could use some programmable logic that would also reduce the number of chips and that is also reprogrammable in case of mistakes. But I don't have any experience with that except for programming a ROM chip if that counts as programmable logic.

It's not just the scan/decode choice.

If you have a completely cpu driven keyboard scan (i.e. the main CPU, not an auxiliary part) then it has to spend a certain amount of it's time just scanning the keyboard, as well as managing the debounce and rollover in software. If you have a completely hardware approach, you need to know when a key is ready, so probably an interrupt, as well as handling (probably) debounce and rollover.

Similarly for something like PS/2, you either need to poll the clock line - rapidly - or have it trigger an interrupt (again, processor time) to decode the data, and you still need to sort out the keydown/keyup messages as well (you might want both edges of a key press, as Windows did (does? I'm out of touch) in an event loop).

My split the difference approach I think will be to use an external processor to mediate a PS/2 keyboard, read the individual packets, and spit them out as serial data - so I'll still need to sort out keydown/up messages at the processor, but the PS/2 sorts everything else out. (Or I can make it just send the keydowns as they happen and sort out control and shift there.) As it happens, I already have an SPI uart, so adding another is no great shakes.

I could do this with an eight-pin part, but I have a box full of STMs with 48 pin, so that's what it'll likely be.

(Or alternatively, use the same STM to handle an external UART channel and talk to it by SPI, let it sort out streams from serial port and keyboard. Time to play.)

Neil

Windows does keep track of the make/break state of each key on the keyboard (somewhat) for video games.

Imagine if you will a typical modern game these days that likes to use WSAD for forward, backward, left, and right movement. Very often players will push Some combination of Forward+Side or Backward+Side.

They may also have something like 'F' to interact, or 'Space' to jump.

If all you want to do is type, then yea, keeping detailed track of the make/break codes doesn't make sense. Last key pressed is good enough, but if the game engine forgot you were pressing "forward" when you hit "jump" and you ended up falling into the bottomless pit because of it, you wouldn't have very happy players.