tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
Staging: frontier: Updated documentation
Signed-off-by: David Täht <d@teklibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
authored by
David Täht
and committed by
Greg Kroah-Hartman
b3bc12da
7f84642b
+36
-17
+36
-17
drivers/staging/frontier/README
+36
-17
drivers/staging/frontier/README
···
1
-
This directory contains the USB Tranzport and Alphatrack Kernel drivers for Linux.
1
+
This directory contains the Linux USB Tranzport and Alphatrack Kernel drivers.
2
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
3
+
See http://www.frontierdesign.com for details on these devices.
5
4
6
-
At present the alphatrack accepts reads/writes of 12 byte cmds to /dev/tranzport0 to control
7
-
the lights and screen and fader.
5
+
Userspace test code is available from
8
6
9
-
Both drivers also have some sysfs hooks that are non-functional at the moment.
7
+
git://toutatis.isc.org/home/d/src/git/frontier.git
10
8
11
-
The API is currently closely tied to the ardour revision and WILL change.
9
+
At present the tranzport does reads/writes of 8 byte cmds to
10
+
/dev/tranzport0 to control the lights, screen, and wheel.
12
11
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.
12
+
At present the alphatrack accepts reads/writes of 12 byte cmds to
13
+
/dev/tranzport0 to control the lights, screen, fader and touchpad.
16
14
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.
15
+
The tranzport driver provides a rudimentary sysfs interface for the status of
16
+
the device and a writable parameter for turning wheel compression on and off.
20
17
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
18
+
The API is nothing more than the USB commands issued to the device. Why?
19
+
20
+
The control wheel/fader can generate events far too quickly for
21
+
a typical userspace application to keep up with them via libusb. Input
22
+
needs to be 100% accurate and fast in order for the alphatrack or tranzport
23
+
to be useful.
24
+
25
+
UIO would be useful except that usb disconnect events need
26
+
to be handled correctly.
27
+
28
+
A sysfs interface is perfect for simple userspace apps to do fun things with
29
+
the lights and screen. But it's fairly lousy for handling input events and
30
+
very lousy for watching the state of the shuttle wheel.
31
+
32
+
A 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
+
37
+
So, thus, these stubby drivers exist.
38
+
39
+
In the end this could be driven by a midi layer, which handles all those
40
+
cases via a well defined API, but - among other things - is slow, doesn't do
41
+
flow control, and is a LOT of extra work, none of which is required at
42
+
the kernel level (probably). Frankly, I'd like to keep the
24
43
core driver simple because the only realtime work really required is
25
44
the bottom half interrupt handler and the output overlapping.
26
45
27
-
Exposing some sort of clean aio api to userspace would be perfect. What that
46
+
Exposing some sort of clean api to userspace would be perfect. What that
28
47
API looks like? Gah. beats me.