Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 8da3dc28 authored by David Taht's avatar David Taht Committed by Greg Kroah-Hartman
Browse files

Staging: add frontier tranzport and alphatrack drivers 



Adds the tranzport and alphatrack drivers to the staging tree.

Cc: David Taht <d@teklibre.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
parent 1242c70d

drivers/staging/Kconfig

+2 −0
Original line number Diff line number Diff line
@@ -89,5 +89,7 @@ source "drivers/staging/rspiusb/Kconfig" 


source "drivers/staging/mimio/Kconfig"



source "drivers/staging/frontier/Kconfig"



endif # !STAGING_EXCLUDE_BUILD

endif # STAGING

drivers/staging/Makefile

+1 −0
Original line number Diff line number Diff line
@@ -27,3 +27,4 @@ obj-$(CONFIG_ALTERA_PCIE_CHDMA) += altpciechdma/ 
obj-$(CONFIG_RTL8187SE)		+= rtl8187se/

obj-$(CONFIG_USB_RSPI)		+= rspiusb/

obj-$(CONFIG_INPUT_MIMIO)	+= mimio/

obj-$(CONFIG_TRANZPORT)		+= frontier/

drivers/staging/frontier/Kconfig

0 → 100644
+6 −0
Original line number Diff line number Diff line 
config TRANZPORT

	tristate "Frontier Tranzport and Alphatrack support"

	depends on USB

	default N

	---help---

	  Enable support for the Frontier Tranzport and Alphatrack devices.

drivers/staging/frontier/Makefile

0 → 100644
+2 −0
Original line number Diff line number Diff line 
obj-$(CONFIG_TRANZPORT)		+= tranzport.o

obj-$(CONFIG_TRANZPORT)		+= alphatrack.o

drivers/staging/frontier/README

0 → 100644
+28 −0
Original line number Diff line number Diff line 
This directory contains the USB Tranzport and Alphatrack Kernel drivers for Linux.



At present the tranzport does reads/writes of 8 byte cmds to /dev/tranzport0 to control

the lights and screen and wheel



At present the alphatrack accepts reads/writes of 12 byte cmds to /dev/tranzport0 to control

the lights and screen and fader.



Both drivers also have some sysfs hooks that are non-functional at the moment.



The API is currently closely tied to the ardour revision and WILL change.



A sysfs interface is PERFECT for simple userspace apps to do fun things with the

lights and screen. 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.



In the end this is going to be driven by a midi layer, which handles all those

cases via a defined API, but - among other things - is slow, doesn't do

flow control, and is a LOT of extra work. 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 aio api to userspace would be perfect. What that

API looks like? Gah. beats me.