PolyKybd (Displays In Your Keycaps)

As promised in my last post, I transferred the (for now) finalized PCB design from the right to the left side and already ordered 5 assembled boards that are in production right now!

The same thing was needed in the past when transferring the initial PCB design from the left to the right. This time, it turned out less painful (TBH I would like to automate a lot of things, maybe with skidl and pcbflow as mentioned in that article: https://kbd.news/Keyboard-as-Python-code-1834.html).

At the same time, I was iterating on the 3D resin prints. Here is the case, which was an almost 100% fit. I did print it first on my FDM printer before, but the tolerances are just a bit different:

The gap between plate and case is a bit larger than I wanted it to be. The fix was easy and the new version should be spot-on!

On the picture above, the print looks a bit scratchy from the post processing, but it is not so pronounced under normal light conditions. In fact, I was surprised how great all the parts turned out.

Only on my second batch, I had a few parts with some excess material here and there, that in my opinion, comes from a faulty resin printer LCD/mask:

You can see a little blob on the middle element. I hope that was just a one-off issue.

The cirque trackpad mounts do fit. However, I have to raise them a bit higher from the plate, otherwise the finger drops too much down when reaching for the trackpad. Also, the keycap stems need some more tuning:

While I can just push the FDM print onto the MX-cross of the switch, the resin print is not so flexible and then sometimes cracks. Making the cross cutout at the bottom just a little bit bigger should fix that.

While waiting for the assembled PCB, I'm working on the software side and it is about time to do that :)

If you have been following my blog posts, you know that a little mistake with my last PCB prevented me from using it as a keyboard: Pin 1 of all OLED displays was on the wrong side.

So I had to route half of the PCB again... Of course I took the chance to rectify some things I was not 100% happy with in the first iteration.

Right Side V2 Changes:

- The RP2020 and flash memory moved about 10mm away from the switching regulators as the space in between was very tight.

- The reset and boot button, as well as the debug port moved to another location as it turned out inconvenient.

- The host USB-C port got an ESD protection chip and I added a resettable 300mA polyfuse to the board to give it perfect protection in case of shorts or similar.

- The non-inverting buffers I used were actually for 5V and not 3V3 so I decided to change them with similar ones, now matching the supplied voltage (even though they worked without any issue).

- I set the current limit for the the displays and LEDs to 250mA as all displays together could potentially draw much more current (all pixel on + max brightness), not even considering all LEDs set to fullbright. Why 250mA? The USB 2.0 specification has a limit of 5V at 500mA (2.5 Watts). With both sides connected (2x250mA) and a display voltage supply of  3.7V I could reach 1.85Watts. That leaves enough room for 2 MCUs, 2 status displays, some other components and losses (also the switching regulators are not perfect). If it turns out to be too strict, I can set it to a higher value by swapping a few resistors.

- With esthetics in mind I changed the package of some components, but the IC type stayed :)

Ready? Set. Go!

I felt very confident and therefore, ordered 5 fully assembled boards with ENIG finish!

And... surprise, surprise: The boards look amazing:

Flashing the RP2040 worked and after connecting all displays without any key switches, I could see that I didn't mess up revision 2 ;) Everything is working!! No bodge wires, no software fixes to work around hardware issues!

Professional 3D Print

Almost at the same time, the SLA 3D prints, I ordered arrived and the quality is amazing! Compared to the 3D prints coming out of my FDM printer the tolerances are a bit tighter, so I had to do a bit of tuning here and there before I could put everything together. However, it worked out and I couldn't be happier:

All 3d prints (case, 1U+1.25U stems, display holder and cirque holder) are designed in OpenSCAD, so fine-tuning for the next batch will be very easy. The resin parts give it a professional look and my personal impression is that it feels more like a real product :)  

TA-DA!

Okay, so now with displays and lights on:

I didn't fix the displays indices yet and with that they don't show the correct content. However, I was so happy that it all worked out and just took a quick picture. There is some homework left for me!

Now it is time to bring the same changes to the left side and the hardware of the PolyKybd Split72 is ready!!

Sidenote

You might have noticed that it is really tricky to make good photos when the displays are on because those are much brighter than the environment. At some point I should maybe do some more professional HDR shots!

(until that time, I will just tweak light and contrast of my cell phone pictures)

Thanks for reading and let me know what you think about it in the comments!

The very first case for the left side was done manually. Just like I did for my macro pad prototype - measure everything and then model a fitting case:

Well, still I had to break away some parts as you can see :-P, this process usually needs multiple iterations to really fit well.

For left side case, I had at least some automatic step, so I haven't had to measure everything: In KiCad, I exported an SVG from the PCB outline and started modelling a case around that:

That worked, but I don't want to repeat that for the right side as it is just too much manual work. Also any changes to the position of the LEDs, USB connector or the mounting holes would be a disaster! 

The good part is, that I now know how the case should look like from the design standpoint!

What I also learned, is that there would be less manual modelling needed, if I placed all bottom SMD parts well within the PCB (well at least 2mm+). Then I don't need to modify the edge where the PCB sits on because of colliding parts. Obvious? Right? Seems like I had to experience that first to realize.

Next Iteration

So for the right side I wanted to start with a more generic and automated approach that ideally creates a fitting case based on the PCB alone.

To make the project as open as possible, I resisted to use any modelling software that would need a paid license. With these two ideas in mind I was wondering if I could use OpenSCAD to programmatically generate the case.

I already used OpenSCAD for the keycap stems and the display holder, why not for the case as well?

So How does it work now?

I still export the outline as SVG, however without all the cut-outs for key switches. In KiCad, you can select which layer to export and each layer can be a different SVG. So the most convenient thing is, to copy the board outline to a separate layer (since the key switch cutouts are also on that layer, but we don't need them). Then create a layer for each of the other physical features like:

1. Usb port cut-out (just a rectangle that can be extruded and subtracted)

2. LED cut-out for the status lights (just a line starting from the middle of the part perpendicular to the board outline)

3. Reset and Boot-Select switch cut-outs (again just rectangles)

4. And finally the stand-offs, which I just redraw as circles in a new layer as circles with the exact diameter of the drill hole.

So all together that makes 5 different SVGs (well, I also optionally had cut-outs for debug ports but that will not matter in the end).

All Set?

Unfortunately, my outline was not perfect (tiny gaps) and I had to fix it with InkScape to make one polygon out of it (I don't remember the exact steps, maybe there is some expert who can comment? Maybe there is a command line tool to do that?).

Apart from that, for some reason, all lines in my exported SVGs where in groups and I just got all lines out of any groups and deleted the empty groups as OpenSCAD had issues with objects in groups.

After these little cosmetic operations, I can load the generated SVGs into OpenSCAD:

With the offset command I can make the extra space around the PCB for the case. All that missing is a linear_extrude and we already three dimensional representation:

If the outline or another physical property ever changes, I just regenerate the SVGs and run OpenSCAD again. That's all! I love that!

You can find the current version as usual on my git repo: https://github.com/thpoll83/PolyKeyboard/blob/master/case/right_side.scad

And as usual my apologies for the mess in the repo, I really need to cleanup the structure. It's just like my desk ;)

Remaining Manual Work

There are a few things that might need manual adjustment once a while, but it's really manageable:

- The logo as I just placed it loosely in the middle

- The wedge shape in the front

- The mount points for tenting (on the side)

3D Printing

Of course I 3D printed the case and it turned out well:

I would like to show you with the new PCB, but the updated right version is currently in production and will take a few more days...

I had a good time designing the right side and it is really satisfying to see it turning on without any issues:

As you know from earlier posts, I used the right side to test a new hardware iteration that includes an on-board RP2040, USB-C, more flash memory, etc. So there was some risk that the board might not even boot up.

To give myself enough possibilities to tweak and debug things, I added a lot of solder jumpers and also pin headers to connect to the most important data via a logic analyzer:

Before I had to solder some wire to test points here and there just to check my SPI signals.

But the new board has a problem (makes me cry a bit), which makes it only usable as dev board and not as (Poly) keyboard. Disappointing, as all my PCBs on this project so far proved to be fully functional prototypes.

Here comes my list of what works and what doesn't.

Success:

- RP2040 with 8MB Flash and USB-C works (obviously)

- The non-inverting buffers do solve my issue with the data glitches I experienced, it was indeed a fan-out problem (😆 so happy that this is off the table)! Huge thanks to my co-worker Peter who suggested that change. This was my last electrical issue :)

As this problem was solved, it was time to increase my SPI frequency from 400kHz to 16MHz. That success made me go further so that I increased also the frequency for the shift registers to 16MHz and it works! It was a pure software change, but with the data glitches before, I didn't dare to tweak the way the shift registers operate. Finally, updating the displays is amazingly fast, no way to recognize any delay 🤯.
Now everything runs on 16MHz and I can see my 10$ logic analyzer reaching its limit. For hardware debugging I have to reduce the clock, otherwise it misses some signals (Well, I should maybe invested into a proper one... any affordable recommendations? Maybe a Kingst LA2016?).

- Successfully tested the new 0.42" displays with the SSD1315 chip! These were fully compatible with the old ones having the well known SSD1306 - no change needed.

- I also consider the solder jumpers as a big success. These let me re-wire pieces of the circuit without any new iteration (like the power supply of the displays, unfortunately these really need a voltage of about 3.6V, 3.3V is not working). In the future, I will remove them as they needed quite some space on the surface though.

- Right and left side can currently communicate via my RJ45-to-UsbC franken-connector and you cannot damage the boards by confusing the two USB-C plugs:

If you plug the side connector into any other USB-C device it will look like an analog headphone, which is harmless.

- A bit over-enthusiastic, I also decided to use an OLED status display which does not come on a break-out board to avoid any supply-chain issues with 3rd party PCBs. It's a bare OLED display with a 30 pin FPC (I2C) which I got from my trusted display supplier:

It did not turn on right away as I tied all reset lines together and the displays from the keycaps were initialized after the status OLED and so the reset triggered too late. To fix that, I now initialize them together and and we are good!

No Conclusion Yet:

- The pimoroni trackball (see picture above - fits just perfect), which can be used as alternative to the rotary encoder and is already soldered on for the current board, but I just did not configure it in QMK yet.

- There was also no time to check the cirque connector, but this will be still possible of course. It could make a nice addition or alternative to the trackball as mouse input.

Failure:

So here is the problem... Can you spot it? (new one above, old one below)

Well, it's easy if you see it right next to each other...! I changed to another FPC connector with 14 pins because the customized displays will have less pins to get rid of redundant ones (and therefore will be 1mm smaller and fit with more switches). There was even a KiCad footprint for the new socket, so I was very happy. And here is the problem... I did not compare it with the old footprint and there, pin 1 is on the right. The new one has it on the left!

Everything is electrically working, but the displays will face downward when putting them into the key cap 😭😭😭. And that means I have to make one more PCB to fix that!

What's Next?

Well, testing the trackball and getting a cirque to work and of course layout a new PCB, this time with pin 1 on the correct side!

So there will be just another iteration of the right side, hopefully already in a "final" state.

Actually, I planned to write much earlier about the language layer, but the draft never finished itself ;)

From the spreadsheet color scheme above, you can see that I support 10 languages at the moment. Of course at some point I would like to be able to download any language to the keyboard on demand maybe via the HID interface. Then, there would be no need to use a hard-coded lookup table. However, for this even more needs to be done on the software side and today I will focus on how it works at present.

Maybe the main reason why you are looking at the PolyKB is not language, but program context dependent keyboard functions? Don't worry, I think this is not too much different from the language layer. Let's call it the program or context layer, which would be just another lookup (table) to display a customized text or icon, if there is a function defined for that key. So if your focus is function and not language, please just take it as a template that can be also applied to the program context.

Easier Data Handling

Organizing the language lookup table (lang_lut) in source became an unmanable mess after 3 languages, so I started working with an xlsx spreadsheet, which indeed makes things much easier.

Let's look at the following example:

Each language has 3 columns. The first is what's usually displayed on the display, the second when pressing shift and the third, when caps lock is on in case it differs from the second (when pressing shift) case.

This is not uniform! For an english US layout the number keys turn back to numbers when caps lock is turned on (while the letter stay upper case of course), for a german keyboard the wild cards will stay active and behave just like the letters (and therefore there is no entry in the LUT).

Additionally there is a second row for each key to display what the key does together with ALT (GR):

While there is nothing for the US layout, you can see that there is an additional glyph for almost every number key in case of French or Spanish.

Translate the LUT to code

To get the xlsx file into C++ source code I use cog: https://nedbatchelder.com/code/cog/

That's a way to use Python code which is inlined in C++ comments and transform marked sections with that code.

Python is quite handy here because there are libs to do almost anything (including spreadsheet data access).

An example to get all defined languages (lang/lang_lut.h):

Everything between /*[[cog ... ]]]*/ and //[[[end]]] is generated. Just for the available languages, the effort doesn't pay off. It is an example. The python code that generates the LUT for the glyphs isn't much longer and it generates around 600 lines of code (in lang/lang_lut.c), which exactly why I use cog.

Apart from that it makes it very easy updating multiple code pieces at once. A new entry in the spreadsheet is enough and also dependent code will be updated:

That's very handy!

Cog needs to be executed to update the code sections and so I have a little script to run cog on all source files with Python code parts:

There is still much more work ahead to make this work in a more dynamic way, also for the program context, but let's do everything step by step!

After some back-and-forth where to assemble, I finally uploaded my Gerber files at my usual go-to-shop and now waiting for the whole thing to ship in the next weeks (hopefully).

Here is a KiCad rendering how the board currently looks like:

To make good use of the time until the PCBs arrive, I decided to test some more switches.

Compatible Key switches

I'm quite happy with the results: There are now 8 key switches that work as they are, without any modification. When getting the customized displays (with a longer and smaller flex cable), this number should grow to 28 key switches!

Additionally, I tested another 20 switches that work when cutting away the little bar in the middle:

I used my box cutter knife and gave it a little push on both sides and it's gone:

Here a picture of the happy family that can be used for the PolyKB at the moment (without any bigger effort):

And the list in more detail:

The 8 switches, that already work:

Kailh Novel Keys Cream Switch, 55g Linear

Kailh Purple Potato, 63.5g Tactile

 Kailh x Domikey Knight Saber, 42g Tactile

Gateron KS-9 (Pro) Red, 45g Linear Gateron KS-9 (Pro) Yellow, 50g Linear Gateron KS-9 (Pro) Green, 80g Clicky Gateron KS-9 (Pro) Blue, 60g Clicky Gateron KS-9 (Pro) Brown, 55g Tactile (they all look the same except the color)

In case you are confused with Gateron switches and their name (like me), better read this article: https://www.keebtalk.com/t/the-many-yellowses-of-gateron/17557

In short you might see KS-9 (Pro) switches with and without the plastic bar and might get the wrong version (=in case of the PolyKB that would be the version with bar), despite the product image showing no bar, because most resellers don't care about that little difference. Better directly ask the resellser about that (or just remove the bar, it's not a big deal).

The 20 switches that work when cutting the little piece of plastic away:

Gateron KS-9 (Pro 2.0) Red, 45g Linear

Gateron KS-9 (Pro 2.0) White, 35g Linear

Kailh BOX V2 Red Switch, 40g Linear

Kailh Box Cream, 45g Linear

Kailh Pro Purple, 50g Tactile Kailh Pro Burgundy, 50g Linear Kailh Pro Light Green, 50g Clicky Kailh Pro Plum, 70g Tactile

Kailh Speed Gold, 50g Clicky Kailh Speed Silver, 50g Linear Kailh Speed Bronze, 50g Clicky Kailh Speed Copper, 40g Tactile Kailh Speed Burnt Orange, 70g Linear/Tactile

Kailh Speed Pro Heavy Army Green, 70g Clicky Kailh Speed Pro Heavy Yellow, 70g Linear

Kailh Black, 60g Linear

Kailh RGB Red, 45g Linear Kailh RGB Black, 60g Linear Kailh RGB Blue, 50g Clicky Kailh RGB Brown, 50g Tactile

Also Kailh naming is not everywhere the same (including the Kailh website), so you might find these switches under slightly different names.

And the 20 switches I expect to work soon:

From left to right, starting with row 1:

Ashkeebs Alexandrite
Owlab Neon
Aflion Tropical
Waters GOJU Works x Tecsee
Safety Switch Blue Dusk Panda (by BSun)
Glorious Panda

Row 2:
Outemu Red
Outemu Brown
Outemu Purple
Outemu Teal
Outemu Black
Outemu Blue

Row 3:
Outemu Dustproof Red
Outemu Dustproof Brown
Outemu Dustproof Black
Outemu Dustproof Blue
LCET Sprout
LCET Joker

Row 4:
LCET Pink Queen
LCET Grace

That's it for today, I hope next time I can already give some feedback on the right side ;)

It took me some time to get started with the right side, since I had to make a couple of design decisions.

As a small spoiler, I posted a rendering on twitter (see below)

Maybe you already spotted a couple of things, but here is the complete list:

•  Kailh hotswap sockets instead of Mill Max sockets (since these are a pain to solder).
• Putting the RP2040 directly on the PCB instead of using the RP2040 Pico board to 1) allow a USB-C socket, 2) access even more IO pins and 3) use a bigger flash chip as I'm not sure that the Pico's 2MB is enough in the end (paranoid?).
• USB-C for the split-link, which I decided after running a poll on Twitter and Mastodon and USB-C was the clear winner on both platforms.
• A more generic footprint for the rotary encoder which allows the a standard Alps encoder, the rotary encoder from the left side EVQWGD001, the Pimoroni Trackball and there is a also a cirque connector (for I2C)
• A non-inverting buffer for each display row on the SPI clock and data line to hopefully overcome the problem (maybe a fan-out issue of the RP2040's IO pins) I described earlier where I saw some kind of noise when updating the displays.
• Status OLED display directly connected to a socket instead of a I2C break-out board from a random Chinese manufacturer.
• I also picked smaller FPC sockets for the displays - only 14 pins - since this is the goal for the kit. And 14 pins only need an FPC of about 7.5mm which will work for much more key switches than before (which was about 8.5mm).
• Plenty of solder jumpers, which allow a lot of different operation modes. For example: I got some newer 0.42" OLED displays for testing, which allow a voltage supply of 3.3V and therefore, I could bypass the 3.8V regulator which was required for the old OLED displays.

So a lot of new stuff and I really hope (fingers crossed) it is not too much at once and the board boots up!

That's it for today. Let me know what you think about these improvements, it's not too late to change some things before assembly!

And of course I which a joyful holiday season whatever you celebrate at your home!!

Finishing the second hardware prototype turned out to be more involved than expected! I had some troubles (with noise I think) on the signal lines, which went away when I removed the pull-up resistors which I had on the SPI pins (I shouldn't have used them in the first place, as it is not I2C but at some point these solved a problem with floating pins when I was using the STM407F MCU and they just stayed - well, until now).

Once a while, there is still a glitch, which I need to investigate. The strange thing is that also without refresh, I can see some pixel light up one a while. My best guess so far is that I unintentionally introduce some capacitance or resistance due to my soldered together flex-cables (the pitch is only 0.5mm so it is possible that two neighbor lines almost touch each other) and these cause some troubles. That problem would go away if I could get the customized displays with the longer flex cables... but I cannot prove it for now.

Needed Software Changes: Since I have two identical boards for my "test keyboard setup", I started using the eeprom to store which side is the actual left and right side(with `#define EE_HANDS` and make handwired/polykb/wave:default:left` `...right`), but that is not needed as the is a master detection with ChibiOS and it just sets the master to the side with the connected USB cable (just connect the able to the 'correct' side).

Additionally, I had to double the key matrix and num of RGB LEDs as if everything runs on one side (turns out that actually happens - the master just receives the keypress from the other side and runs the logic!). So in the end this is what I changed:

rules.mk:

SPLIT_KEYBOARD = yes

config.h:

#define RGBLED_NUM 72
#define DRIVER_LED_TOTAL RGBLED_NUM
#define RGB_MATRIX_SPLIT { 36, 36 }
#define SERIAL_USART_TX_PIN GP5
#define SPLIT_TRANSPORT_MIRROR
#define SPLIT_LAYER_STATE_ENABLE
#define SPLIT_LED_STATE_ENABLE
#define SPLIT_MODS_ENABLE
#define SPLIT_OLED_ENABLE
//and also define a new LAYOUT to have both sides in one:
#define SPLIT_LAYOUT

( ... My first few connection tests failed, however after changing a couple of things back and forth I got some basic input working, however, just for one the master (left side) and !some! key on the slave (right side):

Again, it took me some time to think about it, but after the realization that only the master really executes the logic it was clear that all my static helpers were never updates on the other side (and some initial mistakes when adding the second side to the layout).

The solution to this was to use the housekeeping task and check for changes (as we already configured QMK to sync status changes like modifiers and status LEDs) and then perform the needed updates. As I can do the same on the master the display update now moved from the matrix processing to the housekeeping as well, which should be an improvement for the scan rate!

To also get the language change propagated (which are no QMK layers), I had to add a rpc callback which is triggered by the master to send that information together with the display brightness:

The `user_sync_poly_data_handler` task is executed on the the `slave` side, which just sets the static variables and then asks for a refresh of the displays which will be done in the housekeeping task.

There are still open software issues I need to address at some point (RGB matrix lighting not working correctly at the moment, fade in and out after timeout has some side effects, code cleanup - yes it's messy at the moment, the OLED display update could be faster, ...) but for now you can find the work-in-progress code here: https://github.com/thpoll83/qmk_firmware/tree/PolyKeyboard

And here a small video I posted on Twitter: https://twitter.com/thpoll2/status/1591026041434226688?s=20&t=j8DVR1XFWFR__iBi13svhw

For most people the typing experience itself is the most important part of the keyboard which it is hard to quantify.

So it shouldn't be a surprise that my thoughts circle around that aspect as well when thinking about the PolyKeyboard.

What I cannot influence for now, is the keycap profile from the relegendable keycaps I use. It's maybe close to XDA, however the swale is not that profound, the corners are a bit more distinct and the overall height is only 8mm.

And what about the key-stroke?

How much does the flex cable influence the behavior of the key switches?

To figure that out, I made a little test station and measured how much weight is needed before and after adding the flex cable to the key cap:

The LED on the board will light up when the key switch conducts.

The keycap with the 3D printed stem and the display come with a weight of 2.2g:

My circular tray to hold the weights add another 7g.

First, I did a test without the flex cable, so let's quickly deduct its weight from about 0,5g:

When the LED finally lights up, the following weights rest on the key switch:

Stem with keycap (minus display for the first test): 1.7g

Tray to hold the weights: 7g

Weights: 20g + 20g +1g

That makes a total weight of 49.7g when the switch activates, which matches very good with manufacturer's data for the yellow Gateron switch of 50g for the operating force. So now, how much does that change with the plugged in flex cable? The same thing again, I'm adding weight until the red light turns on:

Stem with keycap and display: 2.2g

Tray to hold the weights: 7g

Weights: 50g + 2g + 1g

Here we have a total of 62.2g, which is 12.5g more. So this is definitely something to consider when choosing switches for the PolyKeyboard!

There is maybe a bit room to get that weight a little bit more down when customizing the flex cable length and maybe also the cable width, but I think the current value of 12.5g added on top of your key switches actuation force is a good orientation.

As you may know this is not the first keyboard with displays in the key caps and I'd like to use this post to draw some comparisons with my project. LC Board / E3 Keys

Maybe the great grandfather of all these keyboards is the LC Board, you can see the commercial version live here: https://www.youtube.com/watch?v=3U20m6KjVrc The first prototype was created in 1984 in Germany and got produced as commercial version from 1987 on by "Hohe Elektronik". It featured 34 programmable keys with monochrome LCD dot matrices:

(https://deskthority.net/download/file.php?id=7771)

(https://deskthority.net/download/file.php?id=7772)

According to https://deskthority.net/viewtopic.php?f=62&t=5726 it was invented by Reinhard Engstler who still owns a company that produces and sells keys with LCD displays (even RGB versions)!

However these switches are not the usual keyboard switches, but a custom version with a size of 24.5 mm by 23.5 mm and seem to be used in control panels for industrial / mixing applications:

(https://www.e3-keys.com/products.html)

You can find out more on https://www.e3-keys.com, they even have some more extensive history post there: https://www.e3-keys.com/news.html#news1

Art.Lebedev Optimus Maximus keyboard

Maybe the best known keyboard with displays:

The 'Optimus Maximus', still advertised on the manufacturer's website https://www.artlebedev.com/optimus/maximus/ However, it is out of stock since almost a decade and the initial price tag was around 1600 USD according to https://en.wikipedia.org/wiki/Optimus_Maximus_keyboard

Most critics you can find online are around the typing experience: People used to get tired after 30 min of typing as the keys are so stiff. Other people mentioned a high pitched sound coming from the keyboard or the separate power supply you needed to operate it. Independent of it's flaws I would say this one was very ambitious the most influential keyboard with displays.

There were variation like the 'Optimus Popularis' which used a single big screen under the keys and the key caps are just transparent to let you see through the underlying segment of the display, so the key caps are suspended on the side.

(https://www.artlebedev.com/optimus/popularis/)

According to this review, the typing experience is better than expected, however it still had a price tag of 1000 USD and the layout is maybe not a fit for everyone.

Additionally there was a 6 key macro pad called 'Mini Six' for around 400 USD. IMHO a bit too much for 6 keys!

Nemeio

One of the more recent attempts to create a keyboard with programmable displays, it uses the same approach like the 'Optimus Popularis' with a singe screen at the bottom and transparent key caps on top, but it uses e-Ink instead of a full RGB display: https://www.nemeio.com/

Funded via a campaign on kickstarter and indiegogo, this keyboard was initially planned to be released by the end of 2019. The current schedule says 'End of 2022'. As it is not yet release we have no review yet and I do wonder about the typing experience of those keys. Of course the fit of the layout is another open question.

Private Project by James Brown

This is a project very similar to the PolyKeyboard by fellow Twitterer James Brown who uses the same displays but with shorter flex cables that are soldered on a flex PCB which is then once again soldered to the main PCB of the keyboard. I was surprised how fast (compared to my project) James came up with working solutions.

The main difference to the PolyKeyboard is that the displays are controlled via I2C instead of SPI and the flex cable doesn't go through the RGB slit of the key switch but just through the PCB via a slot in front of the key switch:

https://twitter.com/ancient_james/status/1525645446923702273?s=20&t=AAAGqh2W81XA7f4Jm9mOxg

I have to admit that this design leaves much freedom of choice for the key switches. 

https://twitter.com/ancient_james/status/1538808294118424578?s=20&t=nmTf1NkwTr6LqAmxBh_jOQ

Also the resin cast keycaps look pretty nice.

Sonder Design

https://en.wikipedia.org/wiki/Sonder_Design

Another single screen e-ink keyboard that according to Wikipedia got bought by Foxconn and the disappeared. The Guardian also covered that keyboard including a YouTube video of the prototype where you can see the e-ink screen in the background refreshing:

E-inkey Dynamic Keyboard

Not sure if this project ever got beyond the design phase as there are only renderings and the indiegogo campaign which wasn't a success. However, it was the only e-ink keyboard that considered to have the displays in the key caps:

There are some more, but only in form stream decks:

Infinitton

Once again the famous technique to use a single RGB screen in the back, this time for a smaller format, founded via kickstarter: https://www.kickstarter.com/projects/2086416348/infinitton-a-smart-touch-screen-keyboard?ref=discovery&term=keyboard%20screen

Elgato Stream Deck XL

I'm not sure how it works under the hood but it also looks like a single RGB display with transparent keycaps. One of the few 'Display Keyboards' that are still produced: https://www.elgato.com/en/stream-deck-xl

Finally the PolyKeyboard! (now PolyKybd)

What can I say about the PolyKeyboard? Well, one day, hopefully, it will be a kit! Which can be assembled by anyone ;)

From the beginning, I stayed away from solutions that would not work for kits.

• For instance resin cast key caps:  These look beautiful, but I cannot even do casts for 10 keyboards. That would be too labor intense. Instead I'm using relegendable key caps which are commercially available in different sizes, the only customized part here is a 3D-printed stem which is doable with my printers (or with some on demand print farms).
• Also soldering the flex cable of the displays to the PCB would be a maintenance burden if a display ever stops working. Instead I'm using a socket to plug the flex cable in.
• No custom key switches! Use the key switches of your choice: At least to some degree, as the flex cable needs to fit though the RGB slit of the key switch. I published a compatibility chart in an earlier post and think we can maybe get even smaller flex cables so that there are more compatible switches out of the box.

It is open source / open hardware, already by today (okay, I know, I have to organize it a bit more) so your are welcome to join in! The firmware is made with QMK, which means that there is no limit to the customization possibilities. The current dev-kit, which I try to put together, is a split keyboard, but I'm also thinking about a 70%ish staggered layout. The only customized component I need, is the display with an extended flex cable, as the current length is not sufficient to plug it into the socket (and I don't want you to extend the flex cable yourself, it is possible and I do that for my prototypes, but it is very painful!!). I just need to reach the minimum order quantity so that my Chinese manufacturer is willing to customize the attached flex cable. For that I need some budget upfront... currently thinking about my possibilities.

I hope you enjoyed my short overview. Maybe you are aware of another project I didn't mention? Please let me know.

Edit: People informed me that there was also such a keyboard by Microsoft, the so called "Adaptive Keyboard" and there is still some information left on Microsoft's website: https://www.microsoft.com/applied-sciences/projects/displaycover

And also here: https://www.engadget.com/2010-08-12-microsoft-adaptive-keyboard-prototype-debuts-at-center-of-uist-s.html

It looks like there were multiple iterations, some with e-ink displays, others with RGB displays and a touchscreen above the F key row:

And now there is also the Flux Keyboard:

https://fluxkeyboard.com/