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

61–70 of 99 posts

Re: Keyboard Ghosting Explained

#61

Post by esw »

taylorbuley wrote: post #3
gggggggg wrote: post #2

Microsoft make some of the best keyboards there are. Just did some tests on my Sidewinder keyboard, no issue at all there.

It's easy to take good hardware design for granted. Suddenly that Das Keyboard I've been eyeing doesn't look so expensive...

Be advised that the Das is no longer being made by Costar. They've moved to an unnamed OEM in China, and most people feel that the new keyboards aren't as nice. There are lots of other good mechanical keyboards out there, though - Filco, WASD, etc. I have a WASD and I love it.

Re: Keyboard Ghosting Explained

#62

Post by kuschku »

sspiff wrote: post #60

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?

I'm using the Sidewinder X4 on linux, and the anti-ghosting-feature works even without any custom driver, so I assume they used the "register one keyboard as multiple keyboards"-approach.

Re: Keyboard Ghosting Explained

#63

Post by phaker »

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.

It's not just that. USB nkro keyboards can fail in several interesting ways, so they earned a bad reputation. Paradoxically the hacks that work around the standard (e.g. a keyboard reports as several devices behind a usb hub) are more reliable, so many keyboards use that instead.

There are several cases of driver bugs you have to work around and ignoring driver bugs, it's just generally much harder than it should be (which means more device bugs):

* USB HID specifies two interfaces: the full report interface and a simplified "boot interface" that lets you avoid parsing interface descriptors. The boot interface supports only 6 keys, low speed and it's supposed to be used by bioses etc. Some host devices (like TVs) use the boot interface, those can't support more than 6kro.

* A USB device can specify several interfaces, the host selects which one it'll use to talk to it. For HID devices the boot interface (if supported) has to come first. The problem is that sometimes the first one is selected as it's the "default" one. It's not really supposed to happen but when it does, you can't have more than 6kro.

* The number of simultaneous keys a keyboard (one of its interfaces) can report is specified in its interface descriptor. The USB HID spec contains few sentences that can be easily misunderstood to mean that if a keyboard can report more than simultaneous 6 keys, it doesn't support the boot interface. Some bios writers read it that way, so if you have a fully compliant keyboard with nkro, it will fail on some (buggy) bioses.

* USB specifies low-speed (1.5Mbit/s) and full-speed (12Mbit/s) operation (2.0 adds high speed and 3.0 adds super speed). At low speed the payload length of the interrupt frames the HID devices use are limited to 8 bytes, which limits them to 6 keys (one byte is used for modifiers, one is reserved) for one frame messages. It's possible to chain multiple frames per message, but some OSes don't support that. This means that a nkro low-speed keyboard will (on buggy oses) have only 6kro.

* A way to work around the last problem is to make a keyboard that uses the full-speed interface. The problem is that one some systems this fails hard (the keyboard doesn't work at all).

(source: I wanted to make my own dream keyboard. The existing USB HID device implementations i could find had various limitations so I decided that i'd make my own one. I mean, hey, how hard could it be?)

Re: Keyboard Ghosting Explained

#65

Post by dools »

dfox wrote: post #58
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.

But there are no two keys connected to the same output wire at the same time. If I put the value:

00100000

onto the input register, and I get:

01000000

on the output register, that can only correspond to one key at the time I read the register.

EDIT: I think perhaps you're underestimating how quickly a microcontroller can scan a keyboard. If I press 2 keys simultaneously that are both connected to the same output pin on the output register at different times, the rate at which I scan the input register is so fast that it would be physically impossible for me not to detect that as 2 distinct keys being pressed.

Re: Keyboard Ghosting Explained

#66

Post by TheLoneWolfling »

dfox wrote: post #58
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.

No it isn't?

He's basically running sets of 8 keys through a mux, and changing the selector of the mux to scan through the keys rapidly, 8 at a time.

There is one output wire per key, at least until it gets to the mux.

Re: Keyboard Ghosting Explained

#67

Post by chewxy »

chinpokomon wrote: post #47

In the high school computer lab, after I showed my friends how to disconnect from the Novell network so our instructor couldn't watch what we were doing, we used to play a very good Street Fighter 2 clone. I quickly learned all about keyboard ghosting and used it to my advantage to block my opponent from blocking my attacks. When I tried the same tactic on my computer at home, I discovered it didn't have the same pro…

Wait Novell Netware still has that bug? I recall in my A levels day, we would disconnect the LAN cable on a Netware client machine to circumvent having to logon to the network, which gave us control of the local machine.

Re: Keyboard Ghosting Explained

#68

Post by sp332 »

kuschku wrote: post #62
sspiff wrote: post #60

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?

I'm using the Sidewinder X4 on linux, and the anti-ghosting-feature works even without any custom driver, so I assume they used the "register one keyboard as multiple keyboards"-approach.

What does `lsusb` give you?

Re: Keyboard Ghosting Explained

#69

Post by tehwalrus »

leoc wrote: post #56
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—lo…

not an expert but:

I was amazed when my Das Keyboard came with a USB->PS2 adapter, and said to use the PS2 to get N-key rollover (I think it's limited to 6 on USB.)

I am still slightly amazed every time I remember that the older format is higher spec - although I assume it is something to do with bandwidth on a "serial bus" (especially since most keyboards are forced to run at USB1.1 speed, for some reason).

Anyone who can explain these mysteries is welcome to reply :)

Re: Keyboard Ghosting Explained

#70

Post by leoc »

tehwalrus wrote: post #69
leoc wrote: post #56

Earlier quoted context omitted.

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—lo…

not an expert but: I was amazed when my Das Keyboard came with a USB->PS2 adapter, and said to use the PS2 to get N-key rollover (I think it's limited to 6 on USB.) I am still slightly amazed every time I remember that the older format is higher spec - although I assume it is something to do with bandwidth on a "serial bus" (especially since most keyboards are forced to run at USB1.1 speed, for some reason). Anyone w…

I'm not an expert either, but afaik it's not a speed issue, just an issue of compatibility with USB's standard driver-spec-thingy for keyboards: its authors decided that six keys (plus modifiers, iirc) should be enough for anybody, right?
Post reply on HN