Fancy lightning on Infinity Ergodox?

[dsvensson]

Notice some animations have been added to the repo. Was hoping this could be enabled on my Infinity Ergodox as it sounds like it could be supported, but compilation fails at weird places.

Background: https://github.com/qmk/qmk_firmware/issues/1077

After just making something up for DRIVER_COUNT, DRIVER_LED_TOTAL, DRIVER_ADDR_1, and DRIVER_ADDR_2 I get compilation errors for PAL_MODE_STM32_ALTERNATE_OPENDRAIN, and if I make something up for that, I get an error about point_t being declared in both tmk_core/common/keyboard.c and gdisp.h.

Is it too farfetched to think that RGB_MATRIX_ENABLE would work on a single colored board like Infinity Ergodox? Looks like it's the same controller at least?

[fauxpark]

RGB Matrix would not work on the Infinity Ergodox, however there is a single-channel version called, unsurprisingly, LED Matrix. It's been a bit neglected compared to RGB Matrix; there are no animations defined and it doesn't yet support splits.

However, I've been working to bring it up to speed: https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed+in%3Atitle+%22led+matrix%22+author%3Afauxpark

I have it all done locally, with as many animations ported as made sense (some obviously don't work as well with a single colour), just splitting it up into more easily reviewed chunks.

[dsvensson]

@fauxpark Perhaps just a git commit -a -m "crap" and I could help testing it out? Rough edges are not a problem. What's the issue with splits? Not being able to initiate it on both halves, or not being able to see the splits as one display, but independent animations would work?

[drashna]

the hub or gh utility can be used to easily test out these changes. hub pr checkout ### or hub merge --squash <url> are both ways to do this.

As for splits, it's because the code, as is, assumes that the master side can communicate with both ISSI controllers. However, that's not how the ergodox infinity is set up. Each half is connected to a single ISSI controller, and that half controls the LED matrix for it's side.
So there is a lot of code that would need to be written to handle this case.

[dsvensson]

@drashna sure, but that doesn't help if parts of @fauxpark code is not pushed :) The PRs he linked are all except one merged, but "I have it all done locally" was mentioned.

As for the split part, that was what I was getting at wrt the halves being independent or not. Would it at all be possible to start an animation (the same) on both halves? Such as randomized fading glow some time after a key was last pressed? Such an animation would not need to be coordinated across both halves as one display, it could for all intents and purposes be mirrored. Is that not possible either, that only the master half would be able to start an animation for that half alone?

[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.

[fauxpark]

@dsvensson Just FYI, I finished my LED matrix work and https://github.com/qmk/qmk_firmware/pull/9657 has been merged into develop - I think that should resolve this issue :)

[dsvensson]

Cool, and also https://github.com/qmk/qmk_firmware/pull/12845 to get the LEDs in the halves synced.... I'll try out latest tonight.

update: Tonight turned out to be a couple of days later. Rebased, built and ready to flash, tonight.

[dsvensson]

Success! Thanks for your awesome work @fauxpark and @firetech ... both halves now breathe in sync after timeout.

Slightly off-topic, unfortunately only my master half wakes up, but at least on input from any half. Is perhaps process_record_user(...) only executed on the master half?

My current strategy for idle timeout is:

#define IDLE_TIMEOUT 30000
static uint32_t idle_timer = 0;

bool process_record_user(uint16_t keycode, keyrecord_t *record) {
    idle_timer = timer_read32();

    if (led_matrix_get_mode() != LED_MATRIX_SOLID) {
        led_matrix_mode_noeeprom(LED_MATRIX_SOLID);
    }
    ...
}

void matrix_scan_user(void) {
    if (timer_elapsed32(idle_timer) > IDLE_TIMEOUT && led_matrix_get_mode() != LED_MATRIX_BREATHING) {
        led_matrix_mode_noeeprom(LED_MATRIX_BREATHING);
    }                                                                                                                                                       
    ...
}

Seem to recall some talk about syncing data between halves.u

[firetech]

There is a built-in define for idle timeout of LED Matrix (EDIT: that turns them off, not switches to breathing like you're doing). Not sure if that works on Infinity Ergodox, though. I'm also quite sure process_record_user is only executed on the master half, yes.

The main issue is that Infinity Ergodox is the only keyboard using the Serial Link system for communication between halves, which means basically nobody is keeping that up to date with new features. I've got my personal Infinity Ergodox running fine with the split_common system instead, and intend to make a PR of that after #13165 has been merged (too many conflicts otherwise). My branch for this is at https://github.com/firetech/qmk_firmware/tree/ergodox_infinity_split_common if you're interested.

EDIT: fauxpark merged #13165 almost immediately after I posted this comment, so the split_common PR is here: #13481 😄

[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.

[stale[bot]]

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know.