RGB Matrix Support for Split Keyboards #9613

tyalie · 2020-07-01T13:59:22Z

This is an advancement from #5998
The idea is to implement the rgb matrix module for split keyboards, as it is currently missing.

Description

This is some basics to get RGB matrix support onto split keyboards. The main change of idea between this and #5998
is, that this feature line does not enable keyboard evaluation on the slave side, but instead the config is always synced from master to slave only if changes occur. (very similar to how the RGB lighting module works).
As such both keyboards cannot get out of sync, has it can happen on #5998.

For interactive animations, the state of the master is transferred to slave, but only rgb matrix specific functions for keyboard evaluation are triggered.

rgb matrix config is synced between both halves
timer.c is now sync'd between halves
Small changes to RGB Matrix to know what indexes apply to which half.
introduction of Lily58l keyboard as it is the one I'm working with (see https://github.com/BenRoe/qmk_firmware/tree/Lily58L as he's the original author)
"fixed" bug, where Elite-C flash failed, even though it worked. Probably my fault

Still to do

suspend isn't synced
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)
i2c testers as I can only test it with a serial connection
As of now timer.c is synced with an static offset to account for transfer delay. If issues occur it might be more plausible to implement a real timer sync protocol similar to Cristian's Algorithm
Split common also syncs master half matrix to slave, this allows slave to know the state of the keyboard
- transfer of keyboard state to rgb_matrix on slave side
doesn't compile with make all as definitions from sync_timer weren't found

Known issues

LT(layer, kc) with KC_CAPS causes reactive animation stutter. This is because it has an inline wait_ms(200). Not much can be done to improve this situation as it hard locks all processing of the keyboard. (maybe. Didn't test it)

Types of Changes

Issues Fixed or Closed by This PR

a lot

Checklist

My code follows the code style of this project.
My change requires a change to the documentation.
I have updated the documentation accordingly.
I have read the CONTRIBUTING document.
I have added tests to cover my changes.
I have tested the changes and verified that they work and don't break anything (as well as I can manage).

Update readme.md

* Initial work for consolidation of board files and default ChibiOS configs. * Migrate F401/F411 black pills for testing. * Add early init bootloader jump flag. * Add support for I2C in order to use i2c_scanner keymap. * Add F401/F411 HSE bypass to get things booting. * Exempt "hooked" ChibiOS conf files from updater script. * Fix up ordering for bootloader_defs file check. * Match previous $(KEYBOARD_PATHS) value for Proton-C, updated for all board configs.

… inline functions (qmk#9055)

XScorpion2 · 2020-07-01T14:20:24Z

Good first start, but there is a reason why the slave half needs to enable keyboard evaluation which is reactive rgb matrix animations. With out that hook, the reactive effects will not work, and I don't see anything in this PR to improve that.

tyalie · 2020-07-01T14:24:58Z

I'll sync the states and directly tap into rgb_matrix, circumventing all other methods that are normally called

Working on that right now

XScorpion2 · 2020-07-01T14:31:02Z

Thanks for taking this over. RL has been a major issue lately for me.

tyalie · 2020-07-01T14:34:42Z

You're welcome. I'm happy to take this over. First mayor contribution to an OS project for me.

I'm also really lucky that the whole situation rn hasn't affected me really at all. Wishing you the best!

tyalie · 2020-07-01T15:50:48Z

Works now, but I'm unhappy with the solution, as keypress evaluation is turned on.
This would create more problems, the more features qmk gets. Because now everytime somebody introduces a feature like RESET, one would need to create a new special case for that when using split keyboards.

A solution would be to make extensive use of c macros to remove all keypress evaluations that are unwanted.
Another solution would be to mirror the matrix scanning code from keyboard_task and call rgb_matrix_process_keycode there directly.

Both solutions are very unsatisfying.

rhruiz · 2020-07-01T16:00:52Z

common split code already has a check for RESET. Keypress evaluation on the slave side has a nice benefit of allowing things like making the slave OLED react to layer change and keypresses (this works in #5998)

tyalie · 2020-07-01T17:39:22Z

But RESET is not the only problem. As for now the slave side also does evaluation of RGB MATRIX commands. That is a very dirty approach especially, since the slave side config is overwritten in the next frame. Using EEPROM cycles, ...

But to my understanding #5998 has a lot bugs, because of slave side keyboard evaluation.

tyalie · 2020-07-01T18:11:21Z

Thanks to @sigprof I found a solution that works nicely. Sadly slave still can't show the current layer information

tyalie · 2020-07-01T19:49:25Z

It's now working as expected. There are only some major problems with the design and how future proof it might be.

drashna · 2020-07-05T04:04:36Z

But to my understanding #5998 has a lot bugs, because of slave side keyboard evaluation.

It's less of that. But it's a lot of changes.

Additionally it's missing some things like state syncing, so it's always sending the matrix code.

Breaking up the PR into chunks (like the sync timers) would make it easier to get merged in, as it would be easier to review, which would make it faster to get in.

tyalie · 2020-07-06T14:23:21Z

Okay. Didn't opened an issue for the sync timer yet, if people wanted to suggest a radically different way for this.

EDIT: Issue is open. See #9665.

tzarc · 2020-07-16T12:47:27Z

Looks like we're going to need a rebase on top of develop -- lots of irrelevant changes here.

tyalie · 2020-07-18T22:54:06Z

Whatya mean? My idea honestly was to do #9665 first from a clean slate on (develop branch). I know what to change and it isn't much. My troubles are:
a) I'd like some feedback on it before delving into it 😅
b) I've exams and other time sensitive stuff in the next 1½ months (after that I'm fine)

KarlK90 · 2020-07-22T22:51:05Z

I am running your code successfully on my split keyboard. Communication is via serial link on an stm32f103. Please let me know if I can help testing the changes. 🙂

tzarc · 2020-07-22T23:02:32Z

Whatya mean? My idea honestly was to do #9665 first from a clean slate on (develop branch). I know what to change and it isn't much. My troubles are:
a) I'd like some feedback on it before delving into it 😅
b) I've exams and other time sensitive stuff in the next 1½ months (after that I'm fine)

Yeah that's fine - it's more that in this PR's files list above, it's got tons of changes from the branch which isn't part of your PR.
Rebasing the changes to the top of develop will make it so that there's only the appropriate changes here.

But... if you're going to refactor with a clean slate, then I'll mark this as "on hold" until #9665 and any other prerequisites are sorted.

EDIT: Scratch that, "awaiting pr" instead.

robhaswell · 2020-10-01T16:12:41Z

I can confirm this is working great with my Lily58L.

Also I noticed that this branch includes Lily58L support, which is strictly beyond the scope of this branch. I will submit a PR for basic Lily58L support with RGBLIGHT, at least then the matrix modifications in this branch for the keyboard will be relevant.

XScorpion2 · 2020-11-28T18:50:46Z

Should be closed for the updated pr: #11055

noroadsleft and others added 10 commits June 19, 2020 21:31

Branch point for 2020 Aug 29 Breaking Change

4aa5fa8

Update readme.md

Remove iWRAP protocol (qmk#9284)

b2d24ea

Various tidyups for USB descriptor code (qmk#9005)

a7614ce

Convert CONSUMER2BLUEFRUIT() and CONSUMER2RN42() macros to static…

da634e9

… inline functions (qmk#9055)

Attempt to fix CI for non-master branches. (qmk#9308)

a81b027

Additional cleanups for V-USB code (qmk#9310)

3e3e7d0

Remove inclusion of adafruit_ble.h from ssd1306.c (qmk#9355)

1cfeef1

Don't compile outputselect.c if Bluetooth is disabled (qmk#9356)

d3c256d

qmk cformat on develop (qmk#9501)

3f6be07

tyalie changed the title ~~Rgb matrix support~~ RGB Matrix Support for Split Keyboards Jul 1, 2020

This was referenced Jul 1, 2020

Split Keyboard RGB Matrix Support #5998

Closed

[Feature Request] Provide RGBLED_SPLIT like functionality for RGB_MATRIX #9570

Closed

tzarc changed the base branch from master to develop July 1, 2020 20:13

tyalie mentioned this pull request Jul 1, 2020

[Feature Request] RGB_MATRIX feature for split keyboards #9619

Closed

9 tasks

tzarc changed the base branch from develop to master July 1, 2020 20:46

tzarc requested a review from a team July 1, 2020 20:46

tzarc added breaking_change Changes that need to wait for a version increment core enhancement feature labels Jul 1, 2020

readded encoder for rgb config

dd472d4

tyalie mentioned this pull request Jul 6, 2020

[Feature Request] Timers between two halves of a split keyboard are not synced #9665

Closed

4 tasks

noroadsleft force-pushed the develop branch from 59cd6ca to d35faa5 Compare July 10, 2020 20:32

noroadsleft force-pushed the develop branch from 415f088 to 14610ee Compare July 18, 2020 07:31

tzarc added the awaiting_pr Relies on another PR to be merged first label Jul 22, 2020

noroadsleft force-pushed the develop branch 2 times, most recently from 550bb6a to 9d827f9 Compare July 31, 2020 19:44

noroadsleft force-pushed the develop branch from 7499550 to 8b7b3ce Compare August 11, 2020 08:24

noroadsleft force-pushed the develop branch 2 times, most recently from 1d4c0cd to 65c27a3 Compare August 29, 2020 21:41

noroadsleft force-pushed the develop branch from 3a8e1b8 to a1b96ba Compare September 4, 2020 22:03

noroadsleft force-pushed the develop branch from a1b96ba to 3430907 Compare September 12, 2020 11:46

skullydazed force-pushed the develop branch from fa8cf59 to cce70f1 Compare October 18, 2020 21:10

noroadsleft force-pushed the develop branch from 5720202 to dcefc1a Compare October 23, 2020 22:37

skullydazed force-pushed the develop branch from db745a9 to 68fc044 Compare October 28, 2020 02:16

noroadsleft force-pushed the develop branch from 92ca6b9 to c3221d4 Compare October 30, 2020 20:23

noroadsleft closed this Nov 28, 2020

noroadsleft deleted the branch qmk:develop November 28, 2020 20:02

tzarc reopened this Nov 28, 2020

github-actions bot added cli qmk cli command python labels Nov 28, 2020

fauxpark closed this Nov 29, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RGB Matrix Support for Split Keyboards #9613

RGB Matrix Support for Split Keyboards #9613

tyalie commented Jul 1, 2020 •

edited

Loading

XScorpion2 commented Jul 1, 2020

tyalie commented Jul 1, 2020 •

edited

Loading

XScorpion2 commented Jul 1, 2020

tyalie commented Jul 1, 2020

tyalie commented Jul 1, 2020 •

edited

Loading

rhruiz commented Jul 1, 2020

tyalie commented Jul 1, 2020 •

edited

Loading

tyalie commented Jul 1, 2020

tyalie commented Jul 1, 2020

drashna commented Jul 5, 2020

tyalie commented Jul 6, 2020 •

edited

Loading

tzarc commented Jul 16, 2020

tyalie commented Jul 18, 2020

KarlK90 commented Jul 22, 2020

tzarc commented Jul 22, 2020 •

edited

Loading

robhaswell commented Oct 1, 2020

XScorpion2 commented Nov 28, 2020

RGB Matrix Support for Split Keyboards #9613

RGB Matrix Support for Split Keyboards #9613

Conversation

tyalie commented Jul 1, 2020 • edited Loading

Description

Still to do

Known issues

Types of Changes

Issues Fixed or Closed by This PR

Checklist

XScorpion2 commented Jul 1, 2020

tyalie commented Jul 1, 2020 • edited Loading

XScorpion2 commented Jul 1, 2020

tyalie commented Jul 1, 2020

tyalie commented Jul 1, 2020 • edited Loading

rhruiz commented Jul 1, 2020

tyalie commented Jul 1, 2020 • edited Loading

tyalie commented Jul 1, 2020

tyalie commented Jul 1, 2020

drashna commented Jul 5, 2020

tyalie commented Jul 6, 2020 • edited Loading

tzarc commented Jul 16, 2020

tyalie commented Jul 18, 2020

KarlK90 commented Jul 22, 2020

tzarc commented Jul 22, 2020 • edited Loading

robhaswell commented Oct 1, 2020

XScorpion2 commented Nov 28, 2020

tyalie commented Jul 1, 2020 •

edited

Loading

tyalie commented Jul 1, 2020 •

edited

Loading

tyalie commented Jul 1, 2020 •

edited

Loading

tyalie commented Jul 1, 2020 •

edited

Loading

tyalie commented Jul 6, 2020 •

edited

Loading

tzarc commented Jul 22, 2020 •

edited

Loading