- Oct 29, 2013
-
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
This is pointed to a bleeding-edge branch where Windows hotplug support is being developed
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
- Oct 21, 2013
-
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
This is more secure by default, and it allows fcserver to work correctly on Mac OS when no networking is available. (With wifi disabled, a server bound to 'null' won't be listening on localhost. Blah.)
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
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.
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
This is really dumb, we weren't processing backlogged packets from the opcsink buffer. This is the cause of the ugly delays I'd been seeing in the 'waves' demo.
-
Micah Elizabeth Scott authored
This lets us disable the Nagle algorithm, and have finer control over error handling
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
- Oct 20, 2013
-
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
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.
-
Micah Elizabeth Scott authored
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.
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
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.
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
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.
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
This is way too verbose
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
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
-
Micah Elizabeth Scott authored
-
Micah Elizabeth Scott authored
-