Pixels in reverse order per-chip vs datasheet/silkscreen

[WolfWings]

So because the driver assigns channels in buffer-order it ends up assigning pixel[0] to the OUT?3 pins, and pixel[3] is actually the OUT?0 pins, I.E. pixel[0] = ( 0.5, 0.0, 0.0 ) sets OUTR3 to ~50% PWM, not OUTR0.

Looking over the code this could be fixed in one of two ways, or the documentation updated as a sort of 'third' way to fix things without breaking backwards compatibility with any existing code.

---

First option is by making a change just in _init_lookuptable to match the datasheet/silkscreen channel ordering...

    def _init_lookuptable(self) -> None:
        for channel_index in range(self.channel_count):
            chip_index = channel_index // 12
            pixel_index = ( channel_index // COLORS_PER_PIXEL ) % PIXEL_PER_CHIP
            color_index = channel_index % COLORS_PER_PIXEL
            buffer_index  = ( _CHIP_BUFFER_BYTE_COUNT // _BUFFER_BYTES_PER_COLOR) * chip_index
            buffer_index += ( PIXEL_PER_CHIP - 1 - pixel_index ) * COLORS_PER_PIXEL
            buffer_index += color_index
            buffer_index *= _BUFFER_BYTES_PER_COLOR
            buffer_index += _CHIP_BUFFER_HEADER_BYTE_COUNT
            self._buffer_index_lookuptable.append(buffer_index)

...which would also make 'channel' access fill R0, G0, B0, R1, G1, B1, R2, G2, B2, R3, G3, B3 in order instead of also following protocol-order.

---

Second option is updating all of the set_pixel_* functions that actually touch self._buffer[] to change how the pixel_start is calculated...

pixel_start  = ( ( pixel_index // PIXEL_PER_CHIP ) * PIXEL_PER_CHIP )
pixel_start += ( ( PIXEL_PER_CHIP - 1 ) - ( pixel_index % PIXEL_PER_CHIP ) )
pixel_start *= COLORS_PER_PIXEL

---

The third option to purely document the reversal of per-chip channel numbering I'm unsure how best to word that so no example for that, and due to the two possible fixes I felt better to open an issue first to discuss instead of just a pull request.