---

yaml
---
r: 141285
b: refs/heads/master
c: b3bc12d
h: refs/heads/master
i:
  141283: a3a97bd
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 7f84642b2f6524929738a4c005002637ecd4b16d
+refs/heads/master: b3bc12dac7e4045654ef4db49bef3e00e03e4452

trunk/drivers/staging/frontier/README

@@ -1,28 +1,47 @@
-This directory contains the USB Tranzport and Alphatrack Kernel drivers for Linux.
+This directory contains the Linux USB Tranzport and Alphatrack Kernel drivers.
 
-At present the tranzport does reads/writes of 8 byte cmds to /dev/tranzport0 to control
-the lights and screen and wheel
+See http://www.frontierdesign.com for details on these devices.
 
-At present the alphatrack accepts reads/writes of 12 byte cmds to /dev/tranzport0 to control
-the lights and screen and fader.
+Userspace test code is available from
 
-Both drivers also have some sysfs hooks that are non-functional at the moment.
+git://toutatis.isc.org/home/d/src/git/frontier.git
 
-The API is currently closely tied to the ardour revision and WILL change.
+At present the tranzport does reads/writes of 8 byte cmds to
+/dev/tranzport0 to control the lights, screen, and wheel.
 
-A sysfs interface is PERFECT for simple userspace apps to do fun things with the
-lights and screen. It's fairly lousy for handling input events and very lousy
-for watching the state of the shuttle wheel.
+At present the alphatrack accepts reads/writes of 12 byte cmds to
+/dev/tranzport0 to control the lights, screen, fader and touchpad.
 
-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.
+The tranzport driver provides a rudimentary sysfs interface for the status of
+the device and a writable parameter for turning wheel compression on and off.
 
-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
 core driver simple because the only realtime work really required is
 the bottom half interrupt handler and the output overlapping.
 
-Exposing some sort of clean aio api to userspace would be perfect. What that
+Exposing some sort of clean api to userspace would be perfect. What that
 API looks like? Gah. beats me.