I’m looking to make a couple small tweaks to the APA102 & SK9822 chipsets and noticed that they both have a writeLed() inline method: https://github.com/FastLED/FastLED/blob/03d12093a92ee2b64fabb03412aa0c3e4f6384dd/chipsets.h#L165
What’s up with that? The only other reference to writeLed() I can find is in the P9813 driver which does actually call it but the APA and SK chipsets do not.
Just wanted to confirm but those are just left over I assume and not used?
They’re vestigial - I replaced them when I started doing optimizations around packing data and interleaving scaling with filling in the spi registers.
ok, awesome, will remove as I make any updates. Couple other questions…
APA102 and SK9822 can actually use a combined protocol that will work for both (https://cpldcpu.com/2016/12/13/sk9822-a-clone-of-the-apa102/). I’ve implemented this in Python and it works great. Any objections to combining these in FastLED? Of course they’d still be callable as separate LED types for those used to that but the code path would be the same.
Also, because I would like to add on-chipset brightness control (see link again). On the APA102 this uses a 440Hz superimposed PWM, but on SK9822 it uses variable current control so much less flicker. It’s an easy update (just do 0xE0 + <5-bit-bright-val> instead of the data packet 0xFF first byte… but do you have any recommendations or preferences as to how to integrate that into the existing brightness control? Right now it looks like FastLED always handles that in software instead of passing it off to the hardware. But trying to avoid adding extra complexity.
https://cpldcpu.com/2016/12/13/sk9822-a-clone-of-the-apa102/
I never found a way that I was happy with mapping the global brightness to the apa102’s - which is why I didn’t.
The different brightness curves of the apa102 and and the sk9822 are one reason to keep them separate for now though, under the hood (and the possibility of eventually doing that is part of why I haven’t combined them yet).
Oh - also the apa102/sk9822 brightness control is not a good fit for FastLED’s color temperature/white balance adjustments (because that’s basically fine tuned brightness for each of r/g/b separately)
Hmmm… ok. So, my intent here is so that I can support the on chipset
brightness for these on the latest AllPixel firmware.
Good to know about the brightness curves though, I was unaware. In my case
it’s not really an issue as I do all the gamma correction outside of
FastLED.
So, I’m just trying to figure out if there’s an acceptable way for this to
be possible for my own uses 
Since all the brightness level stuff is
handled externally. I can certainly just fork FastLED for my needs but I’d
rather keep things kosher with upstream.
Fork away - my first plan when I start working on the library stuff is going to be finishing the rgbw/16-but support which is going to effectively rewrite everything anyway.
LOL… good to know! Probably best anyways as the AllPixel never really
used FastLED in the intended fashion All a little hacky. But now I know
enough how to write my own protocols that if I ever had to pull new work in
it probably wouldn’t be too hard. Thanks for the assessment 
Hi Adam, I’ve been experimenting with GBC on the APA and SK LEDs here, maybe it’s of some use to you:
Nice! Will definitely check that out Thanks!