All About Laptop Keyboard Reuse

Reverse-engineering laptop keyboards: theory, hardware, and sharing data

Similar projects worth following
Starting from
CRImier has 503 orders / 42reviews
Ships from Netherlands, Latvia
Laptop keyboards are cheap and abundant, but quite inaccessible when it comes to reuse. I believe that anyone with a spare laptop keyboard should be able to make use of it.

I aim to develop a variety of tools, from simple to complex, aiming to make laptop keyboard reuse straightforward and quick. The KeyboardWhiz is the main tool I've made for this, and with its help, we can get even cheaper and simpler tools.

Technically, you just need a bunch of GPIOs and a simple firmware that scans through them, and you can easily reuse any laptop keyboard. From there, you get a table that shows which pin on the keyboard FPC maps to which keys.

I'd like us to be able to share these tables. For that, I'll make a resource hosting these tables, and a very easy way to submit your own entries.

Once we have a large enough keyboard database, we should be able to find similarities, and develop some cheap universal adapters - so that anyone can order a PCB that'd make their k

A few years ago, I spent about 8 hours iterating on reverse-engineering a EEE PC 701 keyboard - trying to bruteforce row and column locations in an online keyboard firmware generator, recompiling and flashing firmware over and over again. 126 painful iterations later, I have mapped every key of an EEE PC 701 keyboard, except for one.

This was obviously not the proper way to do things. For the next keyboard I wanted to reuse, I found two I2C GPIO expanders, hooked them up to a ZeroPhone, and wrote some code to reverse-engineer it in a convenient way. It took only about 2-3 hours, and in the end, I had a tool to tame any keyboard I could find around - which would only take minutes.

Somehow, we aren't doing this more, even though it's way easier than I've expected. There's an instructables project that's done a great deal of the same work I've done, and a lot of people have reused their keyboards with help of that project. I believe that things should be done differently, however - in a more open way.

Why reverse-engineer laptop keyboards?

Laptop keyboards are cheap, well-built for the price, and available in large quantities - and, any hacker has a few spare keyboards laying around. Using a laptop keyboard in your project lets you do a whole bunch of input. You can give any of your projects an easy way to input text, execute a variety of commands. You can get from 80 to 100 keys and only use a few GPIOs on your microcontroller.

KeyboardWhiz hardware aims to let you reverse-engineer any laptop keyboard in 5 minutes' time. You get pinout information, a keyboard, nicely formatted in a PDF datasheet. It also lets you upload this data online, so that everyone else can benefit from it.

What's possible with this project?

For a start, if your microcontroller project has I2C available, you can copy the KeyboardWhiz v1 schematic - which is to say, get two 16-bit I2C expanders and an FPC connector, and reuse any spare laptop keyboard you might have around. So, ideally, reusing any laptop keyboard starts at $5 per keyboard.

Once we have a sizeable database of keyboards, we can go even cheaper. If we figure out similarities between pinouts for an assortment of keyboards, we can create universal boards for FPC keyboards. Since a predetermined group of 8 pins has to be outputs and another group of 16-18 has to be inputs, you should be able to use one 74HC595 and two-three 74HC165 chips. Then, you can get adapters that use cheap shift registers instead of I2C - at most, $1 in ICs and connectors instead of $5 if you want to add support for an already-decoded keyboard to your hardware.

This project's efforts also lets you design larger-scale projects around widely available laptop keyboards - as there's families of cheaply available keyboards that are intercompatible. For instance, you can find myriads of Asus K53 keyboard for 7EUR on Aliexpress, and this project has data for these keyboards already. So, if you'd like to produce ten or even a hundred devices equipped with a decent low-footprint keyboard, you can buy a bunch of Asus K53 keyboards off Aliexpress, get the pinout and key table from this project's efforts and reuse these, again, at most, only spending $1 in extra parts.

If there's a family of cheap keyboards that nobody took a KeyboardWhiz to, you can do that yourself, and it only takes 5 minutes.

What's already available?

The reverse-engineering part of it is already possible with KeyboardWhiz code, and you can already generate a PDF with a pinout table. The RE code is robust and flexible, as well as user-friendly. The "creating key events in Linux from this data" part isn't yet written, but will be straightforward given the reverse-engineered data. As for adding KeyboardWhiz to your own hardware, I2C expanders are currently expensive due to chip shortage, so putting a few of these your own board might be non-ideal at the moment. Yet, I'm sure we'll soon get through these tough times.

  • KeyboardWhiz hardware background

    Arya06/11/2022 at 22:00 0 comments

    Laptop keyboard FPCs can have up to 32 pins - and "keyboard+other things" connectors, on like Thinkpad or Framework keyboard modules, can even have up to 50 pins. It's hard to find a cheap USB-capable microcontroller with so many pins.

    A typical keyboard uses 24 pins for the actual keys and 3-4 pins for the LEDs. The keyboard FPCs often have 30-32 pins, however - a portion of them NC. This doesn't work.

    An Arduino Pro Micro has 18 GPIOs, which is nowhere near enough. Microcontrollers like Teensy tend to be of more help - Teensy 2.0 has 26 GPIOs available, which even allows for two LEDs. Bigger Teensies have more pins, but they're way too expensive for this project's goals. A Pi Pico has 26 GPIOs available too, and is cheaper. Plus, the RP2040 chip itself has 30, so it should be possible to add more features if you make a custom board with the RP2040.

    However, in order for 24 pins to be sufficient, you still need to know which pins are used and which aren't - if you don't know that, you still need 32 pins; and for an universal keyboard RE adapter, the assumption is that you don't know which pins are which.

    Because of this 32 GPIO requirement, I use GPIO expanders in the KeyboardWhiz. Two 16-bit or four 8-bit GPIO expanders can provide 32 IO pins - leaving the microcontroller with quite a few extra GPIOs. For instance, you can control many extra keys, PWM the backlight control circuit, or even interface to a touchpad over I2C. I use I2C expanders, but it's possible to use SPI expanders, too.

    The original KeyboardWhiz only had I2C expanders and connectors on it - so you'd have to connect it to a Raspberry Pi or a HDMI-I2C breakout of some sort, and run Python code communicating with these expanders. As such, it couldn't work as a USB keyboard controller, either. The next KeyboardWhiz version will have a RP2040 in addition to expanders, so you can take control of way more features.

  • Theory

    Arya06/07/2022 at 04:07 0 comments

    A laptop keyboard is a diode-less key matrix. Its keys are distributed in a way that you can press the most important key combinations at once, despite the lack of diodes - to the point where some rows only contain one or two keys.

    Often, there's also LEDs for functions like WiFi status, CapsLock and NumLock inside the keyboard, connected to the same FPC connectors. If there's backlight inside the keyboard, it's typically connected separately, however. Sometimes, there's a power button on the keyboard - then, it's also available on the same FPC.

    Laptop keyboards typically use 0.8mm pitch FPC connectors, and 1mm connectors were typically used in older laptops. For small and modern laptops, it's not unheard of to use 0.5mm connectors. At times, keyboards use proprietary connectors, sometimes exposing all the signals through them (i.e. Framework or Thinkpad) and sometimes using a separate keyboard controller chip on a sub-board, which uses some kind of low-pin-count interface to talk to the EC (i.e. Dell Latitude E7470).

    Typically, there's 8 rows and 16 columns in a keyboard matrix - this helps the EC scan the keyboard, since 8 and 16 are multiples of 8, and it's a bit easier to write code that operates with these. Numpad-equipped laptop keyboards tend to have 18 columns. There's no real difference between "rows" and "columns" - it's just a matrix of keys, either of the two sides can be called by either term, theoretically. For consistency, I use "columns" for the side which uses more GPIOs (so, typically the 16-pin side), since that somewhat represents how keyboards actually look physically - they have few rows and many columns.

    As implied in the first paragraph, the key arrangement in the matrix doesn't represent the physical arrangement of the keys on the keyboard. In fact, it's quite a bit different. For a laptop keyboard, you need to be able to press certain keys simultaneously, i.e. Shift/Ctrl/Alt+KEY combos, and Ctrl+Alt+Delete. Laptop keyboards don't use diodes, however - they compensate by dedicating entire columns to certain keys. This explains why a typical keyboard can technically have 128 or 144 spots for keys (8x16 or 8x18), but has way less keys available, typically, from 80 to 100.

    [TODO: image]

    While scanning the matrix, some GPIOs have to be set as outputs, and some have to be set as inputs. It's quicker to scan through 8 pins than it is to scan through 16 pins. So, "row" pins are typically referred to as KSI (Keyboard Scanning Input, 8 pins that are set as outputs on the EC), and "column" pins are typically referred to as KSO (Keyboard Scanning Output, 16-18 pins set as inputs on the EC). Again, some keyboards might use a different terminology, I haven't checked that - I chose this convention because it makes sense physically.

View all 2 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates