tschundler
commented
4 months ago I think this does need some consideration, where should the swizzle of RGB->GBR / whatever yours are happen? It seems to me, it should be after smartleds.Write, so all pattern generation is simply RGB.
But maybe smartleds.write isn't the more useful common denominator. Rather a family of iterators for generating content, RGB8, RGBW8, RGB16, RGBW16, which all support Into traits for each other. And then swizzlers to convert them to component types. (eg BGR) and finally the output drivers to build eg WS28xx signals from there, which can work for RGB, BGR, RGBW, or APA10x signals, etc.
I have been tinkering with an sk6812 light strip (with about 500 lights) and also with ways to correctly address that.
The smart-leds-traits crate does provide for an RGBW type. However, the types like Gamma and Brightness specify an RGBW constraint.
In addition, sk6812 pulse ordering is R -> G -> B -> (W) instead of G -> R -> B for the ws2812.
In thinking about ways to support 4 channel, as well as different orderings. What we need is specialization :) . Since we don't have that, the only thing I can think of is to make traits that supply an iterator of iterators of values.
My thought is that we introduce a new trait called
Channelwhich was just an iterator over ComponentType. So, effectively, we'd be supplying the "column" iterators, then the write/gamma/brightness functions would collect their set of iterators, and then poll each one, in order, as it is processing the colors.One could also make a default implementation of the Color trait which produced a single iterator that just produces each ComponentType value, in order. So the existing implementations of write and friends don't have to change so much.
Thoughts?