Ergodox Infinity LED sync issues

[belak]

I've gone through the process of trying this with a number of different configurations (Both with MASTER=right, left normal right with MASTER=right, etc) and it seems like the colors on the LED screens don't always sync in both directions. If I set the color from the left side (using a key on that side), both panels change color but if I set the color from the right side (using a key on that side) only the right panel changes color.

You can see that here: https://github.com/belak/ergodox-belak/blob/master/keymap.c#L159

[FromtonRouge]

I have the exact same issue with the following code : https://github.com/FromtonRouge/qmk_firmware/blob/master/keyboards/ergodox/keymaps/fromtonrouge/keymap.c#L968

[leshow]

Does qmk have support for the lcd's on the infinity now? I was under the impression it wasn't supported.

[kwkroll32]

I am able to change LCD visualization in both directions, where fn keys on the left change colors on the right half and vice versa. However, my master half always changes ~4 seconds before the slave half, including LED colors and content on the LCD display. I think there's a timer somewhere I need to reduce/refresh. Did you try holding the fn keys down to see if they eventually change on the other half?

I based this on a couple repos by ec1oud and SjB.

https://github.com/kwkroll32/qmk_firmware/blob/master/keyboards/ergodox/keymaps/karl/keymap.c#L639

[bswinnerton]

@leshow: you should be able to pull off LCD support with something like bswinnerton#1.

[bswinnerton]

However, my master half always changes ~4 seconds before the slave half, including LED colors and content on the LCD display.

I'm having the exact same problem. In some cases, the LED colors on the LCD won't change at all, but the text will.

[belak]

I've been digging through this code for the last few hours and I've got debug output working, but does anyone know if it's possible to get the debug output from the slave device?

[leshow]

@bswinnerton I've seen that same visualizer.c file on about 20 different branches and I use it myself. Honestly it doesn't work very well. The keyboard display will sometimes get messed up if it's been plugged in for hours and hours (the slave half) and there is a delay between the halves because the animation only seems to run on the master.

The LED colors however work fine, if you want to see that you can look at my changes over here https://github.com/leshow/qmk_firmware/blob/r2d2rogers/keyboards/ergodox/keymaps/r2d2rogers/visualizer.c

[MungFuSensei]

Has anyone made progress on this? I am having this issue as well. I know nothing about programming, so I spent like 6 hours last night tweaking anything I could find that was relating to timing. Tweaking the frame times in visualizer.c got the delay down to like 1-2s, but I can't get it any lower, and for some reason left master is slower than right master. Like others have said, there is the delay, and also the slave side has no animation.

It might be something in gfxconfig.h, but I have no clue where to start there.

[belak]

Poking around this code, there's a serial connection between the two halves (with a bunch of different data streams included). When there's an event (like a key press) on either side, it gets sent to the master which then tries to dispatch it where needed. Both halves are running the animations separately, so in order to display the same thing on both, the animation needs to be dispatched to the left half and started in around the same amount of time it takes to start the animation on the right side. As far as I can tell, the event is being dispatched almost immediately, so there may be something on the left side which isn't happening correctly.

[belak]

Also, if you want to try debugging this, I recommend starting with the visualizer.c sample (called visualizer_user.c I think) rather than one of the user-created visualizer code samples.

[MungFuSensei]

@belak I tried using the visualizer_user file, renaming it to just visualizer, and now the screens won't work at all. I have tried using different visualizer files, and they still don't work. I switched back to the kll firmware, and the screens work there. So I think the sample file changed another file that messed something up? However, even going to a fresh QMK clone and copying my keymap file over produced the same result. This is very odd.

EDIT: Ignore me, I'm dumb. Forgot to include VISUALIZER_ENABLE=yes when making.

[fredizzimo]

I'm sorry for the mess with the LCD and visualizer support. I should really have made the old visualizer stuff and everything else working before concentrating on the effect system stuff. Also I have personally still been using my tmk fork, so it has not been too critical for me.

But since this is so long overdue, I should probably look at this first and get the old visualizer working.

There should definitely not be a 4 second delay, except maybe at the startup. But once it's up and running both halves should be in sync, the communication should be instant. However, note that If there's some long running effect things can go out of sync after a while. Generally that's not a problem though as it should come back to sync as soon as another effect starts. This is a limitation of how the current visualizer works.

There was a screen corruption issue in the my TMK fork as well, but I thought that one was fixed, and QMK should also have that fix.

Edit:
I noticed that there's already a pull request open #1127, I will check out that first

[fredizzimo]

Just a small update to this.

I enabled the on my own keyboard, and there appears to be some kind of "frame rate" issue on the slave.

So instead of for example animating layer changes, it jumps through the animation, directly to the first frame. This doesn't happen on the master, so next I will try to figure out what's causing the visualizer to not get the proper CPU time needed on the slave.

The extreme delays of up to 4 seconds is probably also related to this, sometimes it could be even worse than what I'm seeing.

[kwkroll32]

I noticed the same. I didn't realize it was the first frame of the animation, but LEDs on the slave definitely flicker when switching layers. For example, if I switch layers during a "breathing" type of backlight animation, the slave half will stick at full brightness then cut to off, while the master undergoes a smooth gradient from lit to off. The choppiness and delay in the slave LCD is identical to LED backlighting.

[fredizzimo]

I did some more testing, at least the frame rate issue seems to be caused by some library code, or in the way I'm calling it. More specifically, the serial_link thread doesn't seem to wait at all, stealing all the CPU from the visualizer. The issue went away when I changed the priorities so that the visualizer has a higher priority than that. But that's not something I want to do as the serial link should be as fast as possible to reduce keyboard lag when typing.

I then downgraded the Chibios, Chbios-Contrib and uGfx libraries to the same versions as my TMK fork, and the issue went away using that too. I will try upgrading to the newest version next (probably tomorrow), otherwise I'll have to dig into their code and see what might have changed. I don't want to permanently downgrade the version, as uGFX wasn't fully compatible and I had to do some customization to make it work.

[fredizzimo]

Actually I did some mistakes in the testing above, the issue is not caused by the external libraries.

However I found the issue. The default rate of sending the matrix to the other side every millisecond is too high for QMK, leaving no CPU left for the visualizer. I have now increased it to 5ms which shouldn't really be a problem as the report is sent as soon as a key is pressed anyway, but in case the packet is corrupted or lost during the way over the link it needs to be re-sent and that's why there's a regular send every 5ms.

I suspect that some keymaps or enabled features are even heavier, and that's when you start to see those 4 second delays. TMK was likely somewhat lighter and things were fine.

The real issue here is that ChibiOS doesn't support DMA transfers for the Kinetis processors. So implementing that, for at least the UART and SPI for the LCD, would speed up things considerably and free up much more time for advanced LCD and LED effects.

Edit:
SPI, not I2C for the LCD. I2C is used for the LEDs though so that should also probably be using DMA.

[fredizzimo]

Good news, at least on my Ergodox, everything seems to work fine now. I even think I fixed the corruption issue, after reading the specifications for the eleventh time, I finally found out that I should select and unselect the SPI bus for each batch of commands that I do. This will keep the CPU and the LCD controller in SYNC. I also noticed that the SPI code actually do use DMA now, I had old information. So I also improved the speed a little bit by batching a few commands together instead of sending them one by one.

Before sending a pull request, I will make a good default visualizer, which emulates the Ergodox EZ LEDs, so that it displays something meaningful by default. But it's possible to override it per keymap to make something more targeted for a specific keymap. The ErgodoxEZ emulation is a little bit tricky to to, since the EZ has three LEDs, and the infinity only two LCD screens. Actually there's a fourth one on the EZ, the board LED, but almost no keymaps seems to use that, so I'll leave it out.

I was thinking of doing the following, if one LED is turned on display that color on the master, if two are turned on display the first on the left and the second on the right LCD screen. If three colors are enabled, then display the first two on the LCD screens, then have a second keyframe displaying the third color on both of the screens, and let it alternate between those two states. I was also considering using a different color for representing that, but the problem is that some keymaps also selects the brightness and that approach wouldn't work in that case. Do you have any other ideas?

BTW I think the matrix LEDs should work too, but I won't enable it, since I can't test it. It's easy for you to enable and use though.

[leshow]

Thank you @fredizzimo I'll look forward to that PR. I actually found the default KLL LED colours/animations to be really nice (the firmware that ships by default with the ergodox infinity now), and that's the only thing I miss from that firmware.

[fredizzimo]

I think the issue is fixed now.

The pull request is here

[leshow]

Sweet!

[FromtonRouge]

Thank you! I have added my visualizer.c file in my keymap and now it works, both screens are synched \o/

[DanielGGordon]

New ergodox user here - so what will I be able to do with QMK on my ergodox Infinity? Will the LCDs be able to display which layer I am on (and can the layers be separate for each hand?)

[belak]

I'm not sure if the LCDs can display different things... I don't believe that's possible under the current framework... but it should be possible to make each hand's layer change independently... you would just have to make each layer (in the keymap) only deal with keys on one hand and you'd enable each of the hand-layers independently. It can be done... but it might be a little weird.