Support more than 256 leds

[mateuszdrwal]

I made a split keyboard with 4 leds under each key (10 for the 2 2U keys) and the results are pretty spectacular. This sums up to 162 leds per half, or 324 leds on both. QMK currently uses a uint_8 in most places to iterate over leds, so this required some patches which I want to polish up and contribute back.

I'm not intimately familiar with the codebase or nuances of QMK, so it would be great with some guidance on the best way to implement it for this project. I assume RAM is enough of a concern for the AVR platform that replacing all relevant uint_8 with uint_16 would be problematic? Would a typedef uintX_t num_leds_t then be best setting the type to uint16_t if RGB_MATRIX_LED_COUNT > 255, and using that type everywhere instead? Anything else I should know before putting time into implementing this properly?

[drashna]

In general, yeah, AVR ram limitations are usually an issue.

I'm not sure of the best solution, but a typedef sounds like probably the best option here. There is a similar thing for the layer state bitmask, for instance.

Also, damn, that board looks spectacular

[getreuer]

That board is gorgeous!

Maybe the LED index type can be defined conditionally based on RGB_MATRIX_LED_COUNT? It would be nice if it works automatically without needing an additional configuration. Perhaps:

#if (RGB_MATRIX_LED_COUNT) <= 255
typedef uint8_t led_index_t;  // Continue using uint8_t by default.
#else
typedef uint_fast16_t led_index_t;  // If there are more than 255 LEDs.
#endif

bool SOME_EFFECT(effect_params_t* params) {
    LED_MATRIX_USE_LIMITS(led_min, led_max);
    for (led_index_t i = led_min; i < led_max; i++) {
       ...

[mateuszdrwal]

Yep, that's what I'm thinking. led_index_t is probably a better type name than what I came up with.

[christrotter]

I ran into this on my last board, but dang, your implementation of 'maxing out led count' is far more wondrous.