Modern PC keyboards under $150 are all junk, nowadays.  Economies of scale & demand has pushed all the good stuff to phones. 

It was a high risk to make a board just for 1 rare 15 year old laptop keyboard of questionable quality, from an e-machine. 

Acer MP-09B23U4-6983 PK130C93A00

All lions remember was it was a very good feeling keyboard with a buckling spring feel.

Recycled a 13 year old stm32 because it had enough pins, USB, & it was free.  Nowadays, there would be no reason to use anything but an RP2040.  It's always fun to see what these old chips were running in their original robots.  Sadly, the flat flex cables are not standardized & the flat flex connectors aren't reusable. 

It's amazing to see what lions programmed long ago & forgot.  Developing the flash filesystem in this one was forgotten.  The bootloader lions wrote 13 years ago still worked.

------------------------------------------------------------------------------------------------------------------------------------------------

The 26 pins connect to rows & columns.  The game is to set 1 pin to 0 while pulling the other 25 high.  Then press keys while observing the voltages on the 25 high pins to try to discover the pinout.  For this keyboard, it actually has some pins enable sectors of keys & other pins detect keys in the sectors.

You have to make a table converting pin voltages to event codes.  This requires sniffing a real keyboard using wireshark to get the codes that go in the USB packets.  It needs to sniff the usbmon corresponding to the bus number & the filter needs to contain the device number.  For lions, the bus is 5 & the device is 5 so the device is usbmon5 & the filter is usb.device_address==005.

Then come the USB descriptors, which are probably the same as https://github.com/heroineworshiper/cp33/blob/master/elan.X/main.c with some changed bits.  It also requires copying bits from an arduino keyboard library https://github.com/arduino-libraries/Keyboard

There were some more bits in

https://github.com/julianschuler/USBKeyboard/blob/master/usbdrv.c

This was the most difficult USB class lions ever worked on. The CDC ACM & mouse classes were a lot more forgiving but the keyboard class for some reason is just incredibly obtuse.  A byte for byte comparison on wireshark between the custom keyboard & a store bought keyboard was the only way.  The HID report descriptor just had to be copied.  None of the internet examples worked.

It became clear that it would be far easier & more modern to connect to it over bluetooth. The USB keyboard class was invented over 25 years ago.  The only advantages with USB were cost savings, less parts, simpler configuration, more practical in a self contained, custom laptop.  Most of the custom laptop concepts called for a wireless keyboard though.  The CPU would stay in a backpack while only the interfaces would be in the lap.

At minimum, everyone now uses an arduino library to do it, rather than the elementary CMSIS library from 2011 lions have been using.  Support for the STM32 grew from the CMSIS library to a HAL layer & then the arduino library in the last 15 years but each layer is slower.  Some early lion programs were maxing out the system calls to stream video & bit bang I2S so the CMSIS library became the baseline.

-------------------------------------------------------------------------------------------------------------------------------------------

Then B13, D8 started erroring low when USB was on.  The 2 pins neighboring USB were problematic even though they weren't set to AF.  The only thing that worked was rerouting them to farther pins.

Finally came the usual grounding jumper to escape the bootloader.

In brief amounts of typing, it was still dropping a lot of keypresses like the others.  The prime suspect is a case where multiple keys are pressed simultaneously & it has to freeze the current key state to avoid sending garbage.  Either because of this or something else, it doesn't feel as good as lions remember in its laptop days. 

There's no capslock or numlock LED.  It's a minor inconvenience.  It needs to handle some 1 byte control URBs to update those LEDs.  Fortunately, there are still some debug pads.

The big problem is it needs a support to avoid wiggling the cable.