I have been working on 6 versions of the per key RGB keymaps but this is the only one that is sorta polished and have not found any conflicts so far. ANYONE please take a look and if you got any changes that would increase speed or use less data for same tasks it would be appreciated. I also have ones for the macropad that work for me but i need to polish those too before uploading. you can see my macropad in the images on the README file.
I worked out how to change the RGB’s brightness like how backlight step works for animation brightness. and also now you can have per key RGB or turn off the RGB brightness and the animation colors will be active and you can configure in the RGB layer.
I have written one version for the keyboard and also one for the macropad and deciding if i want to add color picking that allows you to change per key colors directly from the input device and not need to change the firmware files.
Oh, that would certainly be nice. I know it would be possible, but haven’t run across anyone doing it in QMK. Not that I searched very hard.
Regarding interest, I’ve run into a couple of people ask for that kind of ability, select-able per-key colors without delving into editing the firmware, compiling, flashing. It’s a lot for someone to get into if they haven’t already done similar.
lol, well i have been working on learning QMK since the day i first asked about it here but there is so much still that i need to learn and i created like 10 keymaps with different structures going from completely uncondensed to as far condensed as i could without going into bitwise operations. The biggest issue right now for me is how to send the new RGB values to eeprom only when i specify rather than update every single time you adjust so you are not wasting eeprom writes. i was trying to figure out how to swap the eeprom versions of the RGB adjust keycodes into noeeprom ones. and before power off or enter into bootloader it sends a final update to eeprom so when it comes back on it keeps the settings. i saw that you could do it with certain settings but not how to just send ANY data i wanted to eeprom like the array that holds all the RGB values.
I haven’t played with RGB or eeprom storage of the RGB configs a whole lot. I started to a while ago, then I realized I rarely use RGB… so I stopped.
I really thought there were options not to write to eeprom for everything that does. And I recall seeing functions for storing arbitrary user data in eeprom, but I never used it. I’ll try to jog my memory & maybe delve back in when I have some time.
And forgive me if you already know, but I want to mention just in case, that on the rp2040 the “eeprom” isn’t real eeprom. RP2040 has no eeprom, so it’s simulated using a portion of flash. So while you still may not want to hammer it, it’s possible that it might not be an issue. Maybe depending on how much it will get used in normal use of your RGB firmware. Also, you could use wear-leveling. I think that’s not just enabled and used by default, but not sure. Never had a reason to need it.
~edit~
Oh, it looks like you’ve already enabled wear-leveling, if it wasn’t on to begin with.
Or, looking at the original Framework firmware now, it seems FW had already enabled & configured it to increase it’s size.
yes there are noeeprom versions of the RGB commands but without changing the actual firmware i am not sure how to swap them. i wanted to keep what i wrote to just the keyboard folder so anyone can just replace the framework keyboard folder and run with it. i was really hoping there was a setting that would auto use noeeprom if it was set.
Sorry but can you confirm that any changes that happen while the input device is active stay in the cache? or does it automatically get written to one of the bins of SRAM. Another thing, since we dont have a separate eeprom and its all together then why cant we keep the settings stored and access every time it cycles power? if its better to not write to memory as much then pulling up the last settings of the previous session would be more beneficial than going from zero and changing whatever you adjusted like brightness. the macropad can be pretty blinding at full brightness so to remember which setting it was previously would be nice.
Not sure I follow.
For the commands that have no-eeprom versions, one just uses that instead. rgb_matrix_toggle you swap with rgb_matrix_toggle_noeeprom. rgb_matrix_mode_noeeprom, rgb_matrix_step_noeeprom, rgb_matrix_increase_hue_noeeprom, etc.
But the commands that set individual keys, like rgb_matrix_set_color, I thought those just don’t save to eeprom at all. I see you’re using RGB_MATRIX_INDICATOR_SET_COLOR, is that being saved?
I don’t know details of how QMK handles memory. But if the setting isn’t retained, if the get command, such as rgb_matrix_get_hue, gives you nothing after a power cycle, then it must not have been written to the simulated eeprom.
The rp2040 is using flash but that still has write limits, and simulated eeprom is only using a small section of flash, unless you turn on wear-leveling & enlarge it’s size. So depending on your code, I imagine you could hammer the same small section.
Keep in mind that QMK isn’t just for roomy, capable MCUs like the rp2040, some MCUs are pretty limited, ones we had to use before options with resources to spare were available & cheap. A lot of things in QMK will default to states that don’t assume you have a lot of resources. Even pretty basic functioning, one didn’t always have the resources for on other chips. An example is mouse keys. With the rp2040, I don’t think there is a reason to not have it, but you do have enable it. I use mouse keys specifically as an example because, Framework didn’t enable it on the firmware that comes in the keyboard. I’m guessing it was an oversight. Since the Framework keyboards aren’t lacking for room, at least with the stock firmware. There are some QMK users that do crazy resource intensive things, like drawing to full color displays. They might not want things which they don’t use, taking up any resources.
for the noeeprom commands i was trying to keep from having to use the full name and redefining the shortcuts. that did not even compile.
Edit: i see that they are set in process_rgb.c with the regular versions and also in rgb_matrix.h and .c how should i attempt without changing those files?
so I stopped.