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.
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.
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β.
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.
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.
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β)
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.
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.
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.
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.
When I was just using matrix I had some warnings about this:
Summary
[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 permissionsi 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?
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.