diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2011-10-27 10:44:20 +0400 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2011-10-27 10:44:20 +0400 |
commit | 396e6e49c58bb23d1814d3c240c736c9f01523c5 (patch) | |
tree | a6ec8dac896c3ea3ac7b1bb0dce8728766afcf91 /Documentation | |
parent | 18974369cfe23acf16d0fb79e0d1fba7a9a95ec0 (diff) | |
parent | 6ad390a25a9d1d8606b9b826878f0a30639dc2b3 (diff) | |
download | linux-396e6e49c58bb23d1814d3c240c736c9f01523c5.tar.xz |
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (68 commits)
Input: adp5589-keys - add support for the ADP5585 derivatives
Input: imx_keypad - add pm suspend and resume support
Input: force feedback - potential integer wrap in input_ff_create()
Input: tsc2007 - make sure that X plate resistance is specified
Input: serio_raw - fix memory leak when closing char device
Input: serio_raw - kick clients when disconnecting port
Input: serio_raw - explicitly mark disconnected ports as dead
Input: serio_raw - fix coding style issues
Input: serio_raw - use dev_*() for messages
Input: serio_raw - use bool for boolean data
Input: serio_raw - perform proper locking when adding clients to list
Input: serio_raw - rename serio_raw_list to serio_raw_client
Input: serio_raw - use kref instead of rolling out its own refcounting
Input: psmouse - switch to using dev_*() for messages
Input: wacom - correct max Y value on medium bamboos
Input: wacom - add ABS_DISTANCE to Bamboo Pen reports
Input: wacom - remove unneeded touch pressure initialization
Input: lm8323 - wrap suspend and resume in CONFIG_PM_SLEEP
Input: ad7879-i2c - wrap suspend and resume in CONFIG_PM_SLEEP
Input: synaptics_i2c - wrap suspend and resume in CONFIG_PM_SLEEP
...
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/ABI/testing/sysfs-driver-wacom | 72 | ||||
-rw-r--r-- | Documentation/ABI/testing/sysfs-wacom | 10 | ||||
-rw-r--r-- | Documentation/input/elantech.txt | 295 | ||||
-rw-r--r-- | Documentation/input/multi-touch-protocol.txt | 14 |
4 files changed, 365 insertions, 26 deletions
diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom new file mode 100644 index 000000000000..82d4df136444 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-wacom @@ -0,0 +1,72 @@ +What: /sys/class/hidraw/hidraw*/device/speed +Date: April 2010 +Kernel Version: 2.6.35 +Contact: linux-bluetooth@vger.kernel.org +Description: + The /sys/class/hidraw/hidraw*/device/speed file controls + reporting speed of Wacom bluetooth tablet. Reading from + this file returns 1 if tablet reports in high speed mode + or 0 otherwise. Writing to this file one of these values + switches reporting speed. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led +Date: August 2011 +Contact: linux-input@vger.kernel.org +Description: + Attribute group for control of the status LEDs and the OLEDs. + This attribute group is only available for Intuos 4 M, L, + and XL (with LEDs and OLEDs) and Cintiq 21UX2 (LEDs only). + Therefore its presence implicitly signifies the presence of + said LEDs and OLEDs on the tablet device. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance +Date: August 2011 +Contact: linux-input@vger.kernel.org +Description: + Writing to this file sets the status LED luminance (1..127) + when the stylus does not touch the tablet surface, and no + button is pressed on the stylus. This luminance level is + normally lower than the level when a button is pressed. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance +Date: August 2011 +Contact: linux-input@vger.kernel.org +Description: + Writing to this file sets the status LED luminance (1..127) + when the stylus touches the tablet surface, or any button is + pressed on the stylus. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select +Date: August 2011 +Contact: linux-input@vger.kernel.org +Description: + Writing to this file sets which one of the four (for Intuos 4) + or of the right four (for Cintiq 21UX2) status LEDs is active (0..3). + The other three LEDs on the same side are always inactive. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select +Date: September 2011 +Contact: linux-input@vger.kernel.org +Description: + Writing to this file sets which one of the left four (for Cintiq 21UX2) + status LEDs is active (0..3). The other three LEDs on the left are always + inactive. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance +Date: August 2011 +Contact: linux-input@vger.kernel.org +Description: + Writing to this file sets the overall luminance level (0..15) + of all eight button OLED displays. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg +Date: August 2011 +Contact: linux-input@vger.kernel.org +Description: + When writing a 1024 byte raw image in Wacom Intuos 4 + interleaving format to the file, the image shows up on Button N + of the device. The image is a 64x32 pixel 4-bit gray image. The + 1024 byte binary is split up into 16x 64 byte chunks. Each 64 + byte chunk encodes the image data for two consecutive lines on + the display. The low nibble of each byte contains the first + line, and the high nibble contains the second line. diff --git a/Documentation/ABI/testing/sysfs-wacom b/Documentation/ABI/testing/sysfs-wacom deleted file mode 100644 index 1517976e25c4..000000000000 --- a/Documentation/ABI/testing/sysfs-wacom +++ /dev/null @@ -1,10 +0,0 @@ -What: /sys/class/hidraw/hidraw*/device/speed -Date: April 2010 -Kernel Version: 2.6.35 -Contact: linux-bluetooth@vger.kernel.org -Description: - The /sys/class/hidraw/hidraw*/device/speed file controls - reporting speed of wacom bluetooth tablet. Reading from - this file returns 1 if tablet reports in high speed mode - or 0 otherwise. Writing to this file one of these values - switches reporting speed. diff --git a/Documentation/input/elantech.txt b/Documentation/input/elantech.txt index db798af5ef98..5602eb71ad5d 100644 --- a/Documentation/input/elantech.txt +++ b/Documentation/input/elantech.txt @@ -16,15 +16,28 @@ Contents 1. Introduction 2. Extra knobs - 3. Hardware version 1 - 3.1 Registers - 3.2 Native relative mode 4 byte packet format - 3.3 Native absolute mode 4 byte packet format - 4. Hardware version 2 + 3. Differentiating hardware versions + 4. Hardware version 1 4.1 Registers - 4.2 Native absolute mode 6 byte packet format - 4.2.1 One finger touch - 4.2.2 Two finger touch + 4.2 Native relative mode 4 byte packet format + 4.3 Native absolute mode 4 byte packet format + 5. Hardware version 2 + 5.1 Registers + 5.2 Native absolute mode 6 byte packet format + 5.2.1 Parity checking and packet re-synchronization + 5.2.2 One/Three finger touch + 5.2.3 Two finger touch + 6. Hardware version 3 + 6.1 Registers + 6.2 Native absolute mode 6 byte packet format + 6.2.1 One/Three finger touch + 6.2.2 Two finger touch + 7. Hardware version 4 + 7.1 Registers + 7.2 Native absolute mode 6 byte packet format + 7.2.1 Status packet + 7.2.2 Head packet + 7.2.3 Motion packet @@ -375,7 +388,7 @@ For all the other ones, there are just a few constant bits: In case an error is detected, all the packets are shifted by one (and packet[0] is discarded). -5.2.1 One/Three finger touch +5.2.2 One/Three finger touch ~~~~~~~~~~~~~~~~ byte 0: @@ -384,19 +397,19 @@ byte 0: n1 n0 w3 w2 . . R L L, R = 1 when Left, Right mouse button pressed - n1..n0 = numbers of fingers on touchpad + n1..n0 = number of fingers on touchpad byte 1: bit 7 6 5 4 3 2 1 0 - p7 p6 p5 p4 . x10 x9 x8 + p7 p6 p5 p4 x11 x10 x9 x8 byte 2: bit 7 6 5 4 3 2 1 0 x7 x6 x5 x4 x3 x2 x1 x0 - x10..x0 = absolute x value (horizontal) + x11..x0 = absolute x value (horizontal) byte 3: @@ -420,7 +433,7 @@ byte 3: byte 4: bit 7 6 5 4 3 2 1 0 - p3 p1 p2 p0 . . y9 y8 + p3 p1 p2 p0 y11 y10 y9 y8 p7..p0 = pressure (not EF113) @@ -429,10 +442,10 @@ byte 5: bit 7 6 5 4 3 2 1 0 y7 y6 y5 y4 y3 y2 y1 y0 - y9..y0 = absolute y value (vertical) + y11..y0 = absolute y value (vertical) -4.2.2 Two finger touch +5.2.3 Two finger touch ~~~~~~~~~~~~~~~~ Note that the two pairs of coordinates are not exactly the coordinates of the @@ -446,7 +459,7 @@ byte 0: n1 n0 ay8 ax8 . . R L L, R = 1 when Left, Right mouse button pressed - n1..n0 = numbers of fingers on touchpad + n1..n0 = number of fingers on touchpad byte 1: @@ -480,3 +493,253 @@ byte 5: by7 by8 by5 by4 by3 by2 by1 by0 by8..by0 = upper-right finger absolute y value + +///////////////////////////////////////////////////////////////////////////// + +6. Hardware version 3 + ================== + +6.1 Registers + ~~~~~~~~~ +* reg_10 + + bit 7 6 5 4 3 2 1 0 + 0 0 0 0 0 0 0 A + + A: 1 = enable absolute tracking + +6.2 Native absolute mode 6 byte packet format + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +1 and 3 finger touch shares the same 6-byte packet format, except that +3 finger touch only reports the position of the center of all three fingers. + +Firmware would send 12 bytes of data for 2 finger touch. + +Note on debounce: +In case the box has unstable power supply or other electricity issues, or +when number of finger changes, F/W would send "debounce packet" to inform +driver that the hardware is in debounce status. +The debouce packet has the following signature: + byte 0: 0xc4 + byte 1: 0xff + byte 2: 0xff + byte 3: 0x02 + byte 4: 0xff + byte 5: 0xff +When we encounter this kind of packet, we just ignore it. + +6.2.1 One/Three finger touch + ~~~~~~~~~~~~~~~~~~~~~~ + +byte 0: + + bit 7 6 5 4 3 2 1 0 + n1 n0 w3 w2 0 1 R L + + L, R = 1 when Left, Right mouse button pressed + n1..n0 = number of fingers on touchpad + +byte 1: + + bit 7 6 5 4 3 2 1 0 + p7 p6 p5 p4 x11 x10 x9 x8 + +byte 2: + + bit 7 6 5 4 3 2 1 0 + x7 x6 x5 x4 x3 x2 x1 x0 + + x11..x0 = absolute x value (horizontal) + +byte 3: + + bit 7 6 5 4 3 2 1 0 + 0 0 w1 w0 0 0 1 0 + + w3..w0 = width of the finger touch + +byte 4: + + bit 7 6 5 4 3 2 1 0 + p3 p1 p2 p0 y11 y10 y9 y8 + + p7..p0 = pressure + +byte 5: + + bit 7 6 5 4 3 2 1 0 + y7 y6 y5 y4 y3 y2 y1 y0 + + y11..y0 = absolute y value (vertical) + +6.2.2 Two finger touch + ~~~~~~~~~~~~~~~~ + +The packet format is exactly the same for two finger touch, except the hardware +sends two 6 byte packets. The first packet contains data for the first finger, +the second packet has data for the second finger. So for two finger touch a +total of 12 bytes are sent. + +///////////////////////////////////////////////////////////////////////////// + +7. Hardware version 4 + ================== + +7.1 Registers + ~~~~~~~~~ +* reg_07 + + bit 7 6 5 4 3 2 1 0 + 0 0 0 0 0 0 0 A + + A: 1 = enable absolute tracking + +7.2 Native absolute mode 6 byte packet format + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +v4 hardware is a true multitouch touchpad, capable of tracking up to 5 fingers. +Unfortunately, due to PS/2's limited bandwidth, its packet format is rather +complex. + +Whenever the numbers or identities of the fingers changes, the hardware sends a +status packet to indicate how many and which fingers is on touchpad, followed by +head packets or motion packets. A head packet contains data of finger id, finger +position (absolute x, y values), width, and pressure. A motion packet contains +two fingers' position delta. + +For example, when status packet tells there are 2 fingers on touchpad, then we +can expect two following head packets. If the finger status doesn't change, +the following packets would be motion packets, only sending delta of finger +position, until we receive a status packet. + +One exception is one finger touch. when a status packet tells us there is only +one finger, the hardware would just send head packets afterwards. + +7.2.1 Status packet + ~~~~~~~~~~~~~ + +byte 0: + + bit 7 6 5 4 3 2 1 0 + . . . . 0 1 R L + + L, R = 1 when Left, Right mouse button pressed + +byte 1: + + bit 7 6 5 4 3 2 1 0 + . . . ft4 ft3 ft2 ft1 ft0 + + ft4 ft3 ft2 ft1 ft0 ftn = 1 when finger n is on touchpad + +byte 2: not used + +byte 3: + + bit 7 6 5 4 3 2 1 0 + . . . 1 0 0 0 0 + + constant bits + +byte 4: + + bit 7 6 5 4 3 2 1 0 + p . . . . . . . + + p = 1 for palm + +byte 5: not used + +7.2.2 Head packet + ~~~~~~~~~~~ + +byte 0: + + bit 7 6 5 4 3 2 1 0 + w3 w2 w1 w0 0 1 R L + + L, R = 1 when Left, Right mouse button pressed + w3..w0 = finger width (spans how many trace lines) + +byte 1: + + bit 7 6 5 4 3 2 1 0 + p7 p6 p5 p4 x11 x10 x9 x8 + +byte 2: + + bit 7 6 5 4 3 2 1 0 + x7 x6 x5 x4 x3 x2 x1 x0 + + x11..x0 = absolute x value (horizontal) + +byte 3: + + bit 7 6 5 4 3 2 1 0 + id2 id1 id0 1 0 0 0 1 + + id2..id0 = finger id + +byte 4: + + bit 7 6 5 4 3 2 1 0 + p3 p1 p2 p0 y11 y10 y9 y8 + + p7..p0 = pressure + +byte 5: + + bit 7 6 5 4 3 2 1 0 + y7 y6 y5 y4 y3 y2 y1 y0 + + y11..y0 = absolute y value (vertical) + +7.2.3 Motion packet + ~~~~~~~~~~~~~ + +byte 0: + + bit 7 6 5 4 3 2 1 0 + id2 id1 id0 w 0 1 R L + + L, R = 1 when Left, Right mouse button pressed + id2..id0 = finger id + w = 1 when delta overflows (> 127 or < -128), in this case + firmware sends us (delta x / 5) and (delta y / 5) + +byte 1: + + bit 7 6 5 4 3 2 1 0 + x7 x6 x5 x4 x3 x2 x1 x0 + + x7..x0 = delta x (two's complement) + +byte 2: + + bit 7 6 5 4 3 2 1 0 + y7 y6 y5 y4 y3 y2 y1 y0 + + y7..y0 = delta y (two's complement) + +byte 3: + + bit 7 6 5 4 3 2 1 0 + id2 id1 id0 1 0 0 1 0 + + id2..id0 = finger id + +byte 4: + + bit 7 6 5 4 3 2 1 0 + x7 x6 x5 x4 x3 x2 x1 x0 + + x7..x0 = delta x (two's complement) + +byte 5: + + bit 7 6 5 4 3 2 1 0 + y7 y6 y5 y4 y3 y2 y1 y0 + + y7..y0 = delta y (two's complement) + + byte 0 ~ 2 for one finger + byte 3 ~ 5 for another diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt index 71536e78406f..543101c5bf26 100644 --- a/Documentation/input/multi-touch-protocol.txt +++ b/Documentation/input/multi-touch-protocol.txt @@ -65,6 +65,20 @@ the full state of each initiated contact has to reside in the receiving end. Upon receiving an MT event, one simply updates the appropriate attribute of the current slot. +Some devices identify and/or track more contacts than they can report to the +driver. A driver for such a device should associate one type B slot with each +contact that is reported by the hardware. Whenever the identity of the +contact associated with a slot changes, the driver should invalidate that +slot by changing its ABS_MT_TRACKING_ID. If the hardware signals that it is +tracking more contacts than it is currently reporting, the driver should use +a BTN_TOOL_*TAP event to inform userspace of the total number of contacts +being tracked by the hardware at that moment. The driver should do this by +explicitly sending the corresponding BTN_TOOL_*TAP event and setting +use_count to false when calling input_mt_report_pointer_emulation(). +The driver should only advertise as many slots as the hardware can report. +Userspace can detect that a driver can report more total contacts than slots +by noting that the largest supported BTN_TOOL_*TAP event is larger than the +total number of type B slots reported in the absinfo for the ABS_MT_SLOT axis. Protocol Example A ------------------ |