diff options
Diffstat (limited to 'Documentation/input')
| -rw-r--r-- | Documentation/input/appletouch.txt | 2 | ||||
| -rw-r--r-- | Documentation/input/bcm5974.txt | 2 | ||||
| -rw-r--r-- | Documentation/input/elantech.txt | 8 | ||||
| -rw-r--r-- | Documentation/input/iforce-protocol.txt | 2 | ||||
| -rw-r--r-- | Documentation/input/joystick.txt | 2 | ||||
| -rw-r--r-- | Documentation/input/multi-touch-protocol.txt | 209 | ||||
| -rw-r--r-- | Documentation/input/rotary-encoder.txt | 2 | ||||
| -rw-r--r-- | Documentation/input/sentelic.txt | 126 | ||||
| -rw-r--r-- | Documentation/input/xpad.txt | 2 |
9 files changed, 271 insertions, 84 deletions
diff --git a/Documentation/input/appletouch.txt b/Documentation/input/appletouch.txt index 4f7c633a76d2..b13de3f89108 100644 --- a/Documentation/input/appletouch.txt +++ b/Documentation/input/appletouch.txt @@ -82,4 +82,4 @@ Links: ------ [1]: http://johannes.sipsolutions.net/PowerBook/touchpad/ -[2]: http://web.telia.com/~u89404340/touchpad/index.html +[2]: http://web.archive.org/web/*/http://web.telia.com/~u89404340/touchpad/index.html diff --git a/Documentation/input/bcm5974.txt b/Documentation/input/bcm5974.txt index 5e22dcf6d48d..74d3876d6f34 100644 --- a/Documentation/input/bcm5974.txt +++ b/Documentation/input/bcm5974.txt @@ -62,4 +62,4 @@ Links ----- [1] http://ubuntuforums.org/showthread.php?t=840040 -[2] http://http://bitmath.org/code/ +[2] http://bitmath.org/code/ diff --git a/Documentation/input/elantech.txt b/Documentation/input/elantech.txt index a10c3b6ba7c4..56941ae1f5db 100644 --- a/Documentation/input/elantech.txt +++ b/Documentation/input/elantech.txt @@ -333,14 +333,14 @@ byte 0: byte 1: bit 7 6 5 4 3 2 1 0 - x15 x14 x13 x12 x11 x10 x9 x8 + . . . . . x10 x9 x8 byte 2: bit 7 6 5 4 3 2 1 0 x7 x6 x5 x4 x4 x2 x1 x0 - x15..x0 = absolute x value (horizontal) + x10..x0 = absolute x value (horizontal) byte 3: @@ -350,14 +350,14 @@ byte 3: byte 4: bit 7 6 5 4 3 2 1 0 - y15 y14 y13 y12 y11 y10 y8 y8 + . . . . . . y9 y8 byte 5: bit 7 6 5 4 3 2 1 0 y7 y6 y5 y4 y3 y2 y1 y0 - y15..y0 = absolute y value (vertical) + y9..y0 = absolute y value (vertical) 4.2.2 Two finger touch diff --git a/Documentation/input/iforce-protocol.txt b/Documentation/input/iforce-protocol.txt index 3ac92413c874..2d5fbfd6023e 100644 --- a/Documentation/input/iforce-protocol.txt +++ b/Documentation/input/iforce-protocol.txt @@ -251,7 +251,7 @@ Check www.immerse.com for Immersion Studio, and www.fcoder.com for ComPortSpy. ** Author of this document ** Johann Deneux <johann.deneux@gmail.com> -Home page at http://www.esil.univ-mrs.fr/~jdeneux/projects/ff/ +Home page at http://web.archive.org/web/*/http://www.esil.univ-mrs.fr Additions by Vojtech Pavlik. diff --git a/Documentation/input/joystick.txt b/Documentation/input/joystick.txt index 154d767b2acb..8007b7ca87bf 100644 --- a/Documentation/input/joystick.txt +++ b/Documentation/input/joystick.txt @@ -402,7 +402,7 @@ for the port of the SoundFusion is supported by the cs461x.c module. ~~~~~~~~~~~~~~~~~~~~~~~~ The Live! has a special PCI gameport, which, although it doesn't provide any "Enhanced" stuff like 4DWave and friends, is quite a bit faster than -it's ISA counterparts. It also requires special support, hence the +its ISA counterparts. It also requires special support, hence the emu10k1-gp.c module for it instead of the normal ns558.c one. 3.15 SoundBlaster 64 and 128 - ES1370 and ES1371, ESS Solo1 and S3 SonicVibes diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt index 8490480ce432..bdcba154b83e 100644 --- a/Documentation/input/multi-touch-protocol.txt +++ b/Documentation/input/multi-touch-protocol.txt @@ -6,31 +6,149 @@ Multi-touch (MT) Protocol Introduction ------------ -In order to utilize the full power of the new multi-touch devices, a way to -report detailed finger data to user space is needed. This document -describes the multi-touch (MT) protocol which allows kernel drivers to -report details for an arbitrary number of fingers. +In order to utilize the full power of the new multi-touch and multi-user +devices, a way to report detailed data from multiple contacts, i.e., +objects in direct contact with the device surface, is needed. This +document describes the multi-touch (MT) protocol which allows kernel +drivers to report details for an arbitrary number of contacts. + +The protocol is divided into two types, depending on the capabilities of the +hardware. For devices handling anonymous contacts (type A), the protocol +describes how to send the raw data for all contacts to the receiver. For +devices capable of tracking identifiable contacts (type B), the protocol +describes how to send updates for individual contacts via event slots. + + +Protocol Usage +-------------- + +Contact details are sent sequentially as separate packets of ABS_MT +events. Only the ABS_MT events are recognized as part of a contact +packet. Since these events are ignored by current single-touch (ST) +applications, the MT protocol can be implemented on top of the ST protocol +in an existing driver. + +Drivers for type A devices separate contact packets by calling +input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT +event, which instructs the receiver to accept the data for the current +contact and prepare to receive another. + +Drivers for type B devices separate contact packets by calling +input_mt_slot(), with a slot as argument, at the beginning of each packet. +This generates an ABS_MT_SLOT event, which instructs the receiver to +prepare for updates of the given slot. + +All drivers mark the end of a multi-touch transfer by calling the usual +input_sync() function. This instructs the receiver to act upon events +accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set +of events/packets. + +The main difference between the stateless type A protocol and the stateful +type B slot protocol lies in the usage of identifiable contacts to reduce +the amount of data sent to userspace. The slot protocol requires the use of +the ABS_MT_TRACKING_ID, either provided by the hardware or computed from +the raw data [5]. + +For type A devices, the kernel driver should generate an arbitrary +enumeration of the full set of anonymous contacts currently on the +surface. The order in which the packets appear in the event stream is not +important. Event filtering and finger tracking is left to user space [3]. + +For type B devices, the kernel driver should associate a slot with each +identified contact, and use that slot to propagate changes for the contact. +Creation, replacement and destruction of contacts is achieved by modifying +the ABS_MT_TRACKING_ID of the associated slot. A non-negative tracking id +is interpreted as a contact, and the value -1 denotes an unused slot. A +tracking id not previously present is considered new, and a tracking id no +longer present is considered removed. Since only changes are propagated, +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. + + +Protocol Example A +------------------ + +Here is what a minimal event sequence for a two-contact touch would look +like for a type A device: + + ABS_MT_POSITION_X x[0] + ABS_MT_POSITION_Y y[0] + SYN_MT_REPORT + ABS_MT_POSITION_X x[1] + ABS_MT_POSITION_Y y[1] + SYN_MT_REPORT + SYN_REPORT +The sequence after moving one of the contacts looks exactly the same; the +raw data for all present contacts are sent between every synchronization +with SYN_REPORT. -Usage ------ +Here is the sequence after lifting the first contact: -Anonymous finger details are sent sequentially as separate packets of ABS -events. Only the ABS_MT events are recognized as part of a finger -packet. The end of a packet is marked by calling the input_mt_sync() -function, which generates a SYN_MT_REPORT event. This instructs the -receiver to accept the data for the current finger and prepare to receive -another. The end of a multi-touch transfer is marked by calling the usual -input_sync() function. This instructs the receiver to act upon events -accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new -set of events/packets. + ABS_MT_POSITION_X x[1] + ABS_MT_POSITION_Y y[1] + SYN_MT_REPORT + SYN_REPORT + +And here is the sequence after lifting the second contact: + + SYN_MT_REPORT + SYN_REPORT + +If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the +ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the +last SYN_REPORT will be dropped by the input core, resulting in no +zero-contact event reaching userland. + + +Protocol Example B +------------------ + +Here is what a minimal event sequence for a two-contact touch would look +like for a type B device: + + ABS_MT_SLOT 0 + ABS_MT_TRACKING_ID 45 + ABS_MT_POSITION_X x[0] + ABS_MT_POSITION_Y y[0] + ABS_MT_SLOT 1 + ABS_MT_TRACKING_ID 46 + ABS_MT_POSITION_X x[1] + ABS_MT_POSITION_Y y[1] + SYN_REPORT + +Here is the sequence after moving contact 45 in the x direction: + + ABS_MT_SLOT 0 + ABS_MT_POSITION_X x[0] + SYN_REPORT + +Here is the sequence after lifting the contact in slot 0: + + ABS_MT_TRACKING_ID -1 + SYN_REPORT + +The slot being modified is already 0, so the ABS_MT_SLOT is omitted. The +message removes the association of slot 0 with contact 45, thereby +destroying contact 45 and freeing slot 0 to be reused for another contact. + +Finally, here is the sequence after lifting the second contact: + + ABS_MT_SLOT 1 + ABS_MT_TRACKING_ID -1 + SYN_REPORT + + +Event Usage +----------- A set of ABS_MT events with the desired properties is defined. The events are divided into categories, to allow for partial implementation. The minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which -allows for multiple fingers to be tracked. If the device supports it, the +allows for multiple contacts to be tracked. If the device supports it, the ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size -of the contact area and approaching finger, respectively. +of the contact area and approaching contact, respectively. The TOUCH and WIDTH parameters have a geometrical interpretation; imagine looking through a window at someone gently holding a finger against the @@ -41,40 +159,26 @@ ABS_MT_TOUCH_MAJOR, the diameter of the outer region is ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder against the glass. The inner region will increase, and in general, the ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than -unity, is related to the finger pressure. For pressure-based devices, +unity, is related to the contact pressure. For pressure-based devices, ABS_MT_PRESSURE may be used to provide the pressure on the contact area instead. -In addition to the MAJOR parameters, the oval shape of the finger can be +In addition to the MAJOR parameters, the oval shape of the contact can be described by adding the MINOR parameters, such that MAJOR and MINOR are the major and minor axis of an ellipse. Finally, the orientation of the oval shape can be describe with the ORIENTATION parameter. The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a -finger or a pen or something else. Devices with more granular information +contact or a pen or something else. Devices with more granular information may specify general shapes as blobs, i.e., as a sequence of rectangular shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices that currently support it, the ABS_MT_TRACKING_ID event may be used to -report finger tracking from hardware [5]. - -Here is what a minimal event sequence for a two-finger touch would look -like: - - ABS_MT_POSITION_X - ABS_MT_POSITION_Y - SYN_MT_REPORT - ABS_MT_POSITION_X - ABS_MT_POSITION_Y - SYN_MT_REPORT - SYN_REPORT +report contact tracking from hardware [5]. Event Semantics --------------- -The word "contact" is used to describe a tool which is in direct contact -with the surface. A finger, a pen or a rubber all classify as contacts. - ABS_MT_TOUCH_MAJOR The length of the major axis of the contact. The length should be given in @@ -141,15 +245,16 @@ MT_TOOL_PEN [2]. ABS_MT_BLOB_ID The BLOB_ID groups several packets together into one arbitrarily shaped -contact. This is a low-level anonymous grouping, and should not be confused -with the high-level trackingID [5]. Most kernel drivers will not have blob -capability, and can safely omit the event. +contact. This is a low-level anonymous grouping for type A devices, and +should not be confused with the high-level trackingID [5]. Most type A +devices do not have blob capability, so drivers can safely omit this event. ABS_MT_TRACKING_ID The TRACKING_ID identifies an initiated contact throughout its life cycle -[5]. There are currently only a few devices that support it, so this event -should normally be omitted. +[5]. This event is mandatory for type B devices. The value range of the +TRACKING_ID should be large enough to ensure unique identification of a +contact maintained over an extended period of time. Event Computation @@ -176,20 +281,11 @@ finger along the X axis (1). Finger Tracking --------------- -The kernel driver should generate an arbitrary enumeration of the set of -anonymous contacts currently on the surface. The order in which the packets -appear in the event stream is not important. - The process of finger tracking, i.e., to assign a unique trackingID to each -initiated contact on the surface, is left to user space; preferably the -multi-touch X driver [3]. In that driver, the trackingID stays the same and -unique until the contact vanishes (when the finger leaves the surface). The -problem of assigning a set of anonymous fingers to a set of identified -fingers is a euclidian bipartite matching problem at each event update, and -relies on a sufficiently rapid update rate. - -There are a few devices that support trackingID in hardware. User space can -make use of these native identifiers to reduce bandwidth and cpu usage. +initiated contact on the surface, is a Euclidian Bipartite Matching +problem. At each event synchronization, the set of actual contacts is +matched to the set of contacts from the previous synchronization. A full +implementation can be found in [3]. Gestures @@ -217,11 +313,6 @@ where examples can be found. difference between the contact position and the approaching tool position could be used to derive tilt. [2] The list can of course be extended. -[3] The multi-touch X driver is currently in the prototyping stage. At the -time of writing (April 2009), the MT protocol is not yet merged, and the -prototype implements finger matching, basic mouse support and two-finger -scrolling. The project aims at improving the quality of current multi-touch -functionality available in the Synaptics X driver, and in addition -implement more advanced gestures. +[3] Multitouch X driver project: http://bitmath.org/code/multitouch/. [4] See the section on event computation. [5] See the section on finger tracking. diff --git a/Documentation/input/rotary-encoder.txt b/Documentation/input/rotary-encoder.txt index 3a6aec40c0b0..8b4129de1d2d 100644 --- a/Documentation/input/rotary-encoder.txt +++ b/Documentation/input/rotary-encoder.txt @@ -75,7 +75,7 @@ and the number of steps or will clamp at the maximum and zero depending on the configuration. Because GPIO to IRQ mapping is platform specific, this information must -be given in seperately to the driver. See the example below. +be given in separately to the driver. See the example below. ---------<snip>--------- diff --git a/Documentation/input/sentelic.txt b/Documentation/input/sentelic.txt index f7160a2fb6a2..b2ef125b71f8 100644 --- a/Documentation/input/sentelic.txt +++ b/Documentation/input/sentelic.txt @@ -1,5 +1,5 @@ -Copyright (C) 2002-2008 Sentelic Corporation. -Last update: Oct-31-2008 +Copyright (C) 2002-2010 Sentelic Corporation. +Last update: Jan-13-2010 ============================================================================== * Finger Sensing Pad Intellimouse Mode(scrolling wheel, 4th and 5th buttons) @@ -44,7 +44,7 @@ B) MSID 6: Horizontal and Vertical scrolling. Packet 1 Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| - 1 |Y|X|y|x|1|M|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 | | |B|F|l|r|u|d| + 1 |Y|X|y|x|1|M|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 | | |B|F|r|l|u|d| |---------------| |---------------| |---------------| |---------------| Byte 1: Bit7 => Y overflow @@ -59,15 +59,15 @@ Byte 2: X Movement(9-bit 2's complement integers) Byte 3: Y Movement(9-bit 2's complement integers) Byte 4: Bit0 => the Vertical scrolling movement downward. Bit1 => the Vertical scrolling movement upward. - Bit2 => the Vertical scrolling movement rightward. - Bit3 => the Vertical scrolling movement leftward. + Bit2 => the Horizontal scrolling movement leftward. + Bit3 => the Horizontal scrolling movement rightward. Bit4 => 1 = 4th mouse button is pressed, Forward one page. 0 = 4th mouse button is not pressed. Bit5 => 1 = 5th mouse button is pressed, Backward one page. 0 = 5th mouse button is not pressed. C) MSID 7: -# FSP uses 2 packets(8 Bytes) data to represent Absolute Position +# FSP uses 2 packets (8 Bytes) to represent Absolute Position. so we have PACKET NUMBER to identify packets. If PACKET NUMBER is 0, the packet is Packet 1. If PACKET NUMBER is 1, the packet is Packet 2. @@ -129,7 +129,7 @@ Byte 3: Message Type => 0x00 (Disabled) Byte 4: Bit7~Bit0 => Don't Care ============================================================================== -* Absolute position for STL3888-A0. +* Absolute position for STL3888-Ax. ============================================================================== Packet 1 (ABSOLUTE POSITION) Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 @@ -179,14 +179,14 @@ Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0]) Bit5~Bit4 => y2_g Bit7~Bit6 => x2_g -Notify Packet for STL3888-A0 +Notify Packet for STL3888-Ax Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| 1 |1|0|1|P|1|M|R|L| 2 |C|C|C|C|C|C|C|C| 3 |0|0|F|F|0|0|0|i| 4 |r|l|d|u|0|0|0|0| |---------------| |---------------| |---------------| |---------------| Byte 1: Bit7~Bit6 => 00, Normal data packet - => 01, Absolute coordination packet + => 01, Absolute coordinates packet => 10, Notify packet Bit5 => 1 Bit4 => when in absolute coordinates mode (valid when EN_PKT_GO is 1): @@ -205,15 +205,106 @@ Byte 4: Bit7 => scroll right button Bit6 => scroll left button Bit5 => scroll down button Bit4 => scroll up button - * Note that if gesture and additional button (Bit4~Bit7) - happen at the same time, the button information will not - be sent. + * Note that if gesture and additional buttoni (Bit4~Bit7) + happen at the same time, the button information will not + be sent. + Bit3~Bit0 => Reserved + +Sample sequence of Multi-finger, Multi-coordinate mode: + + notify packet (valid bit == 1), abs pkt 1, abs pkt 2, abs pkt 1, + abs pkt 2, ..., notify packet (valid bit == 0) + +============================================================================== +* Absolute position for STL3888-B0. +============================================================================== +Packet 1(ABSOLUTE POSITION) + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |0|1|V|F|1|0|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |r|l|u|d|X|X|Y|Y| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordinates packet + => 10, Notify packet + Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up. + When both fingers are up, the last two reports have zero valid + bit. + Bit4 => finger up/down information. 1: finger down, 0: finger up. + Bit3 => 1 + Bit2 => finger index, 0 is the first finger, 1 is the second finger. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: X coordinate (xpos[9:2]) +Byte 3: Y coordinate (ypos[9:2]) +Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0]) + Bit3~Bit2 => X coordinate (ypos[1:0]) + Bit4 => scroll down button + Bit5 => scroll up button + Bit6 => scroll left button + Bit7 => scroll right button + +Packet 2 (ABSOLUTE POSITION) + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |0|1|V|F|1|1|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |r|l|u|d|X|X|Y|Y| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordination packet + => 10, Notify packet + Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up. + When both fingers are up, the last two reports have zero valid + bit. + Bit4 => finger up/down information. 1: finger down, 0: finger up. + Bit3 => 1 + Bit2 => finger index, 0 is the first finger, 1 is the second finger. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: X coordinate (xpos[9:2]) +Byte 3: Y coordinate (ypos[9:2]) +Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0]) + Bit3~Bit2 => X coordinate (ypos[1:0]) + Bit4 => scroll down button + Bit5 => scroll up button + Bit6 => scroll left button + Bit7 => scroll right button + +Notify Packet for STL3888-B0 + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |1|0|1|P|1|M|R|L| 2 |C|C|C|C|C|C|C|C| 3 |0|0|F|F|0|0|0|i| 4 |r|l|u|d|0|0|0|0| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordination packet + => 10, Notify packet + Bit5 => 1 + Bit4 => when in absolute coordinate mode (valid when EN_PKT_GO is 1): + 0: left button is generated by the on-pad command + 1: left button is generated by the external button + Bit3 => 1 + Bit2 => Middle Button, 1 is pressed, 0 is not pressed. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: Message Type => 0xB7 (Multi Finger, Multi Coordinate mode) +Byte 3: Bit7~Bit6 => Don't care + Bit5~Bit4 => Number of fingers + Bit3~Bit1 => Reserved + Bit0 => 1: enter gesture mode; 0: leaving gesture mode +Byte 4: Bit7 => scroll right button + Bit6 => scroll left button + Bit5 => scroll up button + Bit4 => scroll down button + * Note that if gesture and additional button(Bit4~Bit7) + happen at the same time, the button information will not + be sent. Bit3~Bit0 => Reserved Sample sequence of Multi-finger, Multi-coordinate mode: notify packet (valid bit == 1), abs pkt 1, abs pkt 2, abs pkt 1, - abs pkt 2, ..., notify packet(valid bit == 0) + abs pkt 2, ..., notify packet (valid bit == 0) ============================================================================== * FSP Enable/Disable packet @@ -250,7 +341,7 @@ Byte 5~8: Don't care (Absolute packet) FSP supports basic PS/2 commanding set and modes, refer to following URL for details about PS/2 commands: -http://www.computer-engineering.org/index.php?title=PS/2_Mouse_Interface +http://www.computer-engineering.org/ps2mouse/ ============================================================================== * Programming Sequence for Determining Packet Parsing Flow @@ -409,7 +500,8 @@ offset width default r/w name 0: read only, 1: read/write enable (Note that following registers does not require clock gating being enabled prior to write: 05 06 07 08 09 0c 0f 10 11 12 16 17 18 23 2e - 40 41 42 43.) + 40 41 42 43. In addition to that, this bit must be 1 when gesture + mode is enabled) 0x31 RW on-pad command detection bit7 0 RW on-pad command left button down tag @@ -463,6 +555,10 @@ offset width default r/w name absolute coordinates; otherwise, host only receives packets with relative coordinate.) + bit7 0 RW EN_PS2_F2: PS/2 gesture mode 2nd + finger packet enable + 0: disable, 1: enable + 0x43 RW on-pad control bit0 0 RW on-pad control enable 0: disable, 1: enable diff --git a/Documentation/input/xpad.txt b/Documentation/input/xpad.txt index aae0d404c566..7cc9a436e6a1 100644 --- a/Documentation/input/xpad.txt +++ b/Documentation/input/xpad.txt @@ -150,7 +150,7 @@ the basic functionality. 1. http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki) 2. http://xpad.xbox-scene.com/ -3. http://www.xboxhackz.com/Hackz-Reference.htm +3. http://www.markosweb.com/www/xboxhackz.com/ 4. /proc/bus/usb/devices - dump from InterAct PowerPad Pro (Germany): |