My preference is to, in the short-term, change the default timing to work with 800KHz Neopixels. I understand that this would be a breaking change but, if we are careful about announcing it on forums ahead of time, it should be manageable.

I think we should also change timing to be an enumeration. We could perhaps emit a message (for, say, the duration of the next release) indicating that the behaviour has changed if no timing parameter was supplied. This would help users manage the change.

I think that the longer-term solution is to use the RMT module for the Neopixel implementation. At this point we could more easily produce a general solution by specifying the timing intervals. (See the original issue above for more detail)

If that sounds reasonable I can get to work on the short-term implementation.

Ok, yes, let's try to get this fixed.

My preference is to, in the short-term, change the default timing to work with 800KHz Neopixels

+1

I understand that this would be a breaking change but, if we are careful about announcing it on forums ahead of time, it should be manageable.

I don't think there's much choice but to make it a breaking change. It really should be the same as esp8266, and so it's really a bug that the default is 400kHz.

I think that the longer-term solution is to use the RMT module for the Neopixel implementation.

Yes, if someone has the time to implement it :) In that case I don't think it's worth introducing enumerations for the timing parameter, since they will quickly be replaced by however the RMT module works. For now the timing can be just 0 or 1.

If that sounds reasonable I can get to work on the short-term implementation.

Yes, please go ahead! Note that the ports/esp32/modules/apa106.py should still work as before, so would need an __init__ method to set timing to 0.

There is an advanced implementation in LoBo‘s fork, it uses RMT. Sadly it hasn‘t made it back