[Bug] RGB Light on split keyboard doesn't sync slave half correctly

[splitkb]

Describe the Bug

When I plug in the keyboard, the slave half will not sync the RGB underglow color to that of the master, sticking instead with the value saved in its own memory.

System Information

• Keyboard: Kyria
  • Revision (if applicable): rev1
• Operating system:
• AVR GCC version:

• ARM GCC version:

• QMK Firmware version:

• Any keyboard related software installed?
  • AutoHotKey
  • Karabiner
  • Other:

Additional Context

I haven't reproduced the problem myself, but one of my customers has. The problem seems to occur with other split keyboards too. This issue is meant to collect those reports, and to come to an eventual solution.

A related issue might be #6277.

[Dinduks]

Hello. I am the customer in question. I will be happy to help!

[zvecr]

Unable to reproduce since #8235 has gone in, can we get some more of that bug report info filled out in the ticket please.

[splitkb]

Bakingpy also said he had been experiencing this bug, he might have more information too.

[su8044]

Hello guys. i just installed the RGB to my handwired split and found i have this issue too. this is what i have found out so far:

• sometimes when the lights loose sync the keyboard will freeze completely after 15-30 seconds. this is most notable on the RGB mood and swirl animations but has happened on breathing too.
• if the keyboard has already lost sync and froze, unplugging and replugging will only work for a few seconds and then will go back again to freezing unless i get it out of its current animation really quick or toggle it off.
• if the breathing animation is going too fast it will start to visually loose sync, the 2 slowest levels seem to work fine.
• if i change hue too fast it will also lose sync and freeze.
• if i connect the right side and change modes, it will not save that mode on the right side and vice versa.
• when the RGB loses sync they seem to change color and dim a bit.

i have tested only breathing, swirl, and mood because they are the only ones the memory holds. im already at 99% capacity. knight and snake were very briefly tested and i didn't see the issues at the time

[mkleehammer]

I can confirm this on an Iris rev2.5. In my case I notice it when using RGB_VAD. It works a couple of times, but then freezes exactly like the previous comments - underglow colors change and dim and backlight goes off. I have to reflash and possibly clear EEPROM.

After reading the previous comment it occurs to me it could be that it happens when I click RGB_VAD a few times too fast. Now that it is somewhat working I didn't want mess with it just yet. If someone has troubleshooting steps I'd be happy to try.

[drashna]

I've been seeing this since #5509 actually. And I have a comment about it, at this point:
#5509 (comment)

At some point, that PR fixed the issue, but then later re-broke it, before it was merged.

I can confirm that it happens on split common, and VERY easy to reproduce (just flash one of my keymaps).

From what I can see, it should be working fine, but it's not. It's not 100%, but it's very consistent. At least when using the non-eeprom functions in layer_state_set_* functions.

My solution has (in part) been to use #5998, so that the matrix is mirrored, which ... fixes the issue. But is a bad hack.

I can confirm it with the Kyria, the Iris, the viterbi, the crkbd, the quefrency, and the orthodox. Any keyboard that uses the Split RGB and split common has this issue.

[ClementVanPeuter]

Can confirm this issue too, with only the Static (no animation) mode.
I'm on a Kyria.

When Hue is change (red to blue in my case) and the keyboard is plugged off and plugged in, slave part loose the right hue (color), and come back in red (default).

But for animations, slave part save the right Hue (Breathing mode is fine, the others too).
I flash with qmk toolbox.
Very weird behaviour.

[skychil]

I have the same problem, also on a Kyria.

Sometimes the board boots correctly (rainbow swirl), sometimes the slave side gets stuck in static mode (all red).

[gardella]

Whelp this just started happening me today after about a week of using my iris rev4. I haven’t made any changes to rgb settings for a week and today I toggled on rgb like I do each morning and this time main half came up with the right hue and slave half was red.

[NullSense]

Can confirm this issue on my bastyl mini as well. Turning on the keyboard without rgb, then turning rgb on makes the slave half not sync, furthermore if I change brightness or any rgb setting, they sync back up.

[Crote]

I think I figured out what is happening.

The sending transport code works as intended. On startup, it sends both the mode and hsv data. All fine.
On the receiving end, rgblight_update_sync is called. In this function, we see

    if (syncinfo->status.change_flags & RGBLIGHT_STATUS_CHANGE_MODE) {
        if (syncinfo->config.enable) {
            rgblight_config.enable = 1;  // == rgblight_enable_noeeprom();
            rgblight_mode_eeprom_helper(syncinfo->config.mode, write_to_eeprom);
        } else {
            rgblight_disable_noeeprom();
        }
    }
    if (syncinfo->status.change_flags & RGBLIGHT_STATUS_CHANGE_HSVS) {
        rgblight_sethsv_eeprom_helper(syncinfo->config.hue, syncinfo->config.sat, syncinfo->config.val, write_to_eeprom);
        // rgblight_config.speed = config->speed; // NEED???
    }

So what happens when rgb is disabled on startup? The mode has changed, so the receiver calls rgblight_disable_noeeprom, which sets rgblight_config.enable = 0. So far, so good. Next, the hsv value has changed, so rgblight_sethsv_eeprom_helper gets called. And what do we find there?

void rgblight_sethsv_eeprom_helper(uint8_t hue, uint8_t sat, uint8_t val, bool write_to_eeprom) {
    if (rgblight_config.enable) {
        // All the code doing stuff, including:
        rgblight_config.hue = hue;
        rgblight_config.sat = sat;
        rgblight_config.val = val;
    }
}

So because we just set the mode disabling the rgb lights, we are completely ignoring the hsv change and the initial color is not saved.
This means that the receiver is still using the old color data - which will be whatever it loaded from eeprom at initialization. Now, when the user enables the rgb lighting, the sync code will only send the new mode over, because the color hasn't been changed.
And there we are: the receiver happily enables the leds using the wrong color data.

[gardella]

thank you @Crote for digging into this! Has this been remedied at this point or is it still an active issue?

[tzarc]

Still an issue I'm afraid.

[keyboard-magpie]

Believe this is now remedied- closing for now.

[malparty]

Hi there,

I'm adding a small note if you struggled like me, it seems like QMK solved the issue, but we must flash BOTH sides 🥲

Thanks _jwe_ for his Reddit answer