Keyboard Ghosting Explained • Hacker News Board

Re: Keyboard Ghosting Explained

#71

Post by StavrosK » Fri, Mar 07, 2014, 4:18 PM UTC

TheLoneWolfling wrote: post #66

dfox wrote: post #58

Earlier quoted context omitted.

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.

To be fair, he didn't mention a mux anywhere. I read his comment four times and only figured it out when you replied.

Re: Keyboard Ghosting Explained

#72

Post by dfox » Fri, Mar 07, 2014, 4:30 PM UTC

dools wrote: post #65

dfox wrote: post #58

Earlier quoted context omitted.

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…

The problem happens when you press three or more keys at once in right combination. And is exactly the same regardless whether you scan output wires in sequence (as is done in simple hardware based keyboards of the 70's and 80's) or if you read them all at once.

Going back to your original example, if one would press keys 1, 2 and 6 at the same time your microcontroller would falsely detect 7 as being also pressed (because keys 1 and 6 shorts two input wires together). This assuming that your output register drives strong 1 and weak (preferably floating) 0. If it has strong drive for both 0 and 1, then such combination of pressed keys would cause some unpredictable effect, possibly including burning out the pins.

Re: Keyboard Ghosting Explained

#73

Post by ChuckMcM » Fri, Mar 07, 2014, 4:33 PM UTC

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…

In the case of a keyboard you would not need more than 4 layers even for a fairly dense ball grid chip because you have lots and lots of space (the keys require spacing) and that lets you run traces fairly circuitously. But a 4 layer PCB is about 2.5x the cost of a two layer board in the designs I've done, and still the cost of the PCB is quite small. (One design I did a two layer version was 0.85 per PCB (4 x 3.5") and when I pushed it to four layers to get down to under 4 x 2" it was $2/PCB so 2.35x the cost.)

Re: Keyboard Ghosting Explained

#74

Post by ChuckMcM » Fri, Mar 07, 2014, 4:42 PM UTC

leoc wrote: post #70

tehwalrus wrote: post #69

Earlier quoted context omitted.

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?

Page 59 of the USB HID Spec [1] is the offender, it states:

   The following table represents the keyboard input report (8 bytes). 
 
   Byte Description 
   0 Modifier keys 
   1 Reserved 
   2 Keycode 1 
   3 Keycode 2 
   4 Keycode 3 
   5 Keycode 4 
   6 Keycode 5 
   7 Keycode 6

Which is where the 6 key roll over comes from. However this is really the minimum implementation so that BIOS'es can use USB keyboards. If you read the spec carefully there isn't anything that says you can't implement a different reporting structure, as long as your HID driver is expecting it. My guess is rather than ship "special" keyboard drivers they just use the standard one, and they opt to use PS/2 connectors which work in the same way (they are really just a serial port and can send as many keys as they want) for the 'corner' case of full n-key rollover.

[1] http://www.usb.org/developers/devclass_docs/HID1_11.pdf

Re: Keyboard Ghosting Explained

#75

Post by moron4hire » Fri, Mar 07, 2014, 4:46 PM UTC

No, no, no, no. This is all wrong. This is not why ghosting happens. This is how ghosting happens. The why is "because stakeholders are cheap bastards". Manufacturers are cheap. Consumers are cheap. Consumers don't want to pay for quality and Manufacturers won't hire quality engineers.

But there is an even bigger issue: engineers are cheap, too. Once you get a design that "works", for varying values of "work", it's like pulling teeth to get an electrical engineer to change anything.

Some of it has good reason. It's really difficult to prototype new circuits. We can prototype new code as fast as we can write it. Have you ever tried using Eagle? Or LabView? Constantly fighting with a goofy UI to build circuit designs, and then you really only have a simulation at that point. To get the real thing (analogous to compiling?), you have to fab a prototype, which fewer and fewer places are doing in-house anymore, which will take a day, or maybe a week. I compile my software 15 times an hour!

And it doesn't necessarily have to be this way. LabView sucks because EEs are shitty programmers. Every hardware shop I've walked into, I was the guy to suggest they start using such outlandishly cutting edge technology as source control. It's been even harder to convince some of the older engineers that no, nobody uses CVS anymore, and the little you remember of it from 15 years ago isn't going to help you anyway.

"Oh yeah, let's write our own atoi(). That sounds like a great idea. What's that? You didn't realize that I'd be sending you a direct copy of what was on the LCD screen? Why wouldn't you want to know that the LCD shows a space in the 10s column between the negative sign and the value when the value is more than -10?"

So yeah. Everyone is a bunch of cheap bastards. I'm not saying it's any better on the software side. Software engineers couldn't be counted on to put a florescent light tube in the right way if their life depended on it. But at least most software engineers try to abdicate hardware responsibility to other people. EEs think "it's just code, anyone can do it."

Re: Keyboard Ghosting Explained

#76

Post by mavroprovato » Fri, Mar 07, 2014, 4:59 PM UTC

orochi235 wrote: post #64

It looks like they ripped all those diagrams off from a three-year old Tom's Hardware article: http://www.microsoft.com/appliedsciences/antighostingexplain... http://www.tomshardware.com/reviews/mechanical-switch-keyboa...

> (Graphics: Microsoft)

Last words on the article

Re: Keyboard Ghosting Explained

#77

Post by moron4hire » Fri, Mar 07, 2014, 5:05 PM UTC

comex wrote: post #11

> The internal electronics on the SideWinder X4 use a variant of resistive multitouch technology. Each key has a screen printed resistor in series with its switch. This allows the internal electronics to read the state of each key switch independently for very large multiple-key combinations. This is pretty vague. How exactly does this disambiguate which keys are being pressed?

This is exactly (minus the "screen printed" part) how I built this bugger: http://www.youtube.com/watch?v=oIFA7msO_x0

The key electrical concept is a voltage divider: http://en.wikipedia.org/wiki/Voltage_divider

Each row of three buttons is in parallel with each other, each with a different value of resister. When a switch closes, it allows current to flow through that switch's resistor. The final voltage at the end of the row of buttons is directly related to which buttons are pressed. Given the right selection of resistors, you can tell exactly what combination of button presses have occurred.

A diagram I had drawn to explain it to a project mate: https://raw.github.com/capnmidnight/GeblinkenKiosk/master/do...

And the (can't remember if it's accurate, but certainly close enough to get the concept) diagram of the full circuit: https://raw.github.com/capnmidnight/GeblinkenKiosk/master/do...

The spreadsheet I wrote to figure out the voltage thresholds for given resister values: https://github.com/capnmidnight/GeblinkenKiosk/blob/master/s...

And the code that read the analog pins on the Arduino to figure out the state: https://github.com/capnmidnight/GeblinkenKiosk/blob/master/s...

Re: Keyboard Ghosting Explained

#78

Post by Anderkent » Fri, Mar 07, 2014, 5:10 PM UTC

comex wrote: post #39

(Unrelated to my other post here...) Aside from gaming, one application that's hurt by rollover is the open source stenotype program Plover: http://plover.stenoknight.com I would like to try it, but I tote around a MacBook Pro and I don't care enough about Plover to try to carry a keyboard around and awkwardly put it on top of the built-in keyboard or something. Still, this is one of the few cases where I feel constr…

You can make a keyboard pretty small nowadays: http://technomancy.us/173

Re: Keyboard Ghosting Explained

#79

Post by keeshawn » Fri, Mar 07, 2014, 6:10 PM UTC

kabdib wrote: post #10

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.

Microsoft used to make some really good keyboards. But about 8 years ago they started making junk. The last MS keyboard I could actually type on was the Wireless Multimedia one (now discontinued). Keyboards in the last few years have had: - Mushy key feel. I can't tell when I've actually done a keystroke. - Keys that are hard to strike (need to press on them just right, or they hang up or don't register). This is par…

Why make good stuff when you can over-engineer and over-sell garbage?

Re: Keyboard Ghosting Explained

#80

Post by T-hawk » Fri, Mar 07, 2014, 6:11 PM UTC

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…

Just wondering, was that SF2 clone Super Fighter, with Pho Huang among the characters?

I did the same thing about figuring out which keys would block my opponent from moving, both in Super Fighter and in the PC ports of the Mortal Kombat games. Didn't go as far as automatically calculating it per keyboard, though. We actually tried to play honestly without using that for advantage, a gentleman's agreement to only press keys for just as long as you needed.