I have been going back and forth for a very long time on how to get the CE certification done, and decided to join https://early.smander.com/getsmandered-round-0/ to finally get this step done. My hesitation comes from the scary price tags I heard from the CE test labs I contacted. I hope with Smander, I can achieve that without much overhead lending the experience in this process, which I don't have yet. It also feels good to follow a guideline :)  Apart from my worries around certification, I have some updates to share:

Increased HID throughput!
In the past, I always felt some slight delay when a new overlay gets streamed to the PolyKybd. This is the known limitation, that HID (in FullSpeed USB2.0) can only transfer one report per msec - so it is deterministic, but also very slow. As I might have mentioned, the host program, therefore, already reduces the data that needs to be transferred to the very minimum. When reading the pixmaps for the program shortcuts, the host program prepares the binary representation of all 4 methods and then chooses the one resulting in the smallest number of bytes:

- Plain bytes (so 8 pixels per byte, as these are monochrome pixmaps), which is really only the best option if there is a repeating bit pattern over the whole display. So this is very rare, but the first thing I started with, and it is still supported.

- RLE compressed. So basically counting how many set and cleard pixel are followed by each other. This is almost always better as the plain bytes (except for the mentioned on/off patterns)

- Region of Interest. So, only sending the rectangle that needs to be updated. And this method comes in two flavors: RLE compressed and uncompressed.

While sending only the region of interest (ROI) updates, the number of bytes is greatly reduced. However, a program with shortcuts on a lot of keys can still result in more than 100 HID messages that need to be sent to the PolyKybd. Next to the limitation of one HID report per msec, I also have to decompress the data (and stitch in the ROIs) on the PolyKybd, which also takes some time. For a while, I have been looking for alternatives to get some high speed communication going with QMK, but it looks like this is rather involved, and I haven't found any project doing that. It looks like it would need some rewrite of QMK's USB stack. Still, I managed to do the following:

Activate the second core of the RP2040!

Right, there are two cores on an RP204,0 and QMK only uses one. When starting my research on that, I could not find any reference of a QMK project doing that, so I started my own implementation with the help of the Pico-SDK. It was a rather painful process that also needed some inline assembler... Just after finishing this tricky task, I found out that there is a module called dual-rp, which lets you run some QMK callbacks on the other core. Nevertheless, I'm really happy with my own implementation as I can control exactly the stack usage of the second code (which I keep as low as 128 bytes, as I cannot waste too much RAM for that) and decide precisely what is executed. In my case, the RLE decompression! With that, I can now offload the buffer I got from HID to the second core (core1) and do not block execution, resulting in faster updates when receiving overlay data. I wish I could show you some screenshots, because I'm rather excited about this improvement. Just believe: It's great!

Increase HID report size

QMK uses 32 bytes HID reports and it is possible to increase that to 64 bytes while still staying USB 2.0 compliant. Increasing, however, meant to break VIA compatibility and also needed a QMK modification in the TMK core, which was unnecessary until now. All other code lives in the keyboard's "user space".

The hesitation to give up VIA was quite significant, not because it is particularly great, but because it is convenient to update keymaps. So I, in fact, did a little GUI prototype before really deciding to give up VIA. In the end dared to do so. Also, QMK separated from VIA a while ago, so this will make updates easier, which is a nice addition on top. With switching to 64 bytes, the HID throughput got doubled, further reducing shortcut update time.

Extending the host program for dynamic keymaps

This is my in-progress keyboard layout editor that is now needed, and I would say it will be in a working state rather soon. I'm very pleased that this worked out smoothly, and I can soon update my layout without VIA. Great!

PolyCorne Split42

Apart from that, I had some time around Christmas to tinker around and made a Corne Split42 variant of the PolyKybd, which still needs to be tested (I need more time). However, I will give you a small sneak-peak here:

Best, Thomas