diff options
author | David Taht <d@teklibre.com> | 2008-12-17 17:13:45 -0800 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2009-01-06 13:52:36 -0800 |
commit | 8da3dc28753ece6b7ddae9d5897a0ad0797e21e6 (patch) | |
tree | df9f694ef05bfad2cc9d05f55fb46693e713b36e /drivers/staging/frontier/README | |
parent | 1242c70df56978e8abbf715a02fb1c55313f8471 (diff) |
Staging: add frontier tranzport and alphatrack drivers
Adds the tranzport and alphatrack drivers to the staging tree.
Cc: David Taht <d@teklibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/staging/frontier/README')
-rw-r--r-- | drivers/staging/frontier/README | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/drivers/staging/frontier/README b/drivers/staging/frontier/README new file mode 100644 index 000000000000..07c9ef9b8fc4 --- /dev/null +++ b/drivers/staging/frontier/README @@ -0,0 +1,28 @@ +This directory contains the USB Tranzport and Alphatrack Kernel drivers for Linux. + +At present the tranzport does reads/writes of 8 byte cmds to /dev/tranzport0 to control +the lights and screen and wheel + +At present the alphatrack accepts reads/writes of 12 byte cmds to /dev/tranzport0 to control +the lights and screen and fader. + +Both drivers also have some sysfs hooks that are non-functional at the moment. + +The API is currently closely tied to the ardour revision and WILL change. + +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. + +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. + +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 +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 +API looks like? Gah. beats me. |