Give HUB75 Color Order Overrides

[troyhacks]

Not all HUB75 panels are RGB.

This just enables the standard color order stuff we already have in the bus system for HUB75 too.

Summary by CodeRabbit

• Bug Fixes

  • Fixed color-order initialization and per-pixel RGB remapping for HUB75 matrix displays so colors render correctly across all panel types.

• New Features

  • HUB75 matrix color-order settings are now preserved and configurable in the LED settings UI, and the Color Order control is shown for HUB75 types.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: e9b29bb9-902d-467e-9b47-0a30ddd09fdf

📥 Commits

Reviewing files that changed from the base of the PR and between 44d666c and 2aa05cb.

📒 Files selected for processing (1)

• wled00/data/settings_leds.htm

🚧 Files skipped from review as they are similar to previous changes (1)

• wled00/data/settings_leds.htm

---

📝 Walkthrough

Walkthrough

BusHub75Matrix now stores and exposes a per-instance color order and applies per-pixel RGB remapping when drawing to HUB75 panels. The LED settings UI was changed to show Color Order controls for HUB75 types and to set the per-output Color Order field for those types when LED type changes.

Changes

Cohort / File(s)	Summary
Hub75 runtime & API wled00/bus_manager.h, wled00/bus_manager.cpp	Added _colorOrder member and getColorOrder() override in BusHub75Matrix. Constructor assigns _colorOrder from bus config. show() remaps per-pixel RGB components according to _colorOrder before calling drawPixelRGB888 for both four-scan and non-four-scan paths.
UI: LED settings wled00/data/settings_leds.htm	When LED type changes with change=true, sets per-output Color Order field (CO{n}) to 1 for HUB75 types (t >= 100 && t < 110). Color Order control visibility is now only hidden for PWM/analog ranges (t in 83–95 or 40–47), not for HUB75 types.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I hopped through pixels, swapped red, green, blue,
A little order tweak — now every hue stays true.
From UI toggle to the panel's glowing show,
I nibble bugs and let the color rivers flow. 🎨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Give HUB75 Color Order Overrides' directly and clearly summarizes the main change: enabling color order configuration for HUB75 panels.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@wled00/data/settings_leds.htm`:
- Line 226: The color-order selector (CO) created in addLEDs() still defaults to
"GRB", so when you unhide CO via gId("co"+n).style.display for a HUB75 bus the
control remains set to GRB and will save incorrectly; update the logic so when
the bus type is HUB75 (the same condition that unhides CO in the code using
gId("co"+n)) you programmatically set the selector's value to the correct
default (e.g., "RGB") or derive its default from the bus type instead of leaving
it as the old GRB default; modify addLEDs() (or the code path that shows CO via
gId("co"+n)) to set gId("co"+n).value appropriately whenever the selector is
made visible for HUB75.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: d2615b08-8f58-4b9d-a91d-81fbf0d3d7df

📥 Commits

Reviewing files that changed from the base of the PR and between 50f507f and 44d666c.

📒 Files selected for processing (3)

• wled00/bus_manager.cpp
• wled00/bus_manager.h
• wled00/data/settings_leds.htm

[softhack007]

Hi @troyhacks, actually this is a very inefficient method to do color ordering on HUB75.
The simplest way - without adding new logic into the hot "pixel pusher" path - would be to swap RGB pins during driver init. Give me a few days, i'll cook something up.

[troyhacks]

Yeah, that was my thought too (and my usual method) - but this GTJD.

I didn't want to mess with re-initing the panel at the moment.

Both ideas may be valid? This is the quick way to get things correct, and then on reboot it could be done via pin swapping.

[softhack007]

Both ideas may be valid? This is the quick way to get things correct, and then on reboot it could be done via pin swapping

actually yes, both ideas are working. There is even a third way, by re-ordering RGB in setPixelColor, and reversing that in getPixelColor.

My concern is that the "hot path" of pushing pixels down to the driver should stay clear of any extra logic - we have less than 8ms for pushing the complete framebuffer, as we need to be faster than the "video scan beam" to avoid tearing.

I have an idea already - maybe we can still have both.