Tranzport and Alphatrack surfaces kernel drivers now in a git tree
m at teklibre.com
Tue Apr 15 15:49:16 PDT 2008
Last year around this time I was working on Linux kernel drivers for the
Frontier Designs Alphatrack and Tranzport. I got stuck on the API
I have had had since, at best irregular connections to the internet, so
working with ardour svn has been difficult, and rapidly the rest of the
surfaces branch of ardour became obsolete, so I just pulled the drivers
out and put them in a git repository:
git clone git://teklibre.com/home/d/src/git/frontier.git
The tranzport and alphatrack drivers still compile and appear to work on
linux 2.6.22. They are only talking to test code in userspace, but they
are very fast and lightweight compared to the libusb version, and more
importantly, they are more reliable, handling events like disconnect,
and high numbers of contending interrupts and real time processes, with
The current tranzport driver in ardour is userland based and tends to
get bogged down when you move the scrollwheel fast. There's no
alphatrack driver in ardour at present.
After I saw K-H's "state of the linux driver project" in lwn last week,
perhaps there might be some interest from that project? I have time to
resume working on it, now that the code is git based I can work offline
on them, but I remain stuck on that pesky API.
The kernel_driver/*sysfs* code is an aborted attempt at coping with a
ton of inputs/outputs. It's commented out for that reason. How sysfs is
managed in C does not scale...
The tranzport and alphatrack are in a category of devices for which I
can think of no kernel subsystem that can be extended to fit, yet they
are way cool.
"Surfaces" devices for audio tend to incorporate several major functions
into one device. They are not strictly input or output devices - they
have outputs like LCDs, LEDs, and motorized sliders, and inputs like 20+
buttons, shift keys, touch sensitive knobs, and sliders or shuttle wheels.
Some workable abstractions for all that would be nice.
A review of these drivers in their present state for feasible inclusion
into the kernel would be nice, too.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://driverdev.linuxdriverproject.org/pipermail/devel/attachments/20080416/265cca7b/attachment.pgp
More information about the devel