This is dumb but awesome. I forked framework’s inputmodule code and completely refactored the rust matrix module into a system service architecture with a new 'FWInputModuleD" service that multiplexes multiple shared space across all modules installed that are addressable by userland apps. It is a system daemon and speaks to apps over DBUS.
Then I forked OpenCode and added hooks to report how many tokens I have left in my context window on the LED matrix. Even activity monitors for when the AI agents are thinking or compacting the conversation. I wanted to do this as a Claude Code plugin, but the plugin API doesn’t expose the context window information, and I couldn’t hack it. I might vibe code some patches for Codex and Gemini CLI, though, since they are open source.
Oh, that’s a really neat project. I didn’t know that existed. But yeah, actually this could work more in reverse. There are two parts to what I built. A daemon to allow multiple front ends to share the real estate on the matrix and a front end hack for my AI context window. This system daemon I created could be a different backend for this. My system daemon lets you create addressable areas so multiple separate apps driving parts of the screen without owning the whole matrix. I even as pagination mode and dbus command to switch pages and I have hot keys to switch to between pages.
I’m interested in this part. Currently the monitoring app takes the matrix and divides it in 4 quadrants, the default is displaying any of x choices of system metrics to display, plugins would allow to display something else on one or any quadrant(s). That’s why I mentioned plugins, as it would allow to have that token metric to displayed.
Yeah! Totally. Right now, I’m using dbus because it made the most sense, especially for security in userland apps to communicate with a system app that has direct dev access, but I’m debating whether I want to create a loopback dev device of sorts so that existing code that already knows how to communicate can just switch to the dev device they write to. dbus has a little overhead for writing updates being a packet protocol with a bit of parsing overhead.