How feasible it is to change colors of the RGB Keyboard input module in real-time, multiple times per second? I want to animate the keyboard & macropad colors in sync to the image/colors on screen (like ambilight, but a single color at any given time).
I’m concerned about EEPROM memory durability, which has a limited amount of rewrite cycles. Is it save to send color & brightness change requests multiple times per second? Is the firmware going to throttle the writes (like, flush once per minute or something)? Is there an API to explicitly avoid writing / persistence?
It’s just a fun little project, I’m not ready to compile QMK firmware from scratch just for this.
I’m sending data about once per second on my custom QMK firmware, and I’ve not seen any issues as a result of that yet, having now had that firmware running for over a month.
Is your custom firmware writing persistent data to EEPROM memory?
By the way, your commit in git repo contains file mode changes for all files, which was definitely not supposed to happen, and which makes it near impossible to tell what is going on there:
Yikes, that’s a gross commit. Yeah, there’s only like 2 files I actually mess with so I’ll fix that when I get the chance. Must’ve missed something in the git ignore. Was just a small hobby thing so I just sent up a git commit -a without checking.
The only thing I write is variables/ram. I don’t know enough about the implementation of hardware to know if that’s an issue, but when I spoke with an electrical engineering colleague of mine I was left with the impression that if my code was going to destroy the memory, it would have already. I’m also not sure how they’d be doing animations without writing to ram regularly (e.g. an RGB breathing animation, or a pinwhell animation that needs to keep track of current/previous state).
I don’t write anything to persistent storage other than when I flash the firmware.
It’s not gitignore. It’s just that you’re probably on Windows where file system doesn’t know what file modes are, so git assumes everything is 755 rwxr-xr-x. Search for git config core.fileMode false and how to fix it.
Updating animation in RAM is not the issue. Only persistent memory is, such as selected mode, color, brightness.
If you just want every key to be the same color but updating with say the average color of the display, I think what you’re looking to do is even easier than what I did. Trickiest part (once getting the dev env setup) would be figuring out how to get the average color of the display.
Would it be helpful if I cleaned up the code and added a readme so you could use it as an example project?
I’m on linux, but I did have a bit of trouble getting the dev env setup, it’s likely an artifact of that. My advice: don’t use their docker image.
The colors in my case gonna be coming straight from a game mod where they are already known, that’s not the hard part.
I guess? It would be appreciated. Do I just need to look into this folder? https://github.com/StrikeNP/qmk_firmware-with-stats-rgb/tree/fw16-rgb-added-stats/keyboards/framework/ansi
I never built this firmware myself, so idea what I’m up to. But thanks for the advice!
I am so confused with Framework’s qml_firmware repo. Which one of the thousand branches am I supposed to compile to get an up-to-date Framework Laptop 16 RGB Keyboard firmware which does not wake up while lid is closed and is compatible with the latest BIOS update?
Haven’t looked at your code, but a way to check if it’s writing to persistent memory is just to unplug & replug your keyboard to see if it always startups with the same color, or if it’s some different color which got written to memory.
I don’t know how fast it can respond, but it sounds like you may want openRGB. A community member created a firmware which includes openRGB support. The thread should come up if your search “openRGB”.
QMK has options both to just keep lighting changes in RAM, and to write it to persistent memory / flash. I believe the default is to not use persistent memory. But you can check pretty easily by just unpluging & repluging your keyboard.
This is the branch that the latest releases were made from
This is a branch that has experimental support for the HID Lamp Array / Dynamic Lighting protocol that you can use to set the LEDs from the host. OpenRGB has a pull request to support that
I looked into qmk repository, found via.h / via.c with VIA API commands (protocol), and qmk_firmware/docs/feature_rgblight.md which describes C API where almost every setter function has a _noeeprom counterpart that’s explicitly “not written to EEPROM”.
Furthermore, in via.c I traced the dispatch chain:
raw_hid_receive
case id_custom_set_value:
case id_custom_get_value:
case id_custom_save: {
via_custom_value_command(data, length);
break;
}
via_qmk_rgb_matrix_command: differentiates between set, get and save command IDs
case id_custom_set_value:
via_qmk_rgb_matrix_set_value(value_id_and_data);
case id_custom_get_value:
via_qmk_rgb_matrix_get_value(value_id_and_data);
case id_custom_save:
via_qmk_rgb_matrix_save();
via_qmk_rgb_matrix_set_value: calls various *_noeeprom functions.
via_qmk_rgb_matrix_save: the one that actually persists the data via eeconfig_update_rgb_matrix.
So, it is save to say, simply setting brightness and RGB values over VIA protocol should not cause EEPROM to wear out as long as you don’t issue any id_custom_save commands (except id_qmk_backlight_effect value id: that one immediately calls eeconfig_update_backlight).
Using a Python script and hidapi library Framework Laptop 16 can achieve 220+ id_qmk_rgb_matrix_color changes per second with a single device, and 120+ fps with both keyboard and macropad. Keyboard and macropad remain responsive during such stress test. That is more than enough for any single color animation without needing custom firmware.
After days of digging through HID & QMK source code, and fighting with Python & .NET libraries, finally here is the result:
Integration my party music mod for Lethal Company, MuzikaGromche, with Framework Laptop 16 RGB Keyboard and macropad. It supports RGB LED flickering and changing colors in sync with in-game surrounding lights (which in turn are synced to the beat).
No custom firmware needed, and the performance is more that I could’ve asked for — at least for a single-color animation.
The VIA integration is not packaged on Thunderstore (yet). However the C# code is available in git for anyone curious:
