I'd been assuming that the OS always copied our USB transfer buffer at submit-time. Turns out that this is true for Linux but not for Windows or Mac. This caused tearing when fcserver received a new frame while previous frame(s) were still queued in the USB host controller.

Fixed this by copying to a per-transfer buffer on Windows and Mac. Linux is unaffected. We avoid performing an additional copy there.

This lets us uniquely identify a particular device connection instance.

This was causing deadlocks all over on Windows. Now things seem to be
running smoothly!

This is necessary for URBs which synchronously complete. This is common on
the win32 backend.

When staring directly at the LEDs, the dithering flicker is visible- but in an enclosure, the flicker is totally nonexistent and the linear section causes a noticeable discontinuity.

A pure nonlinear-only approach seems like the best default. I'll document cases when this linear section might help, and it will be up to individual clients (or fcserver config files) to enable it.

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.

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 is way too verbose

This is hella verbose, quit it.

After discussing with Ping, changed the format of the color correction command to use a MIDI-style SysEx command in OPC.

The server now works end-to-end, yay.

Almost fast enough.. just 1.3ms more to shave off per frame.