[Bug] Unicorne - Column mismatch on RGB matrix animations

[Auretus]

Describe the Bug

KB model: Boardsource Unicorne
OS: Windows 11 23H2
Software version: QMK latest, pulled from Github @ 2024-03-05 18:29 EST
Build environment: QMK Toolbox

I'm seeing a weird thing happen with my Unicorne (Corne variant running on RPI2040), and I'm not sure what's causing it.
When I enable any of the RGB matrix patterns, they mostly work as expected--mostly. The bit that's off: the pattern acts like the last column on the right-hand board is located on the far left of my left-hand board.

As with many split keyboards, the matrix is defined with the two halves on separate row numbers, to avoid confusion. Left hand uses rows 0-3, right hand uses rows 4-7

This happens on any animated RGB matrix effect, though I'll use the RGB_BAND_VAL effect as an example for clarity's sake.

What I expect to see: a band of color going from left to right column by column, like this:

0:0 -> 0:1 -> 0:2 -> 0:3 -> 0:4 -> 0:5 -> 4:0 -> 4:1 -> 4:2 -> 4:3 -> 4:4 -> 4:5
1:0 -> 1:1 -> 1:2 -> 1:3 -> 1:4 -> 1:5 -> 5:0 -> 5:1 -> 5:2 -> 5:3 -> 5:4 -> 5:5
2:0 -> 2:1 -> 2:2 -> 2:3 -> 2:4 -> 2:5 -> 6:0 -> 6:1 -> 6:2 -> 6:3 -> 6:4 -> 6:5
                     3:3 -> 3:4 -> 3:5 -> 7:0 -> 7:1 -> 7:2

What I actually see:

4:5 -> 0:0 -> 0:1 -> 0:2 -> 0:3 -> 0:4 -> 0:5 -> 4:0 -> 4:1 -> 4:2 -> 4:3 -> 4:4
5:5 -> 1:0 -> 1:1 -> 1:2 -> 1:3 -> 1:4 -> 1:5 -> 5:0 -> 5:1 -> 5:2 -> 5:3 -> 5:4
6:5 -> 2:0 -> 2:1 -> 2:2 -> 2:3 -> 2:4 -> 2:5 -> 6:0 -> 6:1 -> 6:2 -> 6:3 -> 6:4
                            3:3 -> 3:4 -> 3:5 -> 7:0 -> 7:1 -> 7:2

The screwy thing is that reactive layouts like TYPING_HEATMAP and the SOLID_REACTIVE set trigger their waves at the correct key location, while still displaying this weird wrapped-around boundary behavior for propagation.

Furthermore, the static ALPHA_MODS pattern doesn't seem to do this, it correctly shows the thumb keys and the outermost columns (column 0 on left board, column 5 on right board) in a different color as expected. Every other pattern behaves this way though, AFAICT. (Hard to tell with the patterns like CYCLE_ALL and BREATHING that play the same animation on every key in sync.)

Keyboard Used

boardsource/unicorne

Link to product page (if applicable)

https://www.boardsource.xyz/products/unicorne-LP

Operating System

Windows 11 23H2

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: F:/Projects/qmk_firmware
Ψ Detected Windows 10 (10.0.22631).
Ψ QMK MSYS version: 1.7.2
Ψ Userspace enabled: False
Ψ Git branch: melicorne
Ψ Repo version: 0.24.2
Ψ - Latest melicorne: 2024-03-05 16:59:09 +0000 (4443fa8a32) -- Attempt to fix changed files on CI workflow (#23205)
Ψ - Latest upstream/master: 2023-11-17 01:48:24 +0800 (a6521b8521) -- [Doc] Improve converter references (#21801)
Ψ - Latest upstream/develop: None
Ψ - Common ancestor with upstream/master: 2023-11-17 01:48:24 +0800 (a6521b8521) -- [Doc] Improve converter references (#21801)
Ψ - Common ancestor with upstream/develop: None
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 10.1.0
Ψ Found avr-gcc version 8.5.0
Ψ Found avrdude version 7.0
Ψ Found dfu-programmer version 0.7.2
Ψ Found dfu-util version 0.11
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2023-04-15 13:48:04 +0000 --  (11edb1610)
Ψ - lib/chibios-contrib: 2023-11-27 18:15:44 +0100 --  (9d7a7f90)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

WinCompose, Microsoft PowerToys Preview

Additional Context

Tested this with both my custom keymap/ruleset and the default, and the same behavior obtains in both places. EEPROM reset and reflash obtains similar results.

[Auretus]

I checked the info.json for this board, and the matrix values were basically copy-pasted from the one in crkbd/rev1. The formatting is a bit screwy, but after parsing what was supposed to go where in terms of X-Y coordinates, nothing seemed to be out of place there.