[FeatureRequest]: Configurable order of color channels for LED data

[FelixJ-RB]

Is your feature request related to a problem? Please describe.

Some LED strips have different color channel order than RGB.

For example we have COB strips with WS2811 chips that need data GRB order.

Describe the solution you propose.

It would be great if M950 would accept an O(rder) parameter, defining the order of the color channels on the data line.

Describe alternatives you've considered

We currently use a M150.1 macro that does the remapping in g-code.

I would expect a simple re-mapping table in SW to perform much better than this, and it would remove the need for a separately maintained macro.

Provide any additional context or information.

[dc42]

We already have a K parameter to specify the colour order, however this is currently supported only for DotStar LED strips. The required work would be:

1. In both RRF and D3E, move the code to parse the K parameter and the storage of the colour order from DotStarLedStrip to LocalLedStrip. We may need different default values for the two strip types, in which case we can pass the default order as a parameter to the LocalLedStrip constructor.
2. Do the remapping in class LocalLedStrip for both LED strip types.

Question: for RGBW Neopixel strips, can we assume that W must always be sent last?

[FelixJ-RB]

Oh, I read over the K-Parameter in the docs :-/ sorry!

Unfortunately I do not have RGBW type strips at hand right now, but looking at the NeoPixelBus Feature for RGBW 6 out of 7 types have the W-channel in the last position and the 7th has it in first. -> https://github.com/Makuna/NeoPixelBus/blob/master/src/internal/features/NeoRgbwFeatures.h

[dc42]

Implemented K parameter for Neopixel LEDs on main and expansion boards. For RGBW Neopixels the W value is always sent last.