mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-08-25 02:09:42 +00:00
![David Täht](/assets/img/avatar_default.png)
Signed-off-by: David Täht <d@teklibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
47 lines
2 KiB
Text
47 lines
2 KiB
Text
This directory contains the Linux USB Tranzport and Alphatrack Kernel drivers.
|
|
|
|
See http://www.frontierdesign.com for details on these devices.
|
|
|
|
Userspace test code is available from
|
|
|
|
git://toutatis.isc.org/home/d/src/git/frontier.git
|
|
|
|
At present the tranzport does reads/writes of 8 byte cmds to
|
|
/dev/tranzport0 to control the lights, screen, and wheel.
|
|
|
|
At present the alphatrack accepts reads/writes of 12 byte cmds to
|
|
/dev/tranzport0 to control the lights, screen, fader and touchpad.
|
|
|
|
The tranzport driver provides a rudimentary sysfs interface for the status of
|
|
the device and a writable parameter for turning wheel compression on and off.
|
|
|
|
The API is nothing more than the USB commands issued to the device. Why?
|
|
|
|
The control wheel/fader can generate events far too quickly for
|
|
a typical userspace application to keep up with them via libusb. Input
|
|
needs to be 100% accurate and fast in order for the alphatrack or tranzport
|
|
to be useful.
|
|
|
|
UIO would be useful except that usb disconnect events need
|
|
to be handled correctly.
|
|
|
|
A sysfs interface is perfect for simple userspace apps to do fun things with
|
|
the lights and screen. But 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, or fader feedback support in that API
|
|
|
|
So, thus, these stubby drivers exist.
|
|
|
|
In the end this could be driven by a midi layer, which handles all those
|
|
cases via a well defined API, but - among other things - is slow, doesn't do
|
|
flow control, and is a LOT of extra work, none of which is required at
|
|
the kernel level (probably). 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 api to userspace would be perfect. What that
|
|
API looks like? Gah. beats me.
|