| Seth Forshee | d4b347b | 2011-11-07 19:53:15 -0800 | [diff] [blame] | 1 | ALPS Touchpad Protocol | 
 | 2 | ---------------------- | 
 | 3 |  | 
 | 4 | Introduction | 
 | 5 | ------------ | 
 | 6 |  | 
| Seth Forshee | 7cf801c | 2011-11-07 19:54:35 -0800 | [diff] [blame] | 7 | Currently the ALPS touchpad driver supports four protocol versions in use by | 
 | 8 | ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various | 
 | 9 | protocol versions is contained in the following sections. | 
| Seth Forshee | d4b347b | 2011-11-07 19:53:15 -0800 | [diff] [blame] | 10 |  | 
 | 11 | Detection | 
 | 12 | --------- | 
 | 13 |  | 
 | 14 | All ALPS touchpads should respond to the "E6 report" command sequence: | 
 | 15 | E8-E6-E6-E6-E9. An ALPS touchpad should respond with either 00-00-0A or | 
| Akio Idehara | 99c90ab | 2012-02-24 00:33:22 -0800 | [diff] [blame] | 16 | 00-00-64 if no buttons are pressed. The bits 0-2 of the first byte will be 1s | 
 | 17 | if some buttons are pressed. | 
| Seth Forshee | d4b347b | 2011-11-07 19:53:15 -0800 | [diff] [blame] | 18 |  | 
 | 19 | If the E6 report is successful, the touchpad model is identified using the "E7 | 
 | 20 | report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is | 
 | 21 | matched against known models in the alps_model_data_array. | 
 | 22 |  | 
| Seth Forshee | 7cf801c | 2011-11-07 19:54:35 -0800 | [diff] [blame] | 23 | With protocol versions 3 and 4, the E7 report model signature is always | 
 | 24 | 73-02-64. To differentiate between these versions, the response from the | 
 | 25 | "Enter Command Mode" sequence must be inspected as described below. | 
 | 26 |  | 
 | 27 | Command Mode | 
 | 28 | ------------ | 
 | 29 |  | 
 | 30 | Protocol versions 3 and 4 have a command mode that is used to read and write | 
 | 31 | one-byte device registers in a 16-bit address space. The command sequence | 
 | 32 | EC-EC-EC-E9 places the device in command mode, and the device will respond | 
 | 33 | with 88-07 followed by a third byte. This third byte can be used to determine | 
 | 34 | whether the devices uses the version 3 or 4 protocol. | 
 | 35 |  | 
 | 36 | To exit command mode, PSMOUSE_CMD_SETSTREAM (EA) is sent to the touchpad. | 
 | 37 |  | 
 | 38 | While in command mode, register addresses can be set by first sending a | 
 | 39 | specific command, either EC for v3 devices or F5 for v4 devices. Then the | 
 | 40 | address is sent one nibble at a time, where each nibble is encoded as a | 
 | 41 | command with optional data. This enoding differs slightly between the v3 and | 
 | 42 | v4 protocols. | 
 | 43 |  | 
 | 44 | Once an address has been set, the addressed register can be read by sending | 
 | 45 | PSMOUSE_CMD_GETINFO (E9). The first two bytes of the response contains the | 
 | 46 | address of the register being read, and the third contains the value of the | 
 | 47 | register. Registers are written by writing the value one nibble at a time | 
 | 48 | using the same encoding used for addresses. | 
 | 49 |  | 
| Seth Forshee | d4b347b | 2011-11-07 19:53:15 -0800 | [diff] [blame] | 50 | Packet Format | 
 | 51 | ------------- | 
 | 52 |  | 
| Seth Forshee | 7cf801c | 2011-11-07 19:54:35 -0800 | [diff] [blame] | 53 | In the following tables, the following notation is used. | 
| Seth Forshee | d4b347b | 2011-11-07 19:53:15 -0800 | [diff] [blame] | 54 |  | 
 | 55 |  CAPITALS = stick, miniscules = touchpad | 
 | 56 |  | 
 | 57 | ?'s can have different meanings on different models, such as wheel rotation, | 
 | 58 | extra buttons, stick buttons on a dualpoint, etc. | 
 | 59 |  | 
 | 60 | PS/2 packet format | 
 | 61 | ------------------ | 
 | 62 |  | 
 | 63 |  byte 0:  0    0 YSGN XSGN    1    M    R    L | 
 | 64 |  byte 1: X7   X6   X5   X4   X3   X2   X1   X0 | 
 | 65 |  byte 2: Y7   Y6   Y5   Y4   Y3   Y2   Y1   Y0 | 
 | 66 |  | 
 | 67 | Note that the device never signals overflow condition. | 
 | 68 |  | 
| Seth Forshee | 7cf801c | 2011-11-07 19:54:35 -0800 | [diff] [blame] | 69 | ALPS Absolute Mode - Protocol Verion 1 | 
 | 70 | -------------------------------------- | 
| Seth Forshee | d4b347b | 2011-11-07 19:53:15 -0800 | [diff] [blame] | 71 |  | 
 | 72 |  byte 0:  1    0    0    0    1   x9   x8   x7 | 
 | 73 |  byte 1:  0   x6   x5   x4   x3   x2   x1   x0 | 
 | 74 |  byte 2:  0    ?    ?    l    r    ?  fin  ges | 
 | 75 |  byte 3:  0    ?    ?    ?    ?   y9   y8   y7 | 
 | 76 |  byte 4:  0   y6   y5   y4   y3   y2   y1   y0 | 
 | 77 |  byte 5:  0   z6   z5   z4   z3   z2   z1   z0 | 
 | 78 |  | 
| Seth Forshee | 7cf801c | 2011-11-07 19:54:35 -0800 | [diff] [blame] | 79 | ALPS Absolute Mode - Protocol Version 2 | 
 | 80 | --------------------------------------- | 
| Seth Forshee | d4b347b | 2011-11-07 19:53:15 -0800 | [diff] [blame] | 81 |  | 
 | 82 |  byte 0:  1    ?    ?    ?    1    ?    ?    ? | 
 | 83 |  byte 1:  0   x6   x5   x4   x3   x2   x1   x0 | 
 | 84 |  byte 2:  0  x10   x9   x8   x7    ?  fin  ges | 
 | 85 |  byte 3:  0   y9   y8   y7    1    M    R    L | 
 | 86 |  byte 4:  0   y6   y5   y4   y3   y2   y1   y0 | 
 | 87 |  byte 5:  0   z6   z5   z4   z3   z2   z1   z0 | 
 | 88 |  | 
 | 89 | Dualpoint device -- interleaved packet format | 
 | 90 | --------------------------------------------- | 
 | 91 |  | 
 | 92 |  byte 0:    1    1    0    0    1    1    1    1 | 
 | 93 |  byte 1:    0   x6   x5   x4   x3   x2   x1   x0 | 
 | 94 |  byte 2:    0  x10   x9   x8   x7    0  fin  ges | 
 | 95 |  byte 3:    0    0 YSGN XSGN    1    1    1    1 | 
 | 96 |  byte 4:   X7   X6   X5   X4   X3   X2   X1   X0 | 
 | 97 |  byte 5:   Y7   Y6   Y5   Y4   Y3   Y2   Y1   Y0 | 
 | 98 |  byte 6:    0   y9   y8   y7    1    m    r    l | 
 | 99 |  byte 7:    0   y6   y5   y4   y3   y2   y1   y0 | 
 | 100 |  byte 8:    0   z6   z5   z4   z3   z2   z1   z0 | 
| Seth Forshee | 7cf801c | 2011-11-07 19:54:35 -0800 | [diff] [blame] | 101 |  | 
 | 102 | ALPS Absolute Mode - Protocol Version 3 | 
 | 103 | --------------------------------------- | 
 | 104 |  | 
 | 105 | ALPS protocol version 3 has three different packet formats. The first two are | 
 | 106 | associated with touchpad events, and the third is associatd with trackstick | 
 | 107 | events. | 
 | 108 |  | 
 | 109 | The first type is the touchpad position packet. | 
 | 110 |  | 
 | 111 |  byte 0:    1    ?   x1   x0    1    1    1    1 | 
 | 112 |  byte 1:    0  x10   x9   x8   x7   x6   x5   x4 | 
 | 113 |  byte 2:    0  y10   y9   y8   y7   y6   y5   y4 | 
 | 114 |  byte 3:    0    M    R    L    1    m    r    l | 
 | 115 |  byte 4:    0   mt   x3   x2   y3   y2   y1   y0 | 
 | 116 |  byte 5:    0   z6   z5   z4   z3   z2   z1   z0 | 
 | 117 |  | 
 | 118 | Note that for some devices the trackstick buttons are reported in this packet, | 
 | 119 | and on others it is reported in the trackstick packets. | 
 | 120 |  | 
 | 121 | The second packet type contains bitmaps representing the x and y axes. In the | 
 | 122 | bitmaps a given bit is set if there is a finger covering that position on the | 
 | 123 | given axis. Thus the bitmap packet can be used for low-resolution multi-touch | 
 | 124 | data, although finger tracking is not possible.  This packet also encodes the | 
 | 125 | number of contacts (f1 and f0 in the table below). | 
 | 126 |  | 
 | 127 |  byte 0:    1    1   x1   x0    1    1    1    1 | 
 | 128 |  byte 1:    0   x8   x7   x6   x5   x4   x3   x2 | 
 | 129 |  byte 2:    0   y7   y6   y5   y4   y3   y2   y1 | 
 | 130 |  byte 3:    0  y10   y9   y8    1    1    1    1 | 
 | 131 |  byte 4:    0  x14  x13  x12  x11  x10   x9   y0 | 
 | 132 |  byte 5:    0    1    ?    ?    ?    ?   f1   f0 | 
 | 133 |  | 
 | 134 | This packet only appears after a position packet with the mt bit set, and | 
| Masanari Iida | 40e4712 | 2012-03-04 23:16:11 +0900 | [diff] [blame] | 135 | usually only appears when there are two or more contacts (although | 
 | 136 | occassionally it's seen with only a single contact). | 
| Seth Forshee | 7cf801c | 2011-11-07 19:54:35 -0800 | [diff] [blame] | 137 |  | 
 | 138 | The final v3 packet type is the trackstick packet. | 
 | 139 |  | 
 | 140 |  byte 0:    1    1   x7   y7    1    1    1    1 | 
 | 141 |  byte 1:    0   x6   x5   x4   x3   x2   x1   x0 | 
 | 142 |  byte 2:    0   y6   y5   y4   y3   y2   y1   y0 | 
 | 143 |  byte 3:    0    1    0    0    1    0    0    0 | 
 | 144 |  byte 4:    0   z4   z3   z2   z1   z0    ?    ? | 
 | 145 |  byte 5:    0    0    1    1    1    1    1    1 | 
 | 146 |  | 
 | 147 | ALPS Absolute Mode - Protocol Version 4 | 
 | 148 | --------------------------------------- | 
 | 149 |  | 
 | 150 | Protocol version 4 has an 8-byte packet format. | 
 | 151 |  | 
 | 152 |  byte 0:    1    ?   x1   x0    1    1    1    1 | 
 | 153 |  byte 1:    0  x10   x9   x8   x7   x6   x5   x4 | 
 | 154 |  byte 2:    0  y10   y9   y8   y7   y6   y5   y4 | 
 | 155 |  byte 3:    0    1   x3   x2   y3   y2   y1   y0 | 
 | 156 |  byte 4:    0    ?    ?    ?    1    ?    r    l | 
 | 157 |  byte 5:    0   z6   z5   z4   z3   z2   z1   z0 | 
 | 158 |  byte 6:    bitmap data (described below) | 
 | 159 |  byte 7:    bitmap data (described below) | 
 | 160 |  | 
 | 161 | The last two bytes represent a partial bitmap packet, with 3 full packets | 
 | 162 | required to construct a complete bitmap packet.  Once assembled, the 6-byte | 
 | 163 | bitmap packet has the following format: | 
 | 164 |  | 
 | 165 |  byte 0:    0    1   x7   x6   x5   x4   x3   x2 | 
 | 166 |  byte 1:    0   x1   x0   y4   y3   y2   y1   y0 | 
 | 167 |  byte 2:    0    0    ?  x14  x13  x12  x11  x10 | 
 | 168 |  byte 3:    0   x9   x8   y9   y8   y7   y6   y5 | 
 | 169 |  byte 4:    0    0    0    0    0    0    0    0 | 
 | 170 |  byte 5:    0    0    0    0    0    0    0  y10 | 
 | 171 |  | 
 | 172 | There are several things worth noting here. | 
 | 173 |  | 
 | 174 |  1) In the bitmap data, bit 6 of byte 0 serves as a sync byte to | 
 | 175 |     identify the first fragment of a bitmap packet. | 
 | 176 |  | 
 | 177 |  2) The bitmaps represent the same data as in the v3 bitmap packets, although | 
 | 178 |     the packet layout is different. | 
 | 179 |  | 
 | 180 |  3) There doesn't seem to be a count of the contact points anywhere in the v4 | 
 | 181 |     protocol packets. Deriving a count of contact points must be done by | 
 | 182 |     analyzing the bitmaps. | 
 | 183 |  | 
 | 184 |  4) There is a 3 to 1 ratio of position packets to bitmap packets. Therefore | 
 | 185 |     MT position can only be updated for every third ST position update, and | 
 | 186 |     the count of contact points can only be updated every third packet as | 
 | 187 |     well. | 
 | 188 |  | 
 | 189 | So far no v4 devices with tracksticks have been encountered. |