[Feature Request] RGB_MATRIX feature for split keyboards

[tyalie]

As of now split keyboards don't support rgb_matrix out of the box. The nature of the problem lies in the asynchron internal timers of both halves, the disabled keypress evaluation on the slave side, ...

Making it work seamlessly is the goal of the current repo, but there're a few problems to solve first.

Feature Request Type

• [x] Core functionality
• [ ] Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
• [ ] Alteration (enhancement/optimization) of existing feature(s)
• [x] New behavior

Description

As mentioned before rgb matrix doesn't work together with split keyboards. There're some forks (#5998 and an iteration on that: #9613) that seem promising, but aren't perfect either. Major problems that need to be fixed first are:

• [ ] how are rgb matrix information transferred

  • both #5998 and #9613 came to the same conclusion, that sending all rgb data to the slave side, is not feasible when using a serial connection. The data rates too slow for that on serial and it as such can introduce a host of other problems like lags, ... As such both concepts gave the slave a render job, which only works synced, if both keyboards have the same firmware

• [ ] synchronization between master and slave timer (see #9665)

  • this was a major point in both #5998 and #9613
  • even though the solution works, extra care needs to be taken when using LT modifier. The quote below from #9613 describes the situation:

    a interactive effect triggered from the slave takes longer to get to the master side, than when an effect that is triggered on the master is transferred to the slave. But this effect is for me only visible, when LT(_LOWER, KC_BSPC) was used. (an LT modifier on master side doesn't seem to be so problematic)

• [ ] how is it guaranteed that both slave and master are in the same state

  • in #5998 both halves were responsible to interpret the key codes correctly. As there was no rgb matrix state sync between both halves, they could get out of sync pretty fast (especially when one half is operated without the other one attached)
  • in #9613 the approach was much different. All logic regarding matrix state selection was responsibility of the master and it only transferred any config changes to the slave. The way here is very similar to the sync implemented in rgblighting.
  • Problems can occur, when packages are incorrectly send and states cannot be synchronized accordingly (which can happen surprisingly often)

• [ ] reactive rgb matrix effects on slave side

  • this would require slave side key evaluation, which can come with a host of other problems. Those include evaluation of RESET, change of rgb matrix states and async behaviour accordingly, ...
  • One solution for it would be to give the slave an empty keymaps with only KC_NO (or all access to it returns KC_NO). This approach was taken in #9613. But this has the side effect, that the slave still has no idea what layer the keyboard is currently on. A component that could be implemented easily, depending on the approach taken

• [ ] processing rgb_matrix_indicator_user()

  • As RGB Matrix doesn't limit itself on only indicating layers, but instead uses the function rgb_matrix_indicator_user() that is run each cycle and cull pull information to set the color of single keys from arbitrary places a simple indicator, which layer is used might not be enough.

[tyalie]

Suggestions are welcome

[tzarc]

Probably need layer state sync too, in order to deal with lighting layers? (Is that RGBLIGHT-only?)

[tyalie]

I haven't really looked into the matter on the RGB Matrix side, but I'm not even sure RGB Matrix has something like that without some hacks. At least the rgb_matrix.h doesn't mention anything to my knowledge

Probably what #717 was for.

[sigprof]

Probably need layer state sync too, in order to deal with lighting layers? (Is that RGBLIGHT-only?)

Yes, lighting layers are currently implemented only in the rgblight code, not in rgbmatrix; and the state of rgblight layers is already synced, so they technically should not need anything more.

Actually there might be some conflicts if we attempt to sync the layer state to the slave side (which would presumably call layer_state_set_user() to update various kinds of indicators) and at the same time send the rgblight layer state there directly.

The RGB Matrix code, on the other hand, has rgb_matrix_indicators_user(), which works in a completely different way (it can pull information for various places to update the LED state), and it would need layer state sync if the user wants some LEDs to show the layer state.

[tyalie]

Hmh. I haven't thought about that. But rgb_matrix_indicator_user() could be very ugly to implement. I'll add it to the list.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

[drashna]

Removing the "in progress" tag, so that this can be closed.

develop (as of May 25th) has everything in place for this to work, now. And in a week, the code will hit master. (as well as the removal of the "legacy" corne revision)

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.