• Home
  • History
  • Annotate
  • only in /drivers/staging/frontier/
NameDateSize

..10-Oct-20124 KiB

alphatrack.c10-Oct-201222.4 KiB

alphatrack.h10-Oct-20122 KiB

Kconfig10-Oct-2012179

Makefile10-Oct-201281

README10-Oct-20122 KiB

TODO10-Oct-2012284

tranzport.c10-Oct-201226.1 KiB

README

1This directory contains the Linux USB Tranzport and Alphatrack Kernel drivers.
2
3See http://www.frontierdesign.com for details on these devices.
4
5Userspace test code is available from
6
7git://toutatis.isc.org/home/d/src/git/frontier.git
8
9At present the tranzport does reads/writes of 8 byte cmds to
10/dev/tranzport0 to control the lights, screen, and wheel.
11
12At present the alphatrack accepts reads/writes of 12 byte cmds to
13/dev/tranzport0 to control the lights, screen, fader and touchpad.
14
15The tranzport driver provides a rudimentary sysfs interface for the status of
16the device and a writable parameter for turning wheel compression on and off.
17
18The API is nothing more than the USB commands issued to the device. Why?
19
20The control wheel/fader can generate events far too quickly for
21a typical userspace application to keep up with them via libusb. Input
22needs to be 100% accurate and fast in order for the alphatrack or tranzport
23to be useful.
24
25UIO would be useful except that usb disconnect events need
26to be handled correctly.
27
28A sysfs interface is perfect for simple userspace apps to do fun things with
29the lights and screen. But it's fairly lousy for handling input events and
30very lousy for watching the state of the shuttle wheel.
31
32A linux input events interface is great for the input events and shuttle wheel.
33* It's theoretically OK on LEDs.
34* A fader can be mapped to an absolute mouse device.
35* But there is no LCD support at all, or fader feedback support in that API
36
37So, thus, these stubby drivers exist.
38
39In the end this could be driven by a midi layer, which handles all those
40cases via a well defined API, but - among other things - is slow, doesn't do
41flow control, and is a LOT of extra work, none of which is required at
42the kernel level (probably). Frankly, I'd like to keep the
43core driver simple because the only realtime work really required is
44the bottom half interrupt handler and the output overlapping.
45
46Exposing some sort of clean api to userspace would be perfect. What that
47API looks like? Gah. beats me.
48