From b3bc12dac7e4045654ef4db49bef3e00e03e4452 Mon Sep 17 00:00:00 2001 From: David Täht Date: Tue, 20 Jan 2009 08:33:23 -0600 Subject: Staging: frontier: Updated documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: David Täht Signed-off-by: Greg Kroah-Hartman --- drivers/staging/frontier/README | 53 ++++++++++++++++++++++++++++------------- 1 file changed, 36 insertions(+), 17 deletions(-) diff --git a/drivers/staging/frontier/README b/drivers/staging/frontier/README index 07c9ef9b8fc4..cd07af22406a 100644 --- a/drivers/staging/frontier/README +++ b/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. -- cgit v1.2.3-59-g8ed1b