drivers/staging/frontier/README - linux - Git at Google


            
            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.
	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.