RGB Matrix indicator on encoder action? | QMK | Page 1

restive sage Aug 20, 2025, 1:19 PM

#

I've come up with this, in order to change the color of the LED where my encoder is, based on a CCW/CW spin:

static bool encoder_active = false;
static bool encoder_clockwise = false;

#define ENCODER_LED_INDEX 65

bool process_record_user(uint16_t keycode, keyrecord_t *record) {
    if (last_encoder_activity_elapsed() < 500) {
        encoder_active = true;
    } else {
        encoder_active = false;
    }

    if (record->event.type == ENCODER_CW_EVENT) {
        encoder_clockwise = true;
    } else if (record->event.type == ENCODER_CCW_EVENT) {
        encoder_clockwise = false;
    }

    return true;
}

bool rgb_matrix_indicators_user(void) {
    if (encoder_active) {
        if (encoder_clockwise) {
            rgb_matrix_set_color(ENCODER_LED_INDEX, 0, 0xff, 0);
        } else {
            rgb_matrix_set_color(ENCODER_LED_INDEX, 0xff, 0, 0);
        }
    }

    return true;
}

I was able to figure out the index with some logging and investigation, but this just doesn't seem to be working at all... Anyone see what I'm missing?

jade pecan Aug 20, 2025, 1:34 PM

#

not that it is the problem, but your encoder_active ~~function~~ variable is useless

#

just check if (last_encoder_activity_elapsed() < 500) inside rgb_matrix_indicators_user

restive sage Aug 20, 2025, 1:34 PM

#

oh sure, that makes sense

#

uhh. i don't have a good feeling that'll fix it though 😮‍💨

jade pecan Aug 20, 2025, 1:35 PM

#

did you read the first part of the message?

#

where i say "not the problem but ... "

restive sage Aug 20, 2025, 1:35 PM

#

yes lol

#

i was agreeing with you

jade pecan Aug 20, 2025, 1:36 PM

#

have you tried returning false from your func?

#

that makes further logic (if any) running RGB indicators NOT to run its things

#

as in: maybe you are actually setting the color, but another piece of code is overwriting your change

viral storm Aug 20, 2025, 1:38 PM

#

this is a split board, yes?
if the led index is not on the same side that is plugged in, then this probably won't work

restive sage Aug 20, 2025, 1:38 PM

#

it is a split board yes... led is index 65, and is on the slave side

jade pecan Aug 20, 2025, 1:39 PM

#

each half can only affect its own LEDs, and processing of user input (ie: process_record_user) only happens on master half (ie: the one with USB plugged)

#

you would need to sync some info across halves

restive sage Aug 20, 2025, 1:41 PM

#

ahh ok, I did wonder about this: #help message

#

but rgb_matrix_indicators_advanced_user runs on both sides?

jade pecan Aug 20, 2025, 1:44 PM

#

yup

restive sage Aug 20, 2025, 1:47 PM

#

ok, will report back. luckily, I'm already familiar with custom data sync 😅

restive sage Aug 20, 2025, 4:27 PM

#

hmm, ok so this is where i ended up: https://github.com/dmyoung9/qmk_userspace/commit/487f286b6361ec034ea6a8ed9bbffbc879e4cda7

GitHub

Add encoder led slave sync · dmyoung9/qmk_userspace@487f286

#

that compiles, but my slave doesn't work when I flash it lol

jade pecan Aug 20, 2025, 4:53 PM

#

Code is muuuch more complex than needed

#

First thing, im pretty sure the "last activity" timers already get sync'ed by QMK

dusty ruin Aug 20, 2025, 4:56 PM

#

yup

#

#define SPLIT_ACTIVITY_ENABLE

#

but would need custom data syncing to syng the encoder activity

restive sage Aug 20, 2025, 11:06 PM

#

thanks all!

#

finally got it!

jade pecan Aug 20, 2025, 11:23 PM

#

restive sage finally got it!

took a quick look at code, you are no longer using encoder_led_t as far as i can tell (sending a bool directly over the wire), if so, i'd remove the typedef to avoid confusion

#

and the whole state_changed logic is very hard to read, could simply:

        const bool previous = g_encoder_clockwise;
        if (record->event.type == ENCODER_CW_EVENT) {
            g_encoder_clockwise = true;
        } else if (record->event.type == ENCODER_CCW_EVENT) {
            g_encoder_clockwise = false;
        }

        if (g_encoder_clockwise != previous) {
            transaction_rpc_send(ENCODER_LED_SYNC, sizeof(bool), &g_encoder_clockwise);
        }

restive sage Aug 21, 2025, 1:18 AM

#

ohh, don't need to bother with doing it in housekeeping then?

jade pecan Aug 21, 2025, 5:53 AM

#

Wtdym

restive sage Aug 22, 2025, 1:53 AM

#

I thought I had to wait until the housekeeping task to send the sync packet, but you've demonstrated that I can do it in process_record_user just fine

restive sage Aug 25, 2025, 5:24 PM

#

jade pecan each half can only affect its own LEDs, and processing of user input (ie: `proce...

is there a good way to figure out which things run only on master vs slave, in general?

jade pecan Aug 25, 2025, 5:28 PM

#

As a rule of thumb, every thing happens on both sides except for processing user input

#

But just put your question in a help channel if unsure

restive sage Sep 7, 2025, 11:24 PM

#

After running this as part of my keymap for the last couple weeks, I've decided to pull it out into a module: https://github.com/dmyoung9/qmk_userspace/tree/stable/modules/dmyoung9/encoder_led

GitHub

qmk_userspace/modules/dmyoung9/encoder_led at stable · dmyoung9/qm...

Userspace for the open-source QMK keyboard firmware. - dmyoung9/qmk_userspace

restive sage Sep 8, 2025, 1:00 AM

#

I had to figure out the LED index at the position on the matrix where my encoder is "manually"... how can I figure this out programmatically? I'm attempting to convert this to work similarly to Encoder Map, just with colors instead of keycodes 👀

dusty ruin Sep 8, 2025, 2:10 AM

#

there isn't a foolproof way to do so

#

if you know the matrix position for the switch on the encoder, you can use that to check the row and column in the g_led_config. But you may not know that, or it may not be exposed in a way that is readable to modules.

#

In theory, the layout section in the json should be mapping it, bu tthat's not always the case.

restive sage Sep 8, 2025, 2:45 AM

#

hmm, ok... so, for example, mine are at https://github.com/qmk/qmk_firmware/blob/master/keyboards/boardsource/lulu/info.json#L154-L155

GitHub

qmk_firmware/keyboards/boardsource/lulu/info.json at master · qmk/...

Open-source keyboard firmware for Atmel AVR and Arm USB families - qmk/qmk_firmware

#

which, again, works for me because I went and found them, but I basically want to write a function that can take in encoder index and give me led index

#

fwiw I got 65, not from the layouts section, but from the rgb_matrix section ([9, 5])

restive sage Sep 8, 2025, 3:55 AM

#

I did find this: https://github.com/dmyoung9/qmk_firmware/blob/master/quantum/rgb_matrix/rgb_matrix.h#L152, which gives me an accurate index for either position on my board (including the one that is a switch instead of an encoder)... but still does not help me programmatically figure out which index maps to an/each encoder

GitHub

qmk_firmware/quantum/rgb_matrix/rgb_matrix.h at master · dmyoung9/...

Open-source keyboard firmware for Atmel AVR and Arm USB families - dmyoung9/qmk_firmware

#

more accurately, if I know the index of the encoder (< NUM_ENCODERS), I need to find the row and column in the switch matrix that correspond to that position

warm charm Sep 8, 2025, 3:59 AM

#

Encoder pins are unrelated to the LED position isn't it?

restive sage Sep 8, 2025, 4:03 AM

#

yeah, probably?

warm charm Sep 8, 2025, 4:06 AM

#

which index maps to an/each encoder
If QMK does not have the index or physical location, it will need to be supplied with that information to determine it programmatically.

restive sage Sep 8, 2025, 4:19 AM

#

right, now that makes sense... ok I have a path forward here 👌

restive sage Sep 25, 2025, 12:47 AM

#

Ok, so I've made a bunch of refactors to how I'm managing this functionality, and am super close to being able to slap a "release" sticker on the module, but am running into something with timers

#

I've added the ability to specify LED color on a per-layer, per-encoder, per-direction basis, similar to Encoder Map, and supporting (see: requiring lol) elpekenin/indicators colors, like this:

const uint8_t encoder_leds[NUM_ENCODERS] = { 65 };
const color_t PROGMEM encoder_ledmap[][NUM_ENCODERS][NUM_DIRECTIONS] = {
    [0] = { { HUE(HUE_RED), HUE(HUE_GREEN) } },
    [1] = { { HUE(HUE_YELLOW), HUE(HUE_YELLOW) } },
    [2] = { { HUE(HUE_PURPLE), HUE(HUE_PURPLE) } },
    [3] = { { HUE(HUE_ORANGE), HUE(HUE_ORANGE) } },
    [4] = { { HUE(HUE_CYAN), HUE(HUE_CYAN) } },
};

#

this all works great, up until this commit, where I'm trying to give each encoder its own timing. I am pretty sure that the current implementation is going to act funky if there are two encoders, so I feel like I need to do that... but I don't have two encoders on my board for this to even be tested lol

#

what I do have is one encoder, but it's on my slave side, hence the attention to making sure this is handled properly with slave sync

#

with the changes from that commit, my LED simply stops lighting up altogether, which makes me suspicious that timers are not synced to the slave, only the various activity timestamps... is that right?

jade pecan Sep 25, 2025, 6:18 AM

#

sync_timer_elapsed() exists

#

(unless user opts out of sync'ing it)

#

and FYI; you might want to use the 32 variant of timer APIs instead... using 16bits means the timer can count up to 2 ^ 16 - 1 milliseconds, which is not much (~65 seconds)

dusty ruin Sep 25, 2025, 8:20 AM

#

the 32 bit one is something like 45 days, IIRC

jade pecan Sep 25, 2025, 8:27 AM

#

(2 ^ 32 - 1) / (1000 * 60 * 60 * 24) to be precise 😛

restive sage Sep 25, 2025, 11:04 PM

#

ok yep, fair enough! and thanks for letting me to the sync timer methods... not mentioned in the docs anywhere I can see 😑 those fixed it immediately, two lines changed 🔥

dusty ruin Sep 26, 2025, 12:13 AM

#

well, not many people need to use them. They're mostly for stuff that actually needs syncing between halves, timing wise. Like animations. And even then ... it's a best effort, not a proper sync. "Current time + 2ms, and hope it's close enough"

restive sage Sep 26, 2025, 5:27 AM

#

module here: https://github.com/dmyoung9/qmk_modules/blob/stable/encoder_ledmap

GitHub

qmk_modules/encoder_ledmap at stable · dmyoung9/qmk_modules

Contribute to dmyoung9/qmk_modules development by creating an account on GitHub.

jade pecan Sep 26, 2025, 6:11 AM

#

i should maybe move my code to elpekenin/colors 🤔

#

and make both indicators and ledmap depend on it

restive sage Sep 26, 2025, 1:57 PM

#

I was thinking of trying to do that myself and make some PRs to you 👀

jade pecan Sep 26, 2025, 2:35 PM

#

restive sage I was thinking of trying to do that myself and make some PRs to you 👀

Feel free to

#

Will spend weekend out of home, but can do it myself (or merge PR) when i get back

restive sage Sep 26, 2025, 2:36 PM

#

we'll see if I get around to it tbh lol

restive sage Sep 28, 2025, 2:07 AM

#

well I did lol I didn't refactor ledmap... it is a bit more involved, but seems like adding colors might make it significantly simpler 👀

jade pecan Sep 28, 2025, 1:53 PM

#

Im on phone, wont bother doing a proper review on github

#

No need to include colors.h from indicators.c, it already includes indicators.h with in turn includes colors.h

#

And I'd also like to move the palette (u8 enum) to colors' module

#

But, of course, the getter to read one of those from ledmaps array would stay where it is

jade pecan Sep 28, 2025, 4:33 PM

#

I just thought, though, that maybe i could extend color_t with a transparent variant, and use it (instead of current palette) for ledmap

#

Seems like a better plan, can do it after merging the PR

#

Wont touch the PC today, but will try and do both things tomorrow

restive sage Sep 28, 2025, 6:47 PM

#

no problem, I will change up that import real quick, but yes I'd agree the "extras" like trans, none, white, and black would be good to have here

restive sage Sep 28, 2025, 11:49 PM

#

those are definitely things I want to support in encoder_ledmap, at least trans and white

jade pecan Sep 29, 2025, 6:24 PM

#

trans, none, white, and black

trans: i intended to add that already 🤓
none: is already a thing, if you forget to assign a value for color_t::type(ie: default value of 0), you get that
white: assuming you mean a white value whose brightness is the current RGB matrix's setting - was in my mind too
black: does this need special-casing? RGB_COLOR(RGB_BLACK) should just work 🤔

#RGB Matrix indicator on encoder action?