It looks like the interface is just USB and power, so I’m guessing it should be possible?
ZMK is still highly experimental on RP2040; QMK’s ecosystem officially supports it. I imagine that’s why they decided to use QMK for the Gamework input modules.
At the end of the day they’re all just HID keyboards and the firmware just uses USB, correct? It shouldn’t matter what firmware is sending signals if it’s just a USB keyboard. You could design any USB device to connect to that pinout (more like a modified USB OTG, not technically standard since it has a sleep pin, but that’s trivial to accommodate if you’re making a custom device already), including one with 32-bit or 64-bit processor so ZMK can run on it. I have some wild ideas already about what control surfaces I can create when high refresh rate touch panels that are thin enough to make into an input module become commercially available, or even how I can piggyback off of the ecosystem and standard to make a bluetooth USB hub for these modules that sits on your lap.
@Be_Far if you manage to create touch panels I’d buy one! We’re going to need a community marketplace.
Just created a thread for crowdsourcing this project. We can’t do much without actual Gameworks to test on, but I want to put my pipe dream out there in case anyone else has the same idea or the knowledge/skills to do more than I can alone.
You should be able to create ZMK-based firmware using our QMK-based firmware as a reference. As noted, QMK has more robust RP2040 support currently.
Awesome, glad to hear it. Thanks for the confirmation!
Power management seems to be a weakness of the QMK firmware, which may be one reason to consider using ZMK. In the firmware for the Framework 16 keyboard I see a
suspend_power_down_kb() call and some code which does a
readPin(SLEEP_GPIO) but nothing which explicitly idles the RP2040 or reduces its scanning rate – although I could easily be missing something.