[rheide]

Aren't those things only a problem because keyboards are being mass-produced? Companies are cutting costs by using less components which introduce these kind of problems. If you're building your own custom keyboard you're not going to care if it costs you a bit more, especially if it means you can avoid these problems from the start.

[skorgu]

Yeah I know just enough about hardware to be dangerous but I think you can stick 6 16-bit GPIO expanders off of an I2C or SPI bus and address every switch individually. Makes no sense for mass production but for diy it's $10 in parts or something

http://octopart.com/mcp23s17-e%2Fso-microchip-470569

[meaty]

Scan rate is shit though if you have to use spi/i2c.

[ChuckMcM]

This is incorrect. While typically Linux has implemented the spidev poorly (its really just a stub to do the things you do occasionally like sideload firmware into a card) SPI itself it actually reasonably zippy for this application.

Typical "fast" SPI clock rates are 10Mhz on a 20Mhz MCU[1], and with a daisy chained set of SPI parallel I/O chips (they appear as 'one' device on the SPI bus) you can clock the state of all 105 key switches (or 120 if you're using 5 of the 24 bit ones) into an embedded processor like the AtMega328 at 10mS per sample. So that is 100 samples per second. Usable for this stuff but not ideal.

Since the n-key rollover patent [2] expired a number of companies have made chips that implement this for arbitrary sized matrices (given i/o pins) of which an exemplar is Atmel's AT43USB325E [3] which can handle up to 20 x 8 (that is 160 keys). The Atmel part is especially useful because it has a built in USB 'peripheral' port and the app notes for this part show how to easily make a USB keyboard out of a bunch of random key switches hooked to a diode matrix.

[1] http://www.atmel.com/Images/doc2585.pdf

[2] http://www.google.com/patents/US4517553

[3] http://datasheet.octopart.com/AT43USB325E-AC-Atmel-datasheet...

[skorgu]

Even for a keyboard? Huh, good to know.