linux/drivers/staging/frontier
Linus Torvalds 159d8133d0 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
Pull trivial tree updates from Jiri Kosina:
 "Usual rocket science -- mostly documentation and comment updates"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial:
  sparse: fix comment
  doc: fix double words
  isdn: capi: fix "CAPI_VERSION" comment
  doc: DocBook: Fix typos in xml and template file
  Bluetooth: add module name for btwilink
  driver core: unexport static function create_syslog_header
  mmc: core: typo fix in printk specifier
  ARM: spear: clean up editing mistake
  net-sysfs: fix comment typo 'CONFIG_SYFS'
  doc: Insert MODULE_ in module-signing macros
  Documentation: update URL to hfsplus Technote 1150
  gpio: update path to documentation
  ixgbe: Fix format string in ixgbe_fcoe.
  Kconfig: Remove useless "default N" lines
  user_namespace.c: Remove duplicated word in comment
  CREDITS: fix formatting
  treewide: Fix typo in Documentation/DocBook
  mm: Fix warning on make htmldocs caused by slab.c
  ata: ata-samsung_cf: cleanup in header file
  idr: remove unused prototype of idr_free()
2014-04-02 16:23:38 -07:00
..
alphatrack.c staging: frontier: Fix quoted string split across lines 2014-03-16 20:26:51 -07:00
alphatrack.h staging/frontier: Fixed up incorrect formatted comments 2013-05-21 10:30:10 -07:00
Kconfig Kconfig: Remove useless "default N" lines 2014-02-20 14:38:06 +01:00
Makefile
README
TODO
tranzport.c Staging:frontier: Fix quoted string split across lines 2014-03-08 19:50:31 -08:00

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.