Fix RGB heatmap to use XY positions and use correct led limits.

[daskygit]

Description

Tested on a split keyboard and board with a duplex matrix and it behaves much better, no more trigger incorrect locations. The effect is slightly different visually compared with the old one. I've not tested on AVR, hopefully not too much impact.

There's a define RGB_MATRIX_TYPING_HEATMAP_SPREAD that can be changed to increase the area of effect.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• Fixes [Bug] RGB_MATRIX_TYPING_HEATMAP lights up wrong keys #14041

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• 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).

[filterpaper]

Tested this on boardsource/technik_o and crkbd/rev1 running AVR controllers. There were no impact on typing performance and heatmap spread displayed correctly on the split matrix without any "bleeding" into incorrect rows or columns.

[drashna]

Tested and works better.

[daskygit]

Did a couple of small updates, noticed the effect was triggering on both key down and key up.

[daskygit]

Thanks, I'll update the docs with the added configuration options before it's merged.

[filterpaper]

Fixes #14041

[RagingCactus]

@daskygit @drashna I'm trying to experiment with this in my firmware. I hope you don't mind me asking as to me it seems related to this change and looks like a potential issue to me: How does this treat keys with no LED ? Wouldn't NO_LED entries in matrix_co mess up the dereferencing in led_point_t? I'm by no means versed in QMK, but it looks to me like NO_LED keys would trigger access to g_led_config.point[255], which would be nonsense.

To me it looks like we would need to do one of two things:

1. Be be able to define LED indexes that are not really LEDs (and get skipped for the driver code) andthus get proper distance calculation even for keys without LEDs (would be cool, but needs changes for all effects and in the core LED matrix system)
2. Skip keys that are defined as NO_LED or have an invalid index altogether for this effect.

[daskygit]

Thanks for spotting this, I think option 2 is likely going to be the way forward.

It could revert to the old behaviour if there's no led at the position but I'm now wondering if this should just be a separate effect entirely.

[daskygit]

@RagingCactus I've opened PR #17488 to address this, thanks again.