David Taht | 8da3dc2 | 2008-12-17 17:13:45 -0800 | [diff] [blame] | 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. |