Put a mux on each group of switches, have the microcontroller rapidly scan the muxes to determine which switches are down.
And now all of a sudden you have a keyboard that you can actually press down as many keys as you need and it still works. Except it won't. Because USB keyboards don't support arbitrary numbers of keys being pressed at once.
There is actually nothing in the USB or HID specifications preventing USB keyboards from supporting n-key rollover (when using the report protocol -- keyboards using the boot protocol are limited to a 6-key rollover). The reason most don't is simply to reduce cost and complexity. A sufficiently motivated person could build a USB-compliant keyboard that supported an arbitrary number of simultaneoue keypresses, and some do (e.g. http://www.maxkeyboard.com/max-keyboard-nighthawk-x9-red-bac...).
In particular, if you try to go over 6-key rollover, good luck. You end up having to, and I'm not making this up, emulate a USB hub connected to multiple keyboards. It's absurd. And all because of the following:
"However, the compatibility version of HID that all present systems implement limits USB keyboards to reporting a mere six regular keys together with four modifiers. Additional keys pressed beyond the limit will generally cause some of the other keys to be dropped." [http://deskthority.net/wiki/Rollover,_blocking_and_ghosting#...]
"non-working n-key rollover with a USB connection is a side effect of the data packet." [http://geekhack.org/index.php?topic=5572.msg85020#msg85020]
(Effectively, instead of doing make:key / break:key packets, the compatibility version of HID does current_keys_pressed:[array of 6 keys]. Why they didn't stick with the make/break of the PS/2 protocol is beyond me.)
Say you have N free pins on your controller, and you want to read K keys. Find the smallest integer number of columns such that log2(k/c) + k/c <= n - so, for example, with 108 keys and 20 pins, you can have 7 columns, with 16 rows (keys/column). This means a 3-bit mux, which is relatively easy to find.
Tie each row via diodes to 1 key in each column. Then tie each row to a pin on the controller.
Tie each column to an output of the mux, and tie the input of the mux to Vcc. You'll also probably want to tie each column to a grounding resister as well. Maybe a small cap. (Or just use the chip that does this directly, I can never remember the name. Output selector? Something along that line. "An IC that outputs Vcc on the selected pin and ground on all others".).
Then connect the selector of the mux to the remaining pins on the controller.
To operate, just loop through all valid outputs on the mux repeatedly - probably with gray code, as that way you don't need to make as many pin transitions. Each time you change the output of the mux, read the values of those keys. You'll probably need a mapping of row/column -> key, as well as the previous values of keys. Any time the value of a key changes, output the appropriate packet. (Note: most of the time most keys don't change. As such it may be faster to do a quick check that "old column values == new column values" before checking bits one by one.)
As long as your scan rate is sufficiently high, you shouldn't miss keypresses. (And if you want to get fancy, you can actually borrow a technique from dRAM. Have each key connected from ground to a cap (per-key) to a diode to Vcc. Potentially with a resistor, although the diode might be enough. Then do the above row/column, but tied to the caps / diodes as opposed to the keys themselves. This way you'll be able to read that there is voltage on the cap even if your scan missed when it was down. It also provides a certain amount of debouncing. The disadvantage is that there's a whole lot more per-key.)
Does it support interrupts on the pins? Or just polling?
Also, can you give me a specific example of a specific part? Searching "STM32Fx QFP208 package" gets me... a link to your comment. Great to know that HN gets crawled, but still...
Huh. Something to consider. Thanks for the links!