This is a big improvement in dithering quality: Near zero, where we have the most problem with visible flicker, this uses a linear curve instead of the usual nonlinear curve.

Now the firmware config flags actually select between several different inner-loops. This will be useful in the future if we want to support different configurations with runtime config options, and right now it's useful for side-by-side comparisons with the various config options.

This can get out of hand if the client is producing frames faster than our USB device accepts them, leading to large kernel-space queues and high latency. This patch causes intermediate frames to be dropped, but it will always update the device with the latest frame buffer state.

This tests the firmware with a busy USB stack, and measures how busy we're keeping it. By virtue of this being a stupid blocking USB client it won't actually be that busy, but this is a baseline at least.

This is way too verbose

I originally had this in here as a workaround because sometimes fcserver would fill up its USB queue, but this increases lag a lot. Much better without, and if fcserver acts up again I should just fix it :P

Configuration is now no longer mandatory.

This makes it easier to move around for future optimizations, and it already gains us a few FPS by allowing the compiler to optimize a little better

This actually works fine, we just weren't initializing it to zero, which borked a bunch of assumptions of course.

This is hella verbose, quit it.

It's causing USB problems (reading the string descriptors) and it doesn't help now that I've determined that executing from RAM doesn't significantly speed up the updatePixel loop.

This causes false negatives sometimes, boo.