Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keyboard Ghosting Explained

microsoft.com

Post reply on HN
Print view View original

51–60 of 99 posts

Re: Keyboard Ghosting Explained

#51

Post by sharpneli »

klipt wrote: post #49
ChuckMcM wrote: post #24

I am always amazed that keyboards still do this. We have scanning matrices because back when I was a new engineer pins on a microprocessor were both expensive (larger packages) and they required more gates in the CPU (more expensive CPU) or chip doing the scanning. Today transistors are free and surface mount BGA packages can put down a lot of pads pretty simply[1]. So your typical 104 key keyboard could actually hav…

> However, because this requires printing a circuit board with over a hundred diodes, it is relatively expensive. So we can stick millions of transistors on an integrated circuit, but a hundred diodes? Too difficult!

"We can stick millions of bytes on an image, but hundreds of small transactions? Too difficult!"

The transistors on an IC are like pixels on an image. Every individual component is a single transaction. Not surprisingly it's way cheaper to transfer an 1MB picture than 100 small requests that each have their own overhead.

It's a difference between the processes they are made with. It would also be expensive to have hundreds of individual transistors. It's the fact that they live in the same packaging and are manufactured at the same moment into the silicon what makes them cheap.

Re: Keyboard Ghosting Explained

#52

Post by simonh »

BoppreH wrote: post #15

When developing Flash games this was a personal hell. Many keyboards are unable to process Up+Left+Space, usually meant for shooting at northeast. In this case one of the keys is simply ignored. Worse yet the other directions work, so you get a hard to diagnose bug. The users end blaming you for their character deaths and the overall experience is frustrating. The best solution I found was to use a different key for…

Or a small, but significant number of other people's keyboard manufacturers. Welcome to lowestcommondenominatorland.

Re: Keyboard Ghosting Explained

#53

Post by dools »

I wonder why they scan the keyboard as a set of columns and rows!! When I was at University, I created a 49 note midi controller from a discarded electric piano keyboard.

Basically I got the hardware and wrote software for a Motorola 68hc11 to control it. The way it worked was that you would put a value on an 8 bit register that would activate one "bit". This bit would be connected to 8 different keys on the keyboard. You would get an 8 bit value out the other end that would tell you which keys were connected at the time.

So for example the value:

01000000

might correspond go keys 1, 6, 11, 16, 21, 26, 31 and 36. If you got the value:

01011001

out the other end, you knew that keys 6, 16, 21 and 36 were pressed. The 68hc11 scanned so fast that you couldn't fool it. I remember my professor standing there for ages mashing the keyboard trying to get it to break with different key combinations.

If such an old microcontroller could handle 48 keys so easily, why the hell would a modern microcontroller not be able to use the exact same method? ie. instead of doing it in "rows and columns" just treat the keys as a linear array and deal with which keys are pressed and which aren't.

Re: Keyboard Ghosting Explained

#54

Post by kevingadd »

qnaal wrote: post #44
Zr40 wrote: post #32

Earlier quoted context omitted.

Not true. A USB keyboard must declare the number of simultaneously pressed keys it is able to report. It just happens that the example descriptor included in the USB spec has this value set to 6.

'USB spec'- so it's up to the keyboard driver your operating system provides to actually set the limit? And other than that, there's no artifact of the protocol that would hinder the development of such support?

Descriptors are provided by devices, not drivers.

Re: Keyboard Ghosting Explained

#55

Post by ilitirit »

I remember having to work around this when I created an arcade stick with the guts of an old PS1 keyboard. I used an Excel Spreadsheet to map the keys and to figure out which combinations of inputs would result in the least amount of blocking/ghosting in practice.

So basically, if you have a two-stick console with 6 buttons for each player, you had to wire it in a way that was impossible for Player 1 to ghost/block Player 2's keys (and vice versa). So when you found a combination that ghosted/blocked, you'd just map them to opposite directions on the same side since it's not possible to press UP+DOWN or LEFT+RIGHT at the same time on a joystick.

Here are some details: http://arcadecontrols.com/arcade_input.shtml#KeyboardGhostin...

Re: Keyboard Ghosting Explained

#56

Post by leoc »

ChuckMcM wrote: post #24

I am always amazed that keyboards still do this. We have scanning matrices because back when I was a new engineer pins on a microprocessor were both expensive (larger packages) and they required more gates in the CPU (more expensive CPU) or chip doing the scanning. Today transistors are free and surface mount BGA packages can put down a lot of pads pretty simply[1]. So your typical 104 key keyboard could actually hav…

Indeed there are now lots of high-end keyboards with no (or effectively almost no) keyboard-matrix ghosting problems. Actually, many of them still have USB-related rollover limitations: it's hard to fathom how someone can design a brand-new USB keyboard with no rollover limitations in the keyboard matrix, price it at $100+, and still not think (or bother?) to implement the obvious multiple-USB-keyboards workaround—looking at you, Razer!—but there you are. Still, you can find ones (like the Sidewinder discussed in the OP) with competent USB, or you can fall back to PS/2 (welcome to the future).

To my mind the interesting problem is how to get NKRO down into every keyboard. I'm sure it's possible with sufficiently clever engineering, but even with an almost-zero cost burden over bog-standard 2KRO this is almost certainly one of those frustrating situations where mass quality is achievable but only if you can get customers and manufacturers to know and care enough.

> Sure its more expensive than the $0.75 AVR chip they currently use but we're talking high end keyboards here.

Would extra PCB layers would be another significant source of increased cost here?

Re: Keyboard Ghosting Explained

#57

Post by qnaal »

kevingadd wrote: post #54
qnaal wrote: post #44

Earlier quoted context omitted.

'USB spec'- so it's up to the keyboard driver your operating system provides to actually set the limit? And other than that, there's no artifact of the protocol that would hinder the development of such support?

Descriptors are provided by devices, not drivers.

Sorry, I'm not very familiar with how the usb protocol works- but I meant, that not all OS-provided keyboard drivers support devices with up to 100-whatever simultaneous keypresses, right?

I've seen keyboards with what looked like hardware 'nkro' toggles, and overheard discussions to the effect that many implementations of nkro over usb are sometimes 'unreliable', which sounds like inexcusable behavior on either part of the keyboard's controller, the software driver, or the protocol itself.

Re: Keyboard Ghosting Explained

#58

Post by dfox »

dools wrote: post #53

I wonder why they scan the keyboard as a set of columns and rows!! When I was at University, I created a 49 note midi controller from a discarded electric piano keyboard. Basically I got the hardware and wrote software for a Motorola 68hc11 to control it. The way it worked was that you would put a value on an 8 bit register that would activate one "bit". This bit would be connected to 8 different keys on the keyboard…

Your scheme is essentially same as is used by keyboards and has the same problem. When you press two keys that are connected to same output wire, additional keys on these two inputs are ambiguous. There are some software tricks related to the fact that nobody presses multiple keys at exactly same time, but the root problem still exists.

Re: Keyboard Ghosting Explained

#59

Post by dfox »

Zr40 wrote: post #32
qnaal wrote: post #8

Fun Fact: The standard USB keyboard protocol can't handle more than... 6? non-modifier keys being pressed at the same time. IIRC, to get past this, all you need to do is emulate a hub with fifteen or twenty keyboards attached. Then you can press every key at once!

Not true. A USB keyboard must declare the number of simultaneously pressed keys it is able to report. It just happens that the example descriptor included in the USB spec has this value set to 6.

Resulting HID report has to fit into 8 byte payload of low speed interrupt frame, which works out as 6 bytes for keys, 1 byte for LED states (which is arguably redundant) and one byte for modifier keys.

On the other hand I can't understand why they had designed HID in this way, when essentially all previous PC keyboard interfaces worked by sending state changes (key down/key up) and not full state. It's not like that generating down/up events would add significant complexity to keyboard, there has to be whole lot of stuff for the USB itself and also it's already there for PS/2.

Re: Keyboard Ghosting Explained

#60

Post by sspiff »

They fail to address the way they solved the protocol problem (only being able to encode 6 keys in one event).

I'm assuming they went the custom-protocol-extension route, meaning sending more than 6 keys restricted to Windows-only drivers?

Or did they do something else?

Post reply on HN