rgb_led_ws281x: support more colour component orders (wire, and text)
commit17b2579a517489ce06756943529986921e194ef9
authorGerhard Sittig <gerhard.sittig@gmx.net>
Sat, 29 Jul 2023 14:59:43 +0000 (29 16:59 +0200)
committerGerhard Sittig <gerhard.sittig@gmx.net>
Sat, 29 Jul 2023 19:29:11 +0000 (29 21:29 +0200)
treeceeaeb0b2f47d635ad01b2c64960edade1b89d49
parent5e8090d7d30fb0915fc1b54f3ec098c69a417745
rgb_led_ws281x: support more colour component orders (wire, and text)

The 'type' option was not good enough. Replace it by 'wireorder' (order
of colour components on the wire, depends on the RGB LED chip type), and
'textorder' (presentation to users in annotations).

Support many more layouts of colour components on the wire. Cover all
permutations of R, G, and B. Support a few RGB plus W layouts that are
known to be in use. Adding more is just a matter of adding more choices
in the option, the implementation transparently follows.

Support a few text orders: Reflect the very order of bits on the wire.
Automatic support for RGB with optional White, or fixed RGB or RGB-W
variants (all are users' choices, default remains "RGB" for backwards
compatibility). Support arbitrary combinations of wire order and text
order in emitted annotations.

Keep support for the weird RGWB text format, which the previous decoder
implementation used for "all" RGBW types, and which is referenced by
existing test cases. It is uncertain which chip type is supposed to
generate this specific RGBW traffic. It is as uncertain why this text
order was chosen, which neither is the human readable RGBW format nor
matches the wire order. The previous implementation was introduced in
commit 47ff9910f7e1, but neither commented nor referenced literature or
external sources nor did the commit message contain any clues.

This current implementation needs more tests and reviews, but lends
itself better to maintenance, fixes and enhancements.
decoders/rgb_led_ws281x/pd.py