Accepting more simultaneous keyboard inputs

The quote from the other forum is completely incorrect...

Keyboards always use a matrix and an 8x8 arrangement on the key membrane / microswitches would cover 64 keys. Sending power down a common row and picking up which column(s) (if any) power was connected to one at a time - it just scans very quickly. The controller chip can easily determine as many keys down at one time as it wishes (including all of them) without taking any kind of performance hit (it has to poll every key anyway, up or down).

That info is then serialised by the keyboard to inform the host which events have occurred (limiting factors being the design of the chip #1 and the amount of traffic it wants to put on the bus #2). They're converted into the appropriate OS events by the drivers (limiting factor #3). Those events are then handled by applications, which in turn may have their own limits on the number of keys they track (#4).

There's a lot going on, but they haven't used 1 wire per key + ground since about the 60's. And if you don't think the matrix could scan fast enough - look at any lcd/led screen, that's the same matrix happening, just in reverse.

If you want this fixed you need to purchase a pricey-er keyboard.

A program called GlovePie allows programmable input from different sources and can resolve this problem. GlovePie download page Here.~

For instance, I'm developing an RPG game, and my laptop's keyboard cannot detect a combination of Run + Up + Left (run northeast). However, if I plug in my USB Logitech controller and map those exact keyboard keys (Up, Left, and B [to run]) to the controller's buttons using GlovePie, I can do the command to run northeast with no issues.

As for your questions, I'm unsure exactly why programs react differently to keyboard input, but it could be with how they detect your input. For example: a Java-based game may detect DirectInput (the signature sent from your input/output devices) while an emulator (like the SNES emulator ZSNES for PC) may detect only the instance of the "Up" key being used. Another input-emulation program, AutoHotkey, cannot control a java-based game because it doesn't use the same form of input the game detects (it doesn't use Java's DirectInput).

So, in order to get more keys, I'd use a USB controller with GlovePie running.

Quote from another forum: "It isn't really a problem (technically). The solution is quite simple but increases the cost of the keyboard. Consider this simple problem: You have 64 keys. How many wires do you need if you want to distinguish every possible simultaneous key press. Answer: 65, One common and one for each key. However, if you arrange the keys in an array with 8x8 keys you only need 16 wires. 8 for the columns and 8 for the rows. This reduces the amount of pins on the keyboard controller chip and makes the keyboard a lot cheaper to produce. All keyboards I have ever seen are produced this way."

I found a good article Keyboard Ghosting Explained!, that explained all I needed to know on this issue. And it has a test area so I could find which combinations of keys on my laptop don't play together nicely.