I would characterize that as not supporting RGBW LEDs. My understanding of RGBW LEDs is that instead of 3 bytes of data, there is a 4th byte of data necessary for the white channel, and the white has its own separate LED. The SK6812RGBW seems to show the same timing as WS2812, so the SPI timing should work for either. My theory was that the configuration have the LED wing configured as 3 bytes or 4 bytes per pixel, and the number of pixels in the chain. That gives the firmware the number bytes needed to transmit the whole chain.
When updating the LEDs, a single fade command is supported. The fade command is as follows: board id (byte, normally 0x20 for STM32s), command (byte, 0x40), offset (2 bytes), num bytes to update (2 bytes), time of fade (number of ms, 2 bytes), data, crc8.
By setting the time of fade to 0 ms (0x0000), the changes will take affect immediately.
Assuming an rgb LED chain (3 bytes per pixel), updating the 3rd pixel to be black (all channels off) immediately would look like:
0x20 0x40 0x00 0x06 0x00 0x03 0x00 0x00 0x00 0x00 0x00 crc8
Assuming an rgb LED chain (3 bytes per pixel), updating the 4th pixel to all on immediately would look like:
0x20 0x40 0x00 0x09 0x00 0x03 0x00 0x00 0xff 0xff 0xff crc8
Assuming an rgb LED chain (3 bytes per pixel), updating the 5th pixel, green only channel to full on in 1 second would look like:
0x20 0x40 0x00 0x0d 0x00 0x01 0x03 0xe8 0xff crc8
Assuming an rgbw LED chain (4 bytes per pixel), updating 3rd pixel to black (all channels off) immediately would look like:
0x20 0x40 0x00 0x08 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 crc8
That's where the OPP firmware is going next. The goal is that this single command makes it very easy for MPF to update LEDs efficiently.