mirror of https://gitee.com/openkylin/linux.git
12e5550892
* 'staging-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (466 commits) net/hyperv: Add support for jumbo frame up to 64KB net/hyperv: Add NETVSP protocol version negotiation net/hyperv: Remove unnecessary kmap_atomic in netvsc driver staging/rtl8192e: Register against lib80211 staging/rtl8192e: Convert to lib80211_crypt_info staging/rtl8192e: Convert to lib80211_crypt_data and lib80211_crypt_ops staging/rtl8192e: Add lib80211.h to rtllib.h staging/mei: add watchdog device registration wrappers drm/omap: GEM, deal with cache staging: vt6656: int.c, int.h: Change return of function to void staging: usbip: removed unused definitions from header staging: usbip: removed dead code from receive function staging:iio: Drop {mark,unmark}_in_use callbacks staging:iio: Drop buffer mark_param_change callback staging:iio: Drop the unused buffer enable() and is_enabled() callbacks staging:iio: Drop buffer busy flag staging:iio: Make sure a device is only opened once at a time staging:iio: Disallow modifying buffer size when buffer is enabled staging:iio: Disallow changing scan elements in all buffered modes staging:iio: Use iio_buffer_enabled instead of open coding it ... Fix up conflict in drivers/staging/iio/adc/ad799x_core.c (removal of module_init due to using module_i2c_driver() helper, next to removal of MODULE_ALIAS due to using MODULE_DEVICE_TABLE instead). |
||
---|---|---|
.. | ||
Kconfig | ||
Makefile | ||
README | ||
TODO | ||
alphatrack.c | ||
alphatrack.h | ||
tranzport.c |
README
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.