Was reading through the protocol implementation and had a question about the data type constants.
The Question
TYPE_RGBA_8BIT is set to 0x0C (0b00001100). Based on the DDP spec's encoding:
TTT: 001=RGB/RGBA, 010=HSL, 011=HSV, 100=RGBW
SSS: 000=default, 001=4-bit, 010=5-bit, 011=8-bit, 100=16-bit
0x0C decodes to TTT=001, SSS=100. The SSS field 100 means 16-bit according to the comment, not 8-bit. So the constant name says "RGBA_8BIT" but the encoding says 16-bit channel depth.
For comparison, TYPE_RGB_8BIT = 0x0B decodes to TTT=001, SSS=011, which correctly maps to 8-bit.
Question
Is 0x0C intentional for RGBW 8-bit (which would be TTT=100, SSS=011 = 0x23), or is it meant to be RGB with 16-bit channels? The WLED source or the ddp-rs crate might be good cross-references.
This might be fine in practice since WLED may ignore the type byte entirely, but it could cause issues with stricter DDP receivers.
Was reading through the protocol implementation and had a question about the data type constants.
The Question
TYPE_RGBA_8BITis set to0x0C(0b00001100). Based on the DDP spec's encoding:0x0Cdecodes to TTT=001, SSS=100. The SSS field100means 16-bit according to the comment, not 8-bit. So the constant name says "RGBA_8BIT" but the encoding says 16-bit channel depth.For comparison,
TYPE_RGB_8BIT = 0x0Bdecodes to TTT=001, SSS=011, which correctly maps to 8-bit.Question
Is
0x0Cintentional for RGBW 8-bit (which would be TTT=100, SSS=011 =0x23), or is it meant to be RGB with 16-bit channels? The WLED source or the ddp-rs crate might be good cross-references.This might be fine in practice since WLED may ignore the type byte entirely, but it could cause issues with stricter DDP receivers.