[Bug] RGBLED_SPLIT causes indexing overwflow

[muteso]

Describe the Bug

Greetings! Initially i'm just tried to find out how to turn on only one onboard led (i mean soldered directly in microcontroller) on right half of split keyboard when some nondefault layer is active regardless to which half is plugged in with usb cable. And there is no any working (as i described above) solution was found by me finally.

During my research i've tried a lot of combinations of #define and functions, and found something useful (as i thought):

// config.h

#ifdef RGBLIGHT_ENABLE
#   define WS2812_DI_PIN 16
#   define RGBLIGHT_LED_COUNT 2
// #   define RGBLED_SPLIT { 1, 1 }
// #   define SPLIT_LED_STATE_ENABLE
// #   define SPLIT_LAYER_STATE_ENABLE
#endif

// keymap.c

#ifdef RGBLIGHT_ENABLE
layer_state_t layer_state_set_user(layer_state_t state) {
    if (!layer_state_cmp(state, 0)) {   
        rgblight_sethsv_at(128, 255, 70, 1); // cyan with lowered brightness
    } else {
        rgblight_sethsv_at(0,   0,   0,  1); // off
    };
    return state;
} 
#endif

... but all of this didn't work as explained (or as i understood) in docs - 1-indexed led never turned on in all combinations of #define and "targeting" (with _at-suffix) rgblight-functions. After this failure i've tried other one combination - uncommented #define RGBLED_SPLIT { 1, 1 } and rgblight_sethsv_noeeprom(128, 255, 70) - and some progress at last - both leds were on. Then i've tried to debug what is happening underneath, cus something strange is happening if #define RGBLED_SPLIT { 1, 1 } was commented again - only one led was on on "active" half of keyboard (i mean half which is plugged in with usb cable).

And i've found some bug here when #define RGBLED_SPLIT is included - as clipping borders of leds "chain" is redifining by this macro, in a lot of rgblight-function (except rgblight_sethsv_noeeprom, which uses effect borders, but it's really doesn't matter here) when you try to access 0-indexed led you will get overflowed uint8_t (255 in my case) from rgblight_led_index on right half of keyboard which finally (on drivers level) have to point to "garbage" or nonallocated data. But even if i use rgblight_sethsv_noeeprom instead of rgblight_sethsv_at there is always both leds on regardless overflowing (0 and 1 is mutated to 255 and 0 accordingly).

Please help me find out what is happening - i may admit that i miss something but overflowing looks buggy anyway.

Keyboard Used

silakka54/vial (modified latest version - 1.4.0)

Link to product page (if applicable)

https://github.com/Squalius-cephalus/silakka54

Operating System

qmk+vial

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.2.0
Ψ QMK home: /home/sam/projects/vial-qmk
Ψ Detected Linux (WSL, Ubuntu 22.04.1 LTS).
Ψ Userspace enabled: False
Ψ Git branch: vial
⚠ Git has unstashed/uncommitted changes.
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ CLI installed in virtualenv.
⚠ Issues encountered while checking dependencies.
Ψ Found arm-none-eabi-gcc version 15.2.0
Ψ Successfully compiled using arm-none-eabi-gcc
Ψ Successfully tested arm-none-eabi-binutils using arm-none-eabi-size
Ψ Found avr-gcc version 15.2.0
Ψ Successfully compiled using avr-gcc
Ψ Successfully tested avr-binutils using avr-size
⚠ Unknown version for avrdude
⚠ Unknown version for dfu-programmer
⚠ Unknown version for dfu-util
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2025-05-15 08:25:11 +0000 --  (8bd61b8043)
Ψ - lib/chibios-contrib: 2025-01-08 21:03:31 +0100 --  (3ac181e4)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2025-04-20 21:24:29 +1000 --  (d0c5cac)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go, but minor problems were found

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

vial framework

Additional Context

Keyboard if flashed with two versions of firmware - left (common) and right (with #define MASTER_RIGHT) for each half of keyboard.
Microcontroller is used by keyboard - RP2040-Zero.

[spidey3]

Do you have RGBLIGHT_ENABLE = yes in your rules.mk, or "rgblight": true in the features section of keyboard.json?
Do any other RGBLIGHT functions work for you (e.g. effects)?

[muteso]

Yes, i have this in rules.mk:

RGBLIGHT_ENABLE = yes
WS2812_DRIVER = vendor

So, as i said, some positive effect may be reached in some functions, but how it works is totally unclear regrdless how it explained in documentation (or maybe i miss something vital). I've tested all rgblight-functions this way:

bool process_record_user(uint16_t keycode, keyrecord_t *record) {
    if (record->event.pressed) {
        switch (keycode) { 
        case KC_RBRC:
            rgblight_sethsv(HSV_CYAN); break;  
        case KC_Q:
            rgblight_sethsv_at(HSV_CYAN, 0); break; 
        case KC_W:
            rgblight_sethsv_at(HSV_CYAN, 1); break;  
        case KC_E:
            rgblight_sethsv_noeeprom(HSV_CYAN); break; 
        case KC_R:
            rgblight_sethsv_master(HSV_CYAN); break;  
        case KC_T:
            rgblight_sethsv_slave(HSV_CYAN); break; 
        case KC_Y:
            rgblight_enable_noeeprom(); break; 
        case KC_U:
            rgblight_sethsv_range(HSV_CYAN, 0, 2); break; 
        default:
            rgblight_sethsv(HSV_OFF);
        }
    };

    return true;
}

... and this is what i've got:

                                             #define RGBLED_SPLIT { 1, 1 }
                                         -------------------------------------
                                         without           |              with
                                         -------------------------------------
rgblight_sethsv(HSV_CYAN)                on active         |           on both
rgblight_sethsv_at(HSV_CYAN, 0)          on active         |    on active-left
rgblight_sethsv_at(HSV_CYAN, 1)          off both          |   on active-right
rgblight_sethsv_noeeprom(HSV_CYAN)       on active         |           on both
rgblight_sethsv_master(HSV_CYAN)         on active         |         undefined
rgblight_sethsv_slave(HSV_CYAN)          off both          |         undefined
rgblight_enable_noeeprom()               on active         |          off both
rgblight_sethsv_range(HSV_CYAN, 0, 2)    on active         |         on active

active    - half with plugged usb cable
left      - left half of keyboard
right     - right half of keyboard
undefined - fucntion is absent

Hope this will tell you something.

P.S.: the main problem of all this functions that all of them work almost identically - just iterates through some range of indexes (in my case 0 and 1), for each mutating with rgblight_led_index (where i've found a bug) and calling rgblight_driver.set_color + rgblight_driver.flush with mutated ones. Only the one function has differences - rgblight_sethsv (and rgblight_sethsv_noeeprom) which uses RGBLIGHT_SPLIT_SET_CHANGE_HSVS-macro and rgblight_config - maybe this is the answer why this function lights both leds (including "nonactive" half of keyboard) unlike others.

[newacorn]

I also have the silakka54 keyboard. I use RGB Matrix instead of LED Matrix, and with a bit of configuration you can achieve your goal. Below is an excerpt from the official QMK documentation:

This feature allows you to use LED matrices driven by external drivers. It hooks into the backlight system so you can use the same keycodes as backlighting to control it.
If you want to use RGB LEDs you should use the RGB Matrix Subsystem instead.

If you want to control the right side lit regardless of which half the USB cable is plugged into, you need to refer to https://docs.qmk.fm/features/split_keyboard to fix the left and right sides.

[muteso]

@newacorn can you please share your solution with rgb matrix? Unfortunately i didn't get what you mean by "fix the left and right sides" - i thought that it's allright with them.

[newacorn]

Add "rgb_matrix": true to the features field, and add the rgb_matrix and ws2812 fields.
keyboard.json

{
    "keyboard_name": "silakka54",
    "manufacturer": "Squalius-cephalus",
    "url": "https://github.com/Squalius-cephalus/silakka54",
    "maintainer": "Squalius-cephalus",
    "processor": "RP2040",
    "bootloader": "rp2040",
    "usb": {
        "vid": "0x3434",
        "device_version": "1.0.0",
        "pid": "0x1212"
    },
    "features": {
        "bootmagic": true,
        "extrakey": true,
        "mousekey": true,
        "nkro": true,
        "raw" : true,
        "rgb_matrix": true
           },
    "rgb_matrix": {
        "animations":{},
        "driver": "ws2812",
        "layout": [
            {"matrix": [0, 5], "x": 5, "y": 0, "flags": 4},
            {"matrix": [5, 5], "x": 6, "y": 0, "flags": 4}
        ],
        "max_brightness": 127,
        "sleep": true,
        "split_count": [1, 1]
    },
    "ws2812": {
        "driver": "vendor",
        "pin": "GP16"
    },

        "matrix_pins": {
        "cols": ["GP7", "GP8", "GP9", "GP10", "GP11", "GP12"],
        "rows": ["GP2", "GP3", "GP4", "GP5","GP6"]
    },
   ...

Add the following line to the config.h file.
config.h segment

#define EE_HANDS

Use different commands to flash the left and right PCBs; if your USB cable is always connected to the left side, you can skip this step and above.

 qmk flash -kb silakka54 -km default -bl uf2-split-left

qmk flash -kb silakka54 -km default -bl uf2-split-right

Both of the following code snippets should work. Of course, these settings are just one of the expected ways to make it work, and you should be able to gain some insights during the process.

#ifdef RGB_MATRIX_ENABLE
layer_state_t layer_state_set_user(layer_state_t state) {
    if (!layer_state_cmp(state, 0)) {
        rgb_matrix_set_color(1,128,255,70);
    } else {
        rgb_matrix_set_color(1,   0,   0,  0); // off
    };
    return state;
}
#endif

or

#ifdef RGB_MATRIX_ENABLE
layer_state_t layer_state_set_user(layer_state_t state) {
    if (!is_keyboard_left()) {
        if (!layer_state_cmp(state, 0)) {
            rgb_matrix_set_color(0,128,255,70);
        } else {
            rgb_matrix_set_color(0,   0,   0,  0); // off
        };
    }
    return state;
}
#endif

[newacorn]

@newacorn can you please share your solution with rgb matrix? Unfortunately i didn't get what you mean by "fix the left and right sides" - i thought that it's allright with them.你能分享一下你对 rgb matrix 的解决方案吗？不幸的是，我没明白你说的“修复左右两侧”是什么意思——我以为它们没问题。

"Keyboard if flashed with two versions of firmware - left (common) and right (with #define MASTER_RIGHT) for each half of keyboard."

Using this approach to fix left/right keyboard identification is indeed fine.I didn’t notice it at first. You should only need to configure RGB MATRIX to solve the problem.

[muteso]

@newacorn first of all, thank you for your advice! But unfortunately it works even worse for me - i've got just red-glowing leds on both halves (looks like default config) after pluggin' in usb cable, which cannot be adressed by rgb_matrix_set_color nor by 0 or 1 indexes. Dont't know how it works underneath and thus cannot even assume what is going wrong.

[muteso]

UPDATE: i've found some crutch solution - it looks like this:

// config.h

#ifdef RGBLIGHT_ENABLE  
#   define WS2812_DI_PIN 16
#   define RGBLIGHT_LED_COUNT 2
#   define RGBLED_SPLIT { 1, 1 }
#endif

// keymap.c

enum {
    _DEF,
    _SYM,
    _NAV,
};

#ifdef RGBLIGHT_ENABLE
#   define __orange 21, 255, 70 // orange with lowered brightness
#   define __green  85, 255, 70 // green with lowered brightness
#   define __off    0,  0,   0
#   ifdef RIGHT_MASTER
#       define __ind 1
#   else
#       define __ind 0
#   endif
layer_state_t layer_state_set_user(layer_state_t state) {
    switch (get_highest_layer(state | default_layer_state)) {
    case _NAV:
        rgblight_sethsv_noeeprom(__green);
        rgblight_sethsv_at(__off,  __ind);
        break; 
    case _SYM:
        rgblight_sethsv_noeeprom(__orange);
        rgblight_sethsv_at(__off, __ind);
        break; 
    default:
        rgblight_sethsv_noeeprom(__off);
    }
    return state;
}
#endif

This code always turns on "opposite" (to active half of keyboard) led. Considering that any active (i.e. plugged in with usb cable) side of keyboard treats itself as master and some inner syncing processing (like rgblight_handlers_slave, rgblight_status and split_shmem) i'm assuming that something totally wrong with WS2812-drivers or with my instance of keyboard (i didn't assembe it - just bought on aliexpess), cus "opposite" led is always (!!!) unreachable by functuins that don't affect rgblight_status-struct (which lies in shared memory as i assume) directly, like rgblight_sethsv and rgblight_sethsv_noeeprom - therefore redefining clipping and effect borders by defining RGBLED_SPLIT is at least useless (and at most very confusing). Continuing the thought, it looks like ws2812_leds appearing as continuous array of "leds" is "broken" too as we cannot use it like this - there is only 1 "real led" in array (under 0 index) which addresses to physically "local" led - there is no "leds from another half" after it - therefore any function that may address to "nonlocal" leds is useless (or confusing) by definition.

Hope i'm wrong, and this is exactly my keyboard's instance problem - can someone please give me some explanations about syncing and managing between halves of split keyboards - from my perspective it looks like that both halves do some similar init and then work completely different - master runs come managment code (including user-written callbacks) and slave just runs some rpc-style handlers called form the master and some slave-specific callbacks.

[muteso]

UPDATE: i've found much less crutchy solution (previous one has "blinking" issue when turning on and quickly off local led) - now i've modified quantum src-files:

// quantum/rgblight/rgblight.h

#ifdef RGBLIGHT_SPLIT
void my_rgblight_sethsv_onsplit(uint8_t hue, uint8_t sat, uint8_t val, uint8_t index);
#endif

// quantum/rgblight/rgblight.c

#ifdef RGBLIGHT_SPLIT
void my_rgblight_sethsv_onsplit(uint8_t hue, uint8_t sat, uint8_t val, uint8_t index) {
    if (rgblight_config.enable) {
        uint8_t min_ind = rgblight_ranges.clipping_start_pos;
        uint8_t max_ind = rgblight_ranges.clipping_start_pos + rgblight_ranges.clipping_num_leds - 1;
        if (index > max_ind || index < min_ind) {
            // other half of the split keyboard

            // it works badly (but it's better then current implementation) as after
            // syncing of config and status all leds will be turned on on the other 
            // side of keyboard - to fix this it's necessary to rewrite syncing data
            // model and algorithm, but i don't have decent knowledge about this

            if (rgblight_config.hue != hue || 
                rgblight_config.sat != sat ||
                rgblight_config.val != val) 
            {
                RGBLIGHT_SPLIT_SET_CHANGE_HSVS;
            }
            rgblight_status.base_mode = mode_base_table[rgblight_config.mode];

            rgblight_config.hue = hue;
            rgblight_config.sat = sat;
            rgblight_config.val = val;
        } else {
            // local half of the split keyboard
            
            rgblight_sethsv_at(hue, sat, val, index);
        }
    }
}
#endif

// config.h

#ifdef RGBLIGHT_ENABLE  
#   define WS2812_DI_PIN 16
#   define RGBLIGHT_LED_COUNT 2
#   define RGBLED_SPLIT { 1, 1 }
#endif

// keymap.c

enum {
    _DEF,
    _SYM,
    _NAV,
};

#if defined(RGBLIGHT_ENABLE) && defined(RGBLED_SPLIT)
#   define __orange 21, 255, 60 // orange with lowered brightness
#   define __green  85, 255, 60 // green with lowered brightness
#   define __off    0,  0,   0
layer_state_t layer_state_set_user(layer_state_t state) {
    switch (get_highest_layer(state | default_layer_state)) {
    case _NAV:
        my_rgblight_sethsv_onsplit(__green,  1);
        break; 
    case _SYM:
        my_rgblight_sethsv_onsplit(__orange, 0);
        break; 
    default:
        rgblight_sethsv_noeeprom(__off);
    }
    return state;
}
#endif

Sadly my assumption about "broken" drivers and useless rgblight-functions in case of defined RGBLED_SPLIT are confirmed, because my custom function works as expected - current drivers and rgblight-functions implementation cannot access leds on the "other" half of keyboard by indexes, but it can be done only by mutating rgblight_config and rgblight_status which are then synced by master side of keyboard to the slave side (but i don't know how - looks like by some transaction-mechanism and shared memory both) - during syncing slave side calls rgblight_sethsv_eeprom_helper (which is, by the way, wrapped by rgblight_sethsv and rgblight_sethsv_noeeprom) if found some changes in rgblight_status.change_flags - and this is it, i've just used this mechanism in my custom function, to trigger "other side" led (to be honest all "other side" leds, but in my case there is only 1, so this if fine, but still crutchy), while triggering "local" led "directly".

Looks like fixing this problem is requiring some relatively heavy refactoring on the drivers side, sync side and functions side of rgblight functionality regardless RGBLED_SPLIT is defined or not, cus, for example, rgblight_sethsv_master and rgblight_sethsv_slave, which are present only if the RGBLED_SPLIT is not defined, are completely useless - they will not do what is expected of them in current implementation.