[Bug] rgblight_sethsv_range doesn't work on slave half of split keyboard

[jtang9001]

Describe the Bug

Calling rgblight_sethsv_range seems to only change LEDs on the master half of a split keyboard. For example, when calling rgblight_sethsv_range(0, 0, 0, 0, RGBLED_NUM) in housekeeping_task_user, all of the LEDs on the master half turn off, but the slave half continues the base RGB animation. Animations on the keyboards work properly across the two halves (ex. RGBLIGHT_EFFECT_RAINBOW_SWIRL).

System Information

• Keyboard: BFO-9000
  • Revision (if applicable):
• Operating system: Windows 10 64-bit
• AVR GCC version: 8.4.0
• ARM GCC version: 8.4.0
• QMK Firmware version: 0.11.68
• Any keyboard related software installed?
  • [ ] AutoHotKey
  • [ ] Karabiner
  • [x] Other: None of the above, but I am trying to write my own Python scripts for sending commands to the keyboard via the virtual serial port (from VIRTSER_ENABLE). I can turn on and off the builtin RGB effects via this script, so I'm trying to implement control for specific LEDs as well from the PC.

Additional Context

The builtin animations all seem to work fine, it's just trying to define my own LED commands that's not working on the slave half.

[jtang9001]

After some reading of the source code, I think this is because the I2C transmission between master and slave does not include LED-level information, and only the high level information (mode, HSV, speed, enabled/disabled.) I will try to make a second transport method that adds LED level information.

[drashna]

What may be better is to have whatever you are trying to do run on both halves, and just send the data that is needed (layer state, mods, etc) over. This is a better solution in the long run, and more manageable. The only downside is that you'd have to flash both sides, each time.

[jtang9001]

I imagine I could have the virtual serial on the other half too, and send packets to that as well, but is it safe to then keep the split keyboard connected together via a TRRS/I2C connection? In particular I'm worried about connecting two USB power sources together (because the TRRS cable will connect the 5V's together and the GND's together.) It also seems a bit inelegant to have the two USB cables and the TRRS cable.

I will try to implement something myself, but of course if there's no interest in integrating this to QMK then that's fine too. If I were to make a second iteration of my keyboard then I guess I should use only one microcontroller and actually send the matrix pins over some cable to the main side.