[Bug] Using RGBLIGHT breaks split keyboards

[VeyPatch]

Describe the Bug

Currently all of our (splitkb.com) keymaps/keyboards which uses RGBLIGHT are broken. Full list shown below. Broken here is defined as: Unresponsive, garbled OLED and stuck RGB. So basically the whole keyboard is locked up. Interestingly when plugging the left side of the keyboard in to the host. The left side itself does seem to work correctly but not the right side. But when the right side is plugged in, both halves do nothing.

Going back through the PR/commit history I've found that the following PR/commit broke the keyboard behavior: #24364

Broken keymaps/keyboard which have been tested (and all use RGBLIGHT):
splitkb/kyria/rev3:default
splitkb/kyria/rev3:debug
splitkb/aurora/helix/rev1:debug
splitkb/aurora/corne/rev1:debug
splitkb/aurora/lily58/rev1:debug
splitkb/aurora/sofle_v2/rev1:debug
splitkb/aurora/sweep/rev1:debug

These were all compiled with the -e CONVERT_TO=liatris option.

I can imagine more keyboards are broken which are split and still uses RGBLIGHT.

Keyboard Used

splitkb/kyria/rev3:default

Link to product page (if applicable)

No response

Operating System

WSL2

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.6
Ψ QMK home: /home/xxx/Github/qmk/qmk_firmware
Ψ Detected Linux (WSL, Debian GNU/Linux 12 (bookworm)).
Ψ Userspace enabled: False
Ψ Git branch: master
Ψ Repo version: 0.27.1
Ψ - Latest master: 2024-12-15 04:00:18 +0000 (767dfbbd3f) -- Resolve `cli.log.warn` warnings (#24551)
Ψ - Latest upstream/master: 2024-12-15 04:00:18 +0000 (767dfbbd3f) -- Resolve `cli.log.warn` warnings (#24551)
Ψ - Latest upstream/develop: None
Ψ - Common ancestor with upstream/master: 2024-12-15 04:00:18 +0000 (767dfbbd3f) -- Resolve `cli.log.warn` warnings (#24551)
Ψ - Common ancestor with upstream/develop: None
Ψ CLI installed in virtualenv.
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 12.2.1
Ψ Successfully compiled using arm-none-eabi-gcc
Ψ Successfully tested arm-none-eabi-binutils using arm-none-eabi-size
Ψ Found avr-gcc version 5.4.0
Ψ Successfully compiled using avr-gcc
Ψ Successfully tested avr-binutils using avr-size
Ψ Found avrdude version 7.1
Ψ Found dfu-programmer version 0.6.1
Ψ Found dfu-util version 0.11
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2024-02-17 19:20:06 +0000 --  (be44b3305f)
Ψ - lib/chibios-contrib: 2024-04-03 20:39:24 +0800 --  (77cb0a4f)
Ψ - 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: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

Solution could be that we change all our broken keymaps to use RGB_MATRIX. But it's probably better to fix the bug within RGBLIGHT as more boards could be affected.

[VeyPatch]

And to add to this. We have had two reports (in our discord server) of other users with a splitkb/kyria/rev3 that had the same behavior when compiling the default keymap.

[VeyPatch]

Additional finding:

When using an Elite-C (on an aurora helix) it ""works"" but the right side of the keyboard is shifted and mirrored and in full caps as in, Pressing y outputs L, u outputs K, i outputs J. (whoops, that's how our debug firmware works ofcourse🤦) Our debug firmware uses RGBLIGHT_EFFECT_BREATHING. When the breathing happens part of the OLED screen also changes in sync with the RGB.

[VeyPatch]

As suggested by fauxpark on discord, disabling LTO fixes the issues.