-In the end this is going to be driven by a midi layer, which handles all those
-cases via a defined API, but - among other things - is slow, doesn't do
-flow control, and is a LOT of extra work. Frankly, I'd like to keep the
+The API is nothing more than the USB commands issued to the device. Why?
+
+The control wheel/fader can generate events far too quickly for
+a typical userspace application to keep up with them via libusb. Input
+needs to be 100% accurate and fast in order for the alphatrack or tranzport
+to be useful.
+
+UIO would be useful except that usb disconnect events need
+to be handled correctly.
+
+A sysfs interface is perfect for simple userspace apps to do fun things with
+the lights and screen. But it's fairly lousy for handling input events and
+very lousy for watching the state of the shuttle wheel.
+
+A linux input events interface is great for the input events and shuttle wheel.
+* It's theoretically OK on LEDs.
+* A fader can be mapped to an absolute mouse device.
+* But there is no LCD support at all, or fader feedback support in that API
+
+So, thus, these stubby drivers exist.
+
+In the end this could be driven by a midi layer, which handles all those
+cases via a well defined API, but - among other things - is slow, doesn't do
+flow control, and is a LOT of extra work, none of which is required at
+the kernel level (probably). Frankly, I'd like to keep the