i have seen two different posts glossing over this but i need a step by step guide and i feel others do too to set everything up and to change the per key color. i have some knowledge of light coding but trying to follow what was posted or the framework github directory has left me pulling out my hair. I cant figure out what files are even needed from keyboard directory. i just want to make certain keys same color while rest are different depending on the task. i wasnt expecting to have to go down a huge rabbit hole to get it to work but if i could follow a full guide then it would make all the difference in the world.
You’ll want to clone the branch for the latest release. I wrote a little step-by-step here
• Controlling a particular key’s LED / per key color, step-by-step.
You can use this function to set the color of a given LED.
rgb_matrix_set_color(index, r, g, b)
docs.qmk.fm/#/feature_rgb_matrix?id=direct-operation
It would be placed into your keymap.c file. Exactly where you’d put it depends on what you’re looking to do.
But you see that the rgb_matrix_set_color(index, r, g, b) function requires the index number of the LED. You’ll have to look that up.
It’s not obvious how to do it, and it’s a multi-step process cross-referencing files, for each and every key. So it really needs a step-by-step how-to.
Step-by-step, Finding LED index numbers for each key
Let’s use the macropad as an example. I believe you would find the LED index like this:
Go to /framework/macropad/macropad.h and find the keymatrix location for the key you wish to control.
#define LAYOUT( \
H1, H2, H3, H4, \
K90, K95, K100, K105, \
K91, K96, K101, K107, \
K92, K97, K102, K106, \
K93, K98, K103, K109, \
K99, K110, K104, K108 \
) \
{ \
{ K90, K91, K92, K93, K95, K96, K97, K98 }, \
{ K99, K100, K101, K102, K103, K104, K105, K106 }, \
{ K108, H1, H2, KC_NO, H4, K107, K109, K110 }, \
{ KC_NO, KC_NO, KC_NO, KC_NO, H3, KC_NO, KC_NO, KC_NO }, \
}
Say you want the top left key, that’s H1 in the LAYOUT section.
#define LAYOUT( \
H1, H2, H3, H4, \
Now find H1 in the keymatrix section right below it. Note its location within this section. It’s at row 3, column 2.
{ K108, H1, H2, KC_NO, H4, K107, K109, K110 }, \
Now go to /framework/macropad/macropad.c and search for “Key Matrix to LED Index”.
led_config_t g_led_config = { {
// Key Matrix to LED Index
{ 4, 7, 6, 9, 0, 1, 3, 11, },
{ 8, 20, 21, 23, 15, 14, 18, 19, },
{ 12, 5, 2, NO_LED, 17, 16, 13, 10, },
{NO_LED, NO_LED, NO_LED, NO_LED, 22, NO_LED, NO_LED, NO_LED, },
}
Go to the matching location, row 3, column 2. You find a number 5 at that location.
{ 12, 5, 2, NO_LED, 17, 16, 13, 10, },
Your LED index for that key is 5.
So then to control that particular key you would use
rgb_matrix_set_color(5, r, g, b)
Since I was I looking through it, I went ahead and banged out the Macropad LED index numbers.
/* Macropad key location to LED Index
* ┌────┬────┬────┬────┐
* row 1 │ 5 │ 2 │ 22 │ 17 │
* ├────┼────┼────┼────┤
* row 2 │ 4 │ 0 │ 20 │ 18 │
* ├────┼────┼────┼────┤
* row 3 │ 7 │ 1 │ 21 │ 16 │
* ├────┼────┼────┼────┤
* row 4 │ 6 │ 3 │ 23 │ 19 │
* ├────┼────┼────┼────┤
* row 5 │ 9 │ 11 │ 15 │ 13 │
* ├────┼────┼────┼────┤
* row 6 │ 8 │ 10 │ 14 │ 12 │
* └────┴────┴────┴────┘
* 24 keys and LEDs total
*/
It’s in a comment block so that you can just throw it into your keymap.c for future reference.
Let me know if you discover any to be wrong.
.
Disclaimer, I don’t yet have a FWL16, I’ve just used qmk on other devices.
5 Likes
That motivated me to try to get that map together for the US (ANSI) layout. This should be mostly accurate:
/* ANSI/US RGB keyboard key location to LED Index
*
* ┌─────┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬────┐
* row 1 │ 25 │ 21│ 19│ 18│ 20│ 22│ 24│ 26│ 67│ 74│68│66/71│70│72/73│
* ├───┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴────┤
* row 2 │ 16│ 15│ 13│ 12│ 11│ 9 | 14│ 10│ 17│ 69│ 61│ 63│ 62│ 65 │
* ├───┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬────┤
* row 3 │ 1 │ 5 │ 3 │ 2 │ 4 │ 7 │ 8 │ 6 │ 58│ 59│ 60│ 57│ 54│ 55 │
* ├─────┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴────┤
* row 4 │ 44 │ 36│ 41│ 37│ 43│ 39│ 40│ 49│ 50│ 51│ 48│ 52│ 56 │
* ├──────┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴───────┤
* row 5 │ 32 │ 27│ 29│ 31│ 33│ 35│ 76│ 77│ 78│ 75│ 79│ 92 │
* ├────┬───┼───┼───┼───┴───┴───┴───┴───┼───┼───┼───┴┬───┬────┤
* │ │ │ │ │ │ │ │ │ 81│ │
* row 6 │ 34 │ 93│ 46│ 47│ 94 │ 84│ 88│ 89 ├───┤ 91 │
* │ │ │ │ │ │ │ │ │ 90│ │
* └────┴───┴───┴───┴───────────────────┴───┴───┴────┴───┴────┘
*/
Edit: Interestingly, the Prt Scr/F11 and Del/Insert keys (at least) have two separate LEDs. I tried to show that in the map, though it looks weird.
5 Likes
For this section:
which file does it go into? and also can you explain the difference between the upper array and bottom and how do you decide where to put in bottom array the key names. is there a syntax format for these or any name will do?
same for this:
and this:
ok, is the config.h and framework.h the same file?
if i make a folder for my setup do i need all these files in this folder or do they stay in the higher directory?
config.h
framework.h
info.json
keymap.c
rule.mk
also can these names be altered (personalized) and still work?
and can you explain this as the qmk docs dont go into detail as much as i need and want to be able to make this from scratch so i know how to determine everything so can change and know how in future:
led_config_t g_led_config = { {
// Key Matrix to LED Index
{ 5, NO_LED, NO_LED, 0 },
{ NO_LED, NO_LED, NO_LED, NO_LED },
{ 4, NO_LED, NO_LED, 1 },
{ 3, NO_LED, NO_LED, 2 }
}, {
// LED Index to Physical Position
{ 188, 16 }, { 187, 48 }, { 149, 64 }, { 112, 64 }, { 37, 48 }, { 38, 16 }
}, {
// LED Index to Flag
1, 4, 4, 4, 4, 1
} };
yours only had the first section not the bottom two. do you know these?
on the info.json file there is this section:
"matrix_pins": {
"cols": ["C0", "C1", "C2", "C3", "C4", "C5", "C6", "C7", "C8", "C9", "C10", "C11", "C12", "C13"],
"rows": ["B0", "B1", "B2", "B3", "B4", "B5"]
},
i changed a default file as i thought it would work better if i made it 14 columns to cover all the keys in upper rows but not sure if this is correct to do or even if you can choose your own pins or there is a location to figure out the pins and designation.
in same info.json file i changed the layout from 5x12 to this 6x14 instead of default from the 7c8/framework qmk folder:
"processor": "atmega328p",
"bootloader": "usbasploader",
"layouts": {
"LAYOUT_ortho_6x14": {
"layout": [
{"matrix": [0, 0], "x": 0, "y": 0},
{"matrix": [0, 1], "x": 1, "y": 0},
{"matrix": [0, 2], "x": 2, "y": 0},
{"matrix": [0, 3], "x": 3, "y": 0},
{"matrix": [0, 4], "x": 4, "y": 0},
{"matrix": [0, 5], "x": 5, "y": 0},
{"matrix": [0, 6], "x": 6, "y": 0},
{"matrix": [0, 7], "x": 7, "y": 0},
{"matrix": [0, 8], "x": 8, "y": 0},
{"matrix": [0, 9], "x": 9, "y": 0},
{"matrix": [0, 10], "x": 10, "y": 0},
{"matrix": [0, 11], "x": 11, "y": 0},
{"matrix": [0, 12], "x": 12, "y": 0},
{"matrix": [0, 13], "x": 13, "y": 0},
{"matrix": [1, 0], "x": 0, "y": 1},
{"matrix": [1, 1], "x": 1, "y": 1},
{"matrix": [1, 2], "x": 2, "y": 1},
{"matrix": [1, 3], "x": 3, "y": 1},
{"matrix": [1, 4], "x": 4, "y": 1},
{"matrix": [1, 5], "x": 5, "y": 1},
{"matrix": [1, 6], "x": 6, "y": 1},
{"matrix": [1, 7], "x": 7, "y": 1},
{"matrix": [1, 8], "x": 8, "y": 1},
{"matrix": [1, 9], "x": 9, "y": 1},
{"matrix": [1, 10], "x": 10, "y": 1},
{"matrix": [1, 11], "x": 11, "y": 1},
{"matrix": [1, 12], "x": 12, "y": 1},
{"matrix": [1, 13], "x": 13, "y": 1},
{"matrix": [2, 0], "x": 0, "y": 2},
{"matrix": [2, 1], "x": 1, "y": 2},
{"matrix": [2, 2], "x": 2, "y": 2},
{"matrix": [2, 3], "x": 3, "y": 2},
{"matrix": [2, 4], "x": 4, "y": 2},
{"matrix": [2, 5], "x": 5, "y": 2},
{"matrix": [2, 6], "x": 6, "y": 2},
{"matrix": [2, 7], "x": 7, "y": 2},
{"matrix": [2, 8], "x": 8, "y": 2},
{"matrix": [2, 9], "x": 9, "y": 2},
{"matrix": [2, 10], "x": 10, "y": 2},
{"matrix": [2, 11], "x": 11, "y": 2},
{"matrix": [2, 12], "x": 12, "y": 2},
{"matrix": [2, 13], "x": 13, "y": 2},
{"matrix": [3, 0], "x": 0, "y": 3},
{"matrix": [3, 1], "x": 1, "y": 3},
{"matrix": [3, 2], "x": 2, "y": 3},
{"matrix": [3, 3], "x": 3, "y": 3},
{"matrix": [3, 4], "x": 4, "y": 3},
{"matrix": [3, 5], "x": 5, "y": 3},
{"matrix": [3, 6], "x": 6, "y": 3},
{"matrix": [3, 7], "x": 7, "y": 3},
{"matrix": [3, 8], "x": 8, "y": 3},
{"matrix": [3, 9], "x": 9, "y": 3},
{"matrix": [3, 10], "x": 10, "y": 3},
{"matrix": [3, 11], "x": 11, "y": 3},
{"matrix": [3, 12], "x": 12, "y": 3},
{"matrix": [3, 13], "x": 13, "y": 3},
{"matrix": [4, 0], "x": 0, "y": 4},
{"matrix": [4, 1], "x": 1, "y": 4},
{"matrix": [4, 2], "x": 2, "y": 4},
{"matrix": [4, 3], "x": 3, "y": 4},
{"matrix": [4, 4], "x": 4, "y": 4},
{"matrix": [4, 5], "x": 5, "y": 4},
{"matrix": [4, 6], "x": 6, "y": 4},
{"matrix": [4, 7], "x": 7, "y": 4},
{"matrix": [4, 8], "x": 8, "y": 4},
{"matrix": [4, 9], "x": 9, "y": 4},
{"matrix": [4, 10], "x": 10, "y": 4},
{"matrix": [4, 11], "x": 11, "y": 4},
{"matrix": [4, 12], "x": 12, "y": 4},
{"matrix": [4, 13], "x": 13, "y": 4}
]
},
its confusing in the documentation which files everything go in and which ones need to be made particularly for this keyboard and what needs to be left alone.
i have already created this for keymap.c:
#include QMK_KEYBOARD_H
enum framework_layers {
_BASE,
_FN,
_MO1
};enum framework_keycodes {
FN = SAFE_RANGE
};const uint16_t PROGMEM keymaps[MATRIX_ROWS][MATRIX_COLS] = {
[_BASE] = LAYOUT_ortho_6x14(
KC_ESC, KC_MUTE, KC_VOLD, KC_VOLU, KC_MRWD, KC_MPLY, KC_MFFD, KC_BRID, KC_BRIU, RGB_TOG, MO(_MO1), KC_PSCR, KC_APP, KC_DEL,
KC_GRV, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_MIN, KC_EQL, KC_BSPC,
KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, KC_LBRC, KC_RBRC, KC_BSLS,
KC_CAPS, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, KC_SCLN, KC_QUOT, KC_ENT,
KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, KC_UP,
KC_LCTL, FN, KC_LGUI, KC_LALT, KC_SPC, KC_RALT, KC_RCTL, KC_LEFT, KC_DOWN, KC_RGHT
),[_FN] = LAYOUT_ortho_6x14(
QK_LOCK, KC_F1, KC_F2, KC_F3, KC_F4, KC_F5, KC_F6, KC_F7, KC_F8, KC_F9, KC_F10, KC_F11, KC_F12, KC_INS,
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, KC_PGUP, _______,
_______, _______, _______, _______, BL_STEP, _______, _______, KC_HOME, KC_PGDN, KC_END
),[_MO1] = LAYOUT_ortho_6x14(
_______, _______, _______, _______, _______, _______, _______, _______, _______, QK_BOOT, _______, _______, _______, _______,
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______
)
};
it doesnt match up when i pasted this portion but i had it all spaced out to look nice. do you see anything wrong so far?
i want to have the function keys to change color when the function layer is active and same for momentary layer and keys assocciated with each layer.
would like to make caps lock key to change color when toggled.
after i do this i will try to do something similar to the macropad to have it color coded and for different layers. i dont know where you got your macropad.h file as i have not been able to find it so far, can you tell me where?
and for the VIA version it used BL_CYCLE on the spacebar to cycle through the brightness levels, is this the same as BL_STEP from qmk docs?
ok and final question is which things can be changed directly in the file through editor and what needs to be setup in the qmk portal through commands? which files need to be linked in the qmk software to use the correct files?
Sorry, maybe my post wasn’t clear enough. That part of my post is just a how-to for finding the required LED index numbers. None of that gets modified or put into any of the firmware files. It’s just snips of what’s already there, just for the purpose of showing how to look up the LED index number.
But you don’t need to look them up anymore, since after I posted it, Ionitor did the work to create a map for the ANSI keyboard. And I did the map for the Macropad.
When you pull the Framework qmk source files, you will get everything.
Technically, a couple names could be changed, but I wouldn’t suggest doing that. And for most files, I don’t think their names can easily be changed.
7c8/framework is not the Framework keyboards. That’s a different set of qmk keyboards which just happened to use the “framework” name for their keyboard. Those are located at /keyboards/7c8/framework/. The Framework 16 keyboards are located starting as /keyboards/framework/.
If you’re unsure if you’re in the right folder, you can look for /keyboards/framework/macropad/info.json.
Open it and you’ll see this
{
"keyboard_name": "Laptop 16 RGB Macropad",
"manufacturer": "Framework",
"maintainer": "JohnAZoidberg",
"bootloader": "rp2040",
Yes, it’s actually BL_STEP. I don’t recall why Via calls it BL_CYCLE, if I ever even knew. Via has an annoying habit of using different names for several keys. The real names are found in /keyboards/framework/ansi/keymaps/default/keymap.c
I don’t know if I understand.
All of the files in /keyboards/framework/ can be modified with whichever editor you wish. As long as you don’t try to rename files. When compiling, QMK does some error checking, for things that it’s able to at least.
That would be placed into your keymap.c file. Exactly where you’d put it depends on what you want to do. For changing colors when changing layers, take a look at docs.qmk.fm/#/feature_layers?id=layer-change-code
i was asking if any steps need to be input by command in the qmk portal rather than edited in the actual files directly.
Sorry, what qmk portal?
Do you mean QMK toolbox?
docs.qmk.fm/#/newbs_flashing?id=flashing-your-keyboard-with-qmk-toolbox
I’ve never even looked at that since I’m on Linux.
It looks like it’s just to help with other chips that aren’t as easy as the RP2040 which is used in Framework’s keyboards. It even mentions
QMK Toolbox is not necessary for flashing RP2040 devices.
I have how to flash your firmware in my guide here Custom QMK firmware? - #14 by MJ1
there is two portals. the qmk toolbox and the QMK_MSYS. like i know setting up the environment you need to use the QMK_MSYS to input the commands for like where the directory is and the github url to the files. is there anything else that needs to be input in the portal or can it all be done directly in the files?
i have added the QK_BOOT on my momentary layer so that is how i get to point of flashing. but i have not compiled any files yet only through VIA so far as i knew i wasnt doing it correctly so far. i finally found the framework folder which for some reason was not part of my 3 other downloads of the qmk_firmware zip file. not sure why but at least now i can see that everything is ready for me to add the color settings. i would not be anywhere as confused if i knew what folders to look for in the beginning so it would be easier to follow your directions.
QMK toolbox doesn’t look like it provides anything one needs for flashing RP2040 chips.
QMK_MSYS, since I’m not on windows, I’m not certain. It looks like it just helps setup your build environment and also provides a command line terminal, where you should be able to enter the compile and / or flash commands.
Can you run
qmk doctor
in the QMK_MSYS window? If everything is good it will end with “QMK is ready to go”.
qmk doctor will list your home directory. Saying Ψ QMK home: /some-path/
If it doesn’t throw errors at you, then you should be good.
You can also try compiling just to see if it throws errors at you
qmk compile -kb framework/ansi -km default
Yeah, I can’t check the exact issues right now, but the Framework fork of QMK has some old bugs with the qmk doctor command, so trying to compile is the best way to check if it’s working. I think it’s that it fails to detect some binaries.
ok so i went down the path for RGB_MATRIX but found that RBGLIGHT is a better fit to create layers with rgb segments from ranges. the problem is that when i turned on RGBLIGHT i started getting errors. does anyone know what the driver would be for RGBLIGHT?
this is the start of the error:
platforms/chibios/drivers/ws2812_bitbang.c:12:10: error: #error (“NOP_FUDGE configuration required”)
12 | # error(“NOP_FUDGE configuration required”)
what platform and drivers does the RGB ansi keyboard even fall under?
i know what the driver is for the RGB_MATRIX so dont need that.
Whenever there are errors with modifications you’ve made, you really need to link your code, all of the files, like a github repo. The errors given when compiling often aren’t specific enough to know exactly what’s wrong just from seeing the error. All that error tells is that it tried to use the WS2812 driver, the default bitbang one.
But, not sure if you can switch to rgblight. The Framework RGB keyboard is using a IS31FL3743A RGB controller. I took a look and I don’t see built-in support for it with rgblight, only rgb_matrix.
1 Like
The reason I wanted to switch to RGBLIGHT is that it allows layers and can use ranges so don’t need to do each RGB separately. Also RGBLIGHT allows you to step the brightness but when I had the colors switched using rgb matrix it would step the brightness of the keys that were not changed and the keys that were changed were stuck at max brightness. I even tried to adjust the levels by lowering the values but it stayed max. That is with the rgb_matrix_set_color(index, r, g, b). I will try to switch the out with the i,h,s,v version to see if that works.
When I was just using matrix I had some warnings about this:
[WARNINGS]
|
| a:/program files/qmk_msys/mingw64/bin/…/lib/gcc/arm-none-eabi/12.2.0/…/…/…/…/arm-none-eabi/bin/ld.exe: warning: .build/framework_ansi_Cory.elf has a LOAD segment with RWX permissions
| a:/program files/qmk_msys/mingw64/bin/…/lib/gcc/arm-none-eabi/12.2.0/…/…/…/…/arm-none-eabi/bin/ld.exe: warning: .build/framework_ansi_Cory.elf has a LOAD segment with RWX permissions
i looked for the issue but you can only see that info in terminal. no direct access and i was lost trying to find the segments i needed to look at. although i did find on accident that if you compile a second time right after then it comes back with no warnings and no issues with it working once bootloaded. does this mean it hid the warnings on second compile or was it fixed somehow on second try?
To facilitate RGBLIGHT and using ranges i went through the files and rearranged the matrix so now the numbers start at 0 on the escape key and increases by one going right. i had no errors with this (as long as RGBLIGHT was not enabled) and i got every key assigned correctly.
When i only enabled RGBLIGHT and no code added in the keyboard files then it would spit out a ton of errors that all fall under the snippet i copied in my last reply. would you like me to copy and paste the whole error section in another reply?
i really think the RGBLIGHT errors were because the driver was not defined so it picked that one and qmk didnt like it at compile.
if you need anything copied or linked so you can see just let me know.
oh and looking into the files that code RGBLIGHT i found that RGBLIGHT is RGB_MATRIX as it was defined under RGBLIGHT_ENABLE inside rgb_matrix.h in the quantum folder. This is just a few i copied from the file.
define rgblight_toggle rgb_matrix_toggle
define rgblight_enable rgb_matrix_enable
define rgblight_disable rgb_matrix_disable
define rgblight_is_enabled rgb_matrix_is_enabled
define rgblight_mode rgb_matrix_mode
define rgblight_get_mode rgb_matrix_get_mode
define rgblight_step rgb_matrix_step
so why does it go crazy when i enable RGBLIGHT?
As MJ1 mentioned, we really need to see your code to understand what might be causing your problems. Can you at least paste the keymap.c file someplace? If you put it here, make sure to wrap it in ``` (3 backticks) on each end for readability.
That said, two thoughts from me:
-
I get the same warnings about LOAD segments when I compile. The Framework code is a bit of a work-in-progress, but that hasn’t stopped it from working for me.
-
My RGB code is minimal, but it sounds like you need a minimal starting point. Here’s my function for it:
bool rgb_matrix_indicators_user(void) {
if (rgb_matrix_config.enable == 1) {
if (layer_state_cmp(layer_state, _QWERTY_BASE)) {
// Highlight F and J keys (normal home index keys)
rgb_matrix_set_color(43, 64, 64, 0);
rgb_matrix_set_color(49, 64, 64, 0);
} else {
// Highlight F and K keys (Colemak T and N with right hand shifted)
rgb_matrix_set_color(43, 64, 64, 64);
rgb_matrix_set_color(50, 64, 64, 64);
}
if (layer_state_cmp(layer_state, _FM)) {
// Highlight function keys
rgb_matrix_set_color(21, 128, 128, 128);
rgb_matrix_set_color(19, 128, 128, 128);
rgb_matrix_set_color(18, 128, 128, 128);
rgb_matrix_set_color(20, 128, 128, 128);
rgb_matrix_set_color(22, 128, 128, 128);
rgb_matrix_set_color(24, 128, 128, 128);
rgb_matrix_set_color(26, 128, 128, 128);
rgb_matrix_set_color(67, 128, 128, 128);
rgb_matrix_set_color(74, 128, 128, 128);
rgb_matrix_set_color(68, 128, 128, 128);
rgb_matrix_set_color(66, 128, 128, 128);
rgb_matrix_set_color(71, 128, 128, 128);
rgb_matrix_set_color(70, 128, 128, 128);
}
}
return true;
}
If you want to cover more keys at once, look into rgb_matrix_indicators_advanced_user, as described here. This example shows handling all LEDs at once:
bool rgb_matrix_indicators_advanced_user(uint8_t led_min, uint8_t led_max) {
for (uint8_t i = led_min; i < led_max; i++) {
switch(get_highest_layer(layer_state|default_layer_state)) {
case 2:
rgb_matrix_set_color(i, RGB_BLUE);
break;
case 1:
rgb_matrix_set_color(i, RGB_YELLOW);
break;
default:
break;
}
}
return false;
}
That said, I expect it to be trickier for the Framework keyboard if you want to target certain chunks of the keyboard, given the very non-linear layout of the LEDs by index.
2 Likes
Yeah, either not specifying a rgblight driver or leaving something else out will cause it to try to fall back to the default one, the WS2812 bitbang driver.
But as I said, I see no support for IS31FL3743A with rgblight. So, you can’t specify the driver you would need. That’s the true issue.
IS31FL3743A uses the shared common is31fl3731 driver. Try to use it, and it will tell you it’s not a valid driver for rgblight.
* RGBLIGHT_DRIVER=is31fl3731 is not a valid RGB type [ERRORS]
builddefs/common_features.mk:310: *** Invalid RGBLIGHT_DRIVER. Stop.
All of the Framework keyboard’s RGB leds are connected to 2x IS31FL3743A RGB controllers. There is no other way to control them. Unless you are able to add support, you can’t use rgblight.
I don’t know if it’s the issue, but I suggest doing qmk clean before every compile or flash. You can get random problems if you don’t.
1 Like