I’ve been reading through the Pocket Reform documentation and source, especially the kbdgfx-demo, and it’s gotten me seriously interested in the standalone keyboard as a programmable UI device, not just as a keyboard.
My eventual goal is to have a desktop application communicate with the keyboard over USB and drive both the OLED and the RGB backlighting. For the OLED, streaming bitmaps (similar to kbdgfx-demo) seems perfectly reasonable. For the RGB, though, I think I’d rather keep the animations on the RP2040 itself and just send high-level state changes from the host.
For example, instead of continuously streaming LED frames, the host might simply send something like “enter mode X”, “show warning state”, “trigger this animation”, etc., and the firmware would handle the actual lighting effects locally until told otherwise.
That feels like it would make better use of the RP2040 and keep the host protocol much simpler.
My question is: does that fit with how the firmware is currently structured?
Is the existing OLED graphics path (xWBIT/raw HID) the natural place to extend for additional host-to-keyboard commands, or would you recommend creating a separate vendor HID interface for this sort of communication? In other words, if you were implementing this from scratch today, where would you hook into the existing architecture?
I’m still deciding whether to purchase the standalone keyboard, so I’m mostly trying to understand the intended extension points before I dive into the code.
One of the things that attracted me to the Pocket Reform is that it seems to expose enough of the firmware and hardware that projects like this are actually encouraged rather than treated as hacks.