2 files changed, 224 insertions, 0 deletions

diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
new file mode 100644
index 000000000000..ad1125b02ff4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
@@ -0,0 +1,98 @@
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_cpi
+Date:           August 2010
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    It is possible to switch the cpi setting of the mouse with the
+                press of a button.
+                When read, this file returns the raw number of the actual cpi
+                setting reported by the mouse. This number has to be further
+                processed to receive the real dpi value.
+
+                VALUE DPI
+                1     400
+                2     800
+                4     1600
+
+                This file is readonly.
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_profile
+Date:           August 2010
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When read, this file returns the number of the actual profile in
+                range 0-4.
+                This file is readonly.
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/firmware_version
+Date:           August 2010
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When read, this file returns the raw integer version number of the
+                firmware reported by the mouse. Using the integer value eases
+                further usage in other programs. To receive the real version
+                number the decimal point has to be shifted 2 positions to the
+                left. E.g. a returned value of 138 means 1.38
+                This file is readonly.
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile_settings
+Date:           August 2010
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The mouse can store 5 profiles which can be switched by the
+                press of a button. A profile is split in settings and buttons.
+                profile_settings holds informations like resolution, sensitivity
+                and light effects.
+                When written, this file lets one write the respective profile
+                settings back to the mouse. The data has to be 13 bytes long.
+                The mouse will reject invalid data.
+                Which profile to write is determined by the profile number
+                contained in the data.
+                This file is writeonly.
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]_settings
+Date:           August 2010
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The mouse can store 5 profiles which can be switched by the
+                press of a button. A profile is split in settings and buttons.
+                profile_settings holds informations like resolution, sensitivity
+                and light effects.
+                When read, these files return the respective profile settings.
+                The returned data is 13 bytes in size.
+                This file is readonly.
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile_buttons
+Date:           August 2010
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The mouse can store 5 profiles which can be switched by the
+                press of a button. A profile is split in settings and buttons.
+                profile_buttons holds informations about button layout.
+                When written, this file lets one write the respective profile
+                buttons back to the mouse. The data has to be 19 bytes long.
+                The mouse will reject invalid data.
+                Which profile to write is determined by the profile number
+                contained in the data.
+                This file is writeonly.
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]_buttons
+Date:           August 2010
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The mouse can store 5 profiles which can be switched by the
+                press of a button. A profile is split in settings and buttons.
+                profile_buttons holds informations about button layout.
+                When read, these files return the respective profile buttons.
+                The returned data is 19 bytes in size.
+                This file is readonly.
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/startup_profile
+Date:           August 2010
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The integer value of this attribute ranges from 0-4.
+                When read, this attribute returns the number of the profile
+                that's active when the mouse is powered on.
+                This file is readonly.
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/settings
+Date:           August 2010
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When read, this file returns the settings stored in the mouse.
+                The size of the data is 3 bytes and holds information on the
+                startup_profile.
+                When written, this file lets write settings back to the mouse.
+                The data has to be 3 bytes long. The mouse will reject invalid
+                data.
diff --git a/Documentation/input/ntrig.txt b/Documentation/input/ntrig.txt
new file mode 100644
index 000000000000..be1fd981f73f
--- /dev/null
+++ b/Documentation/input/ntrig.txt
@@ -0,0 +1,126 @@
+N-Trig touchscreen Driver
+-------------------------
+        Copyright (c) 2008-2010 Rafi Rubin <rafi@seas.upenn.edu>
+        Copyright (c) 2009-2010 Stephane Chatty
+
+This driver provides support for N-Trig pen and multi-touch sensors.  Single
+and multi-touch events are translated to the appropriate protocols for
+the hid and input systems.  Pen events are sufficiently hid compliant and
+are left to the hid core.  The driver also provides additional filtering
+and utility functions accessible with sysfs and module parameters.
+
+This driver has been reported to work properly with multiple N-Trig devices
+attached.
+
+
+Parameters
+----------
+
+Note: values set at load time are global and will apply to all applicable
+devices.  Adjusting parameters with sysfs will override the load time values,
+but only for that one device.
+
+The following parameters are used to configure filters to reduce noise:
+
+activate_slack          number of fingers to ignore before processing events
+
+activation_height       size threshold to activate immediately
+activation_width
+
+min_height              size threshold bellow which fingers are ignored
+min_width               both to decide activation and during activity
+
+deactivate_slack        the number of "no contact" frames to ignore before
+                        propagating the end of activity events
+
+When the last finger is removed from the device, it sends a number of empty
+frames.  By holding off on deactivation for a few frames we can tolerate false
+erroneous disconnects, where the sensor may mistakenly not detect a finger that
+is still present.  Thus deactivate_slack addresses problems where a users might
+see breaks in lines during drawing, or drop an object during a long drag.
+
+
+Additional sysfs items
+----------------------
+
+These nodes just provide easy access to the ranges reported by the device.
+sensor_logical_height   the range for positions reported during activity
+sensor_logical_width
+
+sensor_physical_height  internal ranges not used for normal events but
+sensor_physical_width   useful for tuning
+
+All N-Trig devices with product id of 1 report events in the ranges of
+X: 0-9600
+Y: 0-7200
+However not all of these devices have the same physical dimensions.  Most
+seem to be 12" sensors (Dell Latitude XT and XT2 and the HP TX2), and
+at least one model (Dell Studio 17) has a 17" sensor.  The ratio of physical
+to logical sizes is used to adjust the size based filter parameters.
+
+
+Filtering
+---------
+
+With the release of the early multi-touch firmwares it became increasingly
+obvious that these sensors were prone to erroneous events.  Users reported
+seeing both inappropriately dropped contact and ghosts, contacts reported
+where no finger was actually touching the screen.
+
+Deactivation slack helps prevent dropped contact for single touch use, but does
+not address the problem of dropping one of more contacts while other contacts
+are still active.  Drops in the multi-touch context require additional
+processing and should be handled in tandem with tacking.
+
+As observed ghost contacts are similar to actual use of the sensor, but they
+seem to have different profiles.  Ghost activity typically shows up as small
+short lived touches.  As such, I assume that the longer the continuous stream
+of events the more likely those events are from a real contact, and that the
+larger the size of each contact the more likely it is real.  Balancing the
+goals of preventing ghosts and accepting real events quickly (to minimize
+user observable latency), the filter accumulates confidence for incoming
+events until it hits thresholds and begins propagating.  In the interest in
+minimizing stored state as well as the cost of operations to make a decision,
+I've kept that decision simple.
+
+Time is measured in terms of the number of fingers reported, not frames since
+the probability of multiple simultaneous ghosts is expected to drop off
+dramatically with increasing numbers.  Rather than accumulate weight as a
+function of size, I just use it as a binary threshold.  A sufficiently large
+contact immediately overrides the waiting period and leads to activation.
+
+Setting the activation size thresholds to large values will result in deciding
+primarily on activation slack.  If you see longer lived ghosts, turning up the
+activation slack while reducing the size thresholds may suffice to eliminate
+the ghosts while keeping the screen quite responsive to firm taps.
+
+Contacts continue to be filtered with min_height and min_width even after
+the initial activation filter is satisfied.  The intent is to provide
+a mechanism for filtering out ghosts in the form of an extra finger while
+you actually are using the screen.  In practice this sort of ghost has
+been far less problematic or relatively rare and I've left the defaults
+set to 0 for both parameters, effectively turning off that filter.
+
+I don't know what the optimal values are for these filters.  If the defaults
+don't work for you, please play with the parameters.  If you do find other
+values more comfortable, I would appreciate feedback.
+
+The calibration of these devices does drift over time.  If ghosts or contact
+dropping worsen and interfere with the normal usage of your device, try
+recalibrating it.
+
+
+Calibration
+-----------
+
+The N-Trig windows tools provide calibration and testing routines.  Also an
+unofficial unsupported set of user space tools including a calibrator is
+available at:
+http://code.launchpad.net/~rafi-seas/+junk/ntrig_calib
+
+
+Tracking
+--------
+
+As of yet, all tested N-Trig firmwares do not track fingers.  When multiple
+contacts are active they seem to be sorted primarily by Y position.