diff options
author | David Taht <d@teklibre.com> | 2008-12-17 20:13:45 -0500 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2009-01-06 16:52:36 -0500 |
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 00000000000..07c9ef9b8fc --- /dev/null +++ b/drivers/staging/frontier/README | |||
@@ -0,0 +1,28 @@ | |||
1 | This directory contains the USB Tranzport and Alphatrack Kernel drivers for Linux. | ||
2 | |||
3 | At present the tranzport does reads/writes of 8 byte cmds to /dev/tranzport0 to control | ||
4 | the lights and screen and wheel | ||
5 | |||
6 | At present the alphatrack accepts reads/writes of 12 byte cmds to /dev/tranzport0 to control | ||
7 | the lights and screen and fader. | ||
8 | |||
9 | Both drivers also have some sysfs hooks that are non-functional at the moment. | ||
10 | |||
11 | The API is currently closely tied to the ardour revision and WILL change. | ||
12 | |||
13 | A sysfs interface is PERFECT for simple userspace apps to do fun things with the | ||
14 | lights and screen. It's fairly lousy for handling input events and very lousy | ||
15 | for watching the state of the shuttle wheel. | ||
16 | |||
17 | A linux input events interface is great for the input events and shuttle wheel. It's | ||
18 | theoretically OK on LEDs. A Fader can be mapped to an absolute mouse device. | ||
19 | But there is no LCD support at all. | ||
20 | |||
21 | In the end this is going to be driven by a midi layer, which handles all those | ||
22 | cases via a defined API, but - among other things - is slow, doesn't do | ||
23 | flow control, and is a LOT of extra work. Frankly, I'd like to keep the | ||
24 | core driver simple because the only realtime work really required is | ||
25 | the bottom half interrupt handler and the output overlapping. | ||
26 | |||
27 | Exposing some sort of clean aio api to userspace would be perfect. What that | ||
28 | API looks like? Gah. beats me. | ||