diff options
author | David S. Miller <davem@davemloft.net> | 2009-01-08 11:05:59 -0800 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2009-01-08 11:05:59 -0800 |
commit | 7f46b1343f723f98634a5dcee47856b2000079ed (patch) | |
tree | ed22b6298c8dd2f687890a0d79abcd1d273b5f81 /drivers/staging/frontier/README | |
parent | b8c31da64165b8566fc6e1c9c826f76e7b98ff02 (diff) | |
parent | 9e42d0cf5020aaf217433cad1a224745241d212a (diff) | |
download | kernel_samsung_smdk4412-7f46b1343f723f98634a5dcee47856b2000079ed.zip kernel_samsung_smdk4412-7f46b1343f723f98634a5dcee47856b2000079ed.tar.gz kernel_samsung_smdk4412-7f46b1343f723f98634a5dcee47856b2000079ed.tar.bz2 |
Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
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 0000000..07c9ef9 --- /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. |