]>
Commit | Line | Data |
---|---|---|
2a0bd75e AO |
1 | Elantech Touchpad Driver |
2 | ======================== | |
3 | ||
4 | Copyright (C) 2007-2008 Arjan Opmeer <arjan@opmeer.net> | |
5 | ||
6 | Extra information for hardware version 1 found and | |
7 | provided by Steve Havelka | |
8 | ||
9 | Version 2 (EeePC) hardware support based on patches | |
10 | received from Woody at Xandros and forwarded to me | |
11 | by user StewieGriffin at the eeeuser.com forum | |
12 | ||
13 | ||
14 | Contents | |
15 | ~~~~~~~~ | |
16 | ||
17 | 1. Introduction | |
18 | 2. Extra knobs | |
28f49616 JD |
19 | 3. Differentiating hardware versions |
20 | 4. Hardware version 1 | |
2a0bd75e | 21 | 4.1 Registers |
28f49616 JD |
22 | 4.2 Native relative mode 4 byte packet format |
23 | 4.3 Native absolute mode 4 byte packet format | |
24 | 5. Hardware version 2 | |
25 | 5.1 Registers | |
26 | 5.2 Native absolute mode 6 byte packet format | |
27 | 5.2.1 Parity checking and packet re-synchronization | |
28 | 5.2.2 One/Three finger touch | |
29 | 5.2.3 Two finger touch | |
30 | 6. Hardware version 3 | |
31 | 6.1 Registers | |
32 | 6.2 Native absolute mode 6 byte packet format | |
33 | 6.2.1 One/Three finger touch | |
34 | 6.2.2 Two finger touch | |
1dc6edec JD |
35 | 7. Hardware version 4 |
36 | 7.1 Registers | |
37 | 7.2 Native absolute mode 6 byte packet format | |
38 | 7.2.1 Status packet | |
39 | 7.2.2 Head packet | |
40 | 7.2.3 Motion packet | |
c6c748ef UDB |
41 | 8. Trackpoint (for Hardware version 3 and 4) |
42 | 8.1 Registers | |
43 | 8.2 Native relative mode 6 byte packet format | |
44 | 8.2.1 Status Packet | |
2a0bd75e AO |
45 | |
46 | ||
47 | ||
48 | 1. Introduction | |
49 | ~~~~~~~~~~~~ | |
50 | ||
c6c748ef UDB |
51 | Currently the Linux Elantech touchpad driver is aware of four different |
52 | hardware versions unimaginatively called version 1,version 2, version 3 | |
53 | and version 4. Version 1 is found in "older" laptops and uses 4 bytes per | |
54 | packet. Version 2 seems to be introduced with the EeePC and uses 6 bytes | |
55 | per packet, and provides additional features such as position of two fingers, | |
56 | and width of the touch. Hardware version 3 uses 6 bytes per packet (and | |
57 | for 2 fingers the concatenation of two 6 bytes packets) and allows tracking | |
58 | of up to 3 fingers. Hardware version 4 uses 6 bytes per packet, and can | |
59 | combine a status packet with multiple head or motion packets. Hardware version | |
60 | 4 allows tracking up to 5 fingers. | |
61 | ||
62 | Some Hardware version 3 and version 4 also have a trackpoint which uses a | |
63 | separate packet format. It is also 6 bytes per packet. | |
2a0bd75e AO |
64 | |
65 | The driver tries to support both hardware versions and should be compatible | |
66 | with the Xorg Synaptics touchpad driver and its graphical configuration | |
67 | utilities. | |
68 | ||
c6c748ef UDB |
69 | Note that a mouse button is also associated with either the touchpad or the |
70 | trackpoint when a trackpoint is available. Disabling the Touchpad in xorg | |
71 | (TouchPadOff=0) will also disable the buttons associated with the touchpad. | |
72 | ||
2a0bd75e AO |
73 | Additionally the operation of the touchpad can be altered by adjusting the |
74 | contents of some of its internal registers. These registers are represented | |
75 | by the driver as sysfs entries under /sys/bus/serio/drivers/psmouse/serio? | |
76 | that can be read from and written to. | |
77 | ||
78 | Currently only the registers for hardware version 1 are somewhat understood. | |
79 | Hardware version 2 seems to use some of the same registers but it is not | |
80 | known whether the bits in the registers represent the same thing or might | |
81 | have changed their meaning. | |
82 | ||
83 | On top of that, some register settings have effect only when the touchpad is | |
84 | in relative mode and not in absolute mode. As the Linux Elantech touchpad | |
85 | driver always puts the hardware into absolute mode not all information | |
86 | mentioned below can be used immediately. But because there is no freely | |
87 | available Elantech documentation the information is provided here anyway for | |
88 | completeness sake. | |
89 | ||
90 | ||
91 | ///////////////////////////////////////////////////////////////////////////// | |
92 | ||
93 | ||
94 | 2. Extra knobs | |
95 | ~~~~~~~~~~~ | |
96 | ||
c6c748ef | 97 | Currently the Linux Elantech touchpad driver provides three extra knobs under |
2a0bd75e AO |
98 | /sys/bus/serio/drivers/psmouse/serio? for the user. |
99 | ||
100 | * debug | |
101 | ||
102 | Turn different levels of debugging ON or OFF. | |
103 | ||
104 | By echoing "0" to this file all debugging will be turned OFF. | |
105 | ||
106 | Currently a value of "1" will turn on some basic debugging and a value of | |
107 | "2" will turn on packet debugging. For hardware version 1 the default is | |
108 | OFF. For version 2 the default is "1". | |
109 | ||
110 | Turning packet debugging on will make the driver dump every packet | |
111 | received to the syslog before processing it. Be warned that this can | |
112 | generate quite a lot of data! | |
113 | ||
114 | * paritycheck | |
115 | ||
116 | Turns parity checking ON or OFF. | |
117 | ||
118 | By echoing "0" to this file parity checking will be turned OFF. Any | |
119 | non-zero value will turn it ON. For hardware version 1 the default is ON. | |
120 | For version 2 the default it is OFF. | |
121 | ||
122 | Hardware version 1 provides basic data integrity verification by | |
123 | calculating a parity bit for the last 3 bytes of each packet. The driver | |
124 | can check these bits and reject any packet that appears corrupted. Using | |
125 | this knob you can bypass that check. | |
126 | ||
71c6d188 ÉP |
127 | Hardware version 2 does not provide the same parity bits. Only some basic |
128 | data consistency checking can be done. For now checking is disabled by | |
129 | default. Currently even turning it on will do nothing. | |
2a0bd75e | 130 | |
c6c748ef UDB |
131 | * crc_enabled |
132 | ||
133 | Sets crc_enabled to 0/1. The name "crc_enabled" is the official name of | |
134 | this integrity check, even though it is not an actual cyclic redundancy | |
135 | check. | |
136 | ||
137 | Depending on the state of crc_enabled, certain basic data integrity | |
138 | verification is done by the driver on hardware version 3 and 4. The | |
139 | driver will reject any packet that appears corrupted. Using this knob, | |
140 | The state of crc_enabled can be altered with this knob. | |
141 | ||
142 | Reading the crc_enabled value will show the active value. Echoing | |
143 | "0" or "1" to this file will set the state to "0" or "1". | |
144 | ||
2a0bd75e AO |
145 | ///////////////////////////////////////////////////////////////////////////// |
146 | ||
71c6d188 ÉP |
147 | 3. Differentiating hardware versions |
148 | ================================= | |
149 | ||
150 | To detect the hardware version, read the version number as param[0].param[1].param[2] | |
151 | ||
152 | 4 bytes version: (after the arrow is the name given in the Dell-provided driver) | |
153 | 02.00.22 => EF013 | |
154 | 02.06.00 => EF019 | |
155 | In the wild, there appear to be more versions, such as 00.01.64, 01.00.21, | |
156 | 02.00.00, 02.00.04, 02.00.06. | |
157 | ||
158 | 6 bytes: | |
159 | 02.00.30 => EF113 | |
160 | 02.08.00 => EF023 | |
161 | 02.08.XX => EF123 | |
162 | 02.0B.00 => EF215 | |
163 | 04.01.XX => Scroll_EF051 | |
164 | 04.02.XX => EF051 | |
165 | In the wild, there appear to be more versions, such as 04.03.01, 04.04.11. There | |
166 | appears to be almost no difference, except for EF113, which does not report | |
167 | pressure/width and has different data consistency checks. | |
168 | ||
169 | Probably all the versions with param[0] <= 01 can be considered as | |
170 | 4 bytes/firmware 1. The versions < 02.08.00, with the exception of 02.00.30, as | |
171 | 4 bytes/firmware 2. Everything >= 02.08.00 can be considered as 6 bytes. | |
172 | ||
173 | ///////////////////////////////////////////////////////////////////////////// | |
2a0bd75e | 174 | |
71c6d188 | 175 | 4. Hardware version 1 |
2a0bd75e AO |
176 | ================== |
177 | ||
71c6d188 | 178 | 4.1 Registers |
2a0bd75e AO |
179 | ~~~~~~~~~ |
180 | ||
181 | By echoing a hexadecimal value to a register it contents can be altered. | |
182 | ||
183 | For example: | |
184 | ||
185 | echo -n 0x16 > reg_10 | |
186 | ||
187 | * reg_10 | |
188 | ||
189 | bit 7 6 5 4 3 2 1 0 | |
190 | B C T D L A S E | |
191 | ||
192 | E: 1 = enable smart edges unconditionally | |
193 | S: 1 = enable smart edges only when dragging | |
194 | A: 1 = absolute mode (needs 4 byte packets, see reg_11) | |
195 | L: 1 = enable drag lock (see reg_22) | |
196 | D: 1 = disable dynamic resolution | |
197 | T: 1 = disable tapping | |
198 | C: 1 = enable corner tap | |
199 | B: 1 = swap left and right button | |
200 | ||
201 | * reg_11 | |
202 | ||
203 | bit 7 6 5 4 3 2 1 0 | |
204 | 1 0 0 H V 1 F P | |
205 | ||
206 | P: 1 = enable parity checking for relative mode | |
207 | F: 1 = enable native 4 byte packet mode | |
208 | V: 1 = enable vertical scroll area | |
209 | H: 1 = enable horizontal scroll area | |
210 | ||
211 | * reg_20 | |
212 | ||
213 | single finger width? | |
214 | ||
215 | * reg_21 | |
216 | ||
217 | scroll area width (small: 0x40 ... wide: 0xff) | |
218 | ||
219 | * reg_22 | |
220 | ||
221 | drag lock time out (short: 0x14 ... long: 0xfe; | |
222 | 0xff = tap again to release) | |
223 | ||
224 | * reg_23 | |
225 | ||
226 | tap make timeout? | |
227 | ||
228 | * reg_24 | |
229 | ||
230 | tap release timeout? | |
231 | ||
232 | * reg_25 | |
233 | ||
234 | smart edge cursor speed (0x02 = slow, 0x03 = medium, 0x04 = fast) | |
235 | ||
236 | * reg_26 | |
237 | ||
238 | smart edge activation area width? | |
239 | ||
240 | ||
71c6d188 | 241 | 4.2 Native relative mode 4 byte packet format |
2a0bd75e AO |
242 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
243 | ||
244 | byte 0: | |
245 | bit 7 6 5 4 3 2 1 0 | |
246 | c c p2 p1 1 M R L | |
247 | ||
248 | L, R, M = 1 when Left, Right, Middle mouse button pressed | |
249 | some models have M as byte 3 odd parity bit | |
250 | when parity checking is enabled (reg_11, P = 1): | |
251 | p1..p2 = byte 1 and 2 odd parity bit | |
252 | c = 1 when corner tap detected | |
253 | ||
254 | byte 1: | |
255 | bit 7 6 5 4 3 2 1 0 | |
256 | dx7 dx6 dx5 dx4 dx3 dx2 dx1 dx0 | |
257 | ||
258 | dx7..dx0 = x movement; positive = right, negative = left | |
259 | byte 1 = 0xf0 when corner tap detected | |
260 | ||
261 | byte 2: | |
262 | bit 7 6 5 4 3 2 1 0 | |
263 | dy7 dy6 dy5 dy4 dy3 dy2 dy1 dy0 | |
264 | ||
265 | dy7..dy0 = y movement; positive = up, negative = down | |
266 | ||
267 | byte 3: | |
268 | parity checking enabled (reg_11, P = 1): | |
269 | ||
270 | bit 7 6 5 4 3 2 1 0 | |
271 | w h n1 n0 ds3 ds2 ds1 ds0 | |
272 | ||
273 | normally: | |
274 | ds3..ds0 = scroll wheel amount and direction | |
275 | positive = down or left | |
276 | negative = up or right | |
277 | when corner tap detected: | |
278 | ds0 = 1 when top right corner tapped | |
279 | ds1 = 1 when bottom right corner tapped | |
280 | ds2 = 1 when bottom left corner tapped | |
281 | ds3 = 1 when top left corner tapped | |
282 | n1..n0 = number of fingers on touchpad | |
283 | only models with firmware 2.x report this, models with | |
284 | firmware 1.x seem to map one, two and three finger taps | |
285 | directly to L, M and R mouse buttons | |
286 | h = 1 when horizontal scroll action | |
287 | w = 1 when wide finger touch? | |
288 | ||
289 | otherwise (reg_11, P = 0): | |
290 | ||
291 | bit 7 6 5 4 3 2 1 0 | |
292 | ds7 ds6 ds5 ds4 ds3 ds2 ds1 ds0 | |
293 | ||
294 | ds7..ds0 = vertical scroll amount and direction | |
295 | negative = up | |
296 | positive = down | |
297 | ||
298 | ||
71c6d188 | 299 | 4.3 Native absolute mode 4 byte packet format |
2a0bd75e AO |
300 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
301 | ||
71c6d188 ÉP |
302 | EF013 and EF019 have a special behaviour (due to a bug in the firmware?), and |
303 | when 1 finger is touching, the first 2 position reports must be discarded. | |
304 | This counting is reset whenever a different number of fingers is reported. | |
305 | ||
2a0bd75e AO |
306 | byte 0: |
307 | firmware version 1.x: | |
308 | ||
309 | bit 7 6 5 4 3 2 1 0 | |
310 | D U p1 p2 1 p3 R L | |
311 | ||
312 | L, R = 1 when Left, Right mouse button pressed | |
313 | p1..p3 = byte 1..3 odd parity bit | |
314 | D, U = 1 when rocker switch pressed Up, Down | |
315 | ||
316 | firmware version 2.x: | |
317 | ||
318 | bit 7 6 5 4 3 2 1 0 | |
319 | n1 n0 p2 p1 1 p3 R L | |
320 | ||
321 | L, R = 1 when Left, Right mouse button pressed | |
322 | p1..p3 = byte 1..3 odd parity bit | |
323 | n1..n0 = number of fingers on touchpad | |
324 | ||
325 | byte 1: | |
326 | firmware version 1.x: | |
327 | ||
328 | bit 7 6 5 4 3 2 1 0 | |
329 | f 0 th tw x9 x8 y9 y8 | |
330 | ||
331 | tw = 1 when two finger touch | |
332 | th = 1 when three finger touch | |
333 | f = 1 when finger touch | |
334 | ||
335 | firmware version 2.x: | |
336 | ||
337 | bit 7 6 5 4 3 2 1 0 | |
338 | . . . . x9 x8 y9 y8 | |
339 | ||
340 | byte 2: | |
341 | bit 7 6 5 4 3 2 1 0 | |
342 | x7 x6 x5 x4 x3 x2 x1 x0 | |
343 | ||
344 | x9..x0 = absolute x value (horizontal) | |
345 | ||
346 | byte 3: | |
347 | bit 7 6 5 4 3 2 1 0 | |
348 | y7 y6 y5 y4 y3 y2 y1 y0 | |
349 | ||
350 | y9..y0 = absolute y value (vertical) | |
351 | ||
352 | ||
353 | ///////////////////////////////////////////////////////////////////////////// | |
354 | ||
355 | ||
71c6d188 | 356 | 5. Hardware version 2 |
2a0bd75e AO |
357 | ================== |
358 | ||
359 | ||
71c6d188 | 360 | 5.1 Registers |
2a0bd75e AO |
361 | ~~~~~~~~~ |
362 | ||
363 | By echoing a hexadecimal value to a register it contents can be altered. | |
364 | ||
365 | For example: | |
366 | ||
367 | echo -n 0x56 > reg_10 | |
368 | ||
369 | * reg_10 | |
370 | ||
371 | bit 7 6 5 4 3 2 1 0 | |
372 | 0 1 0 1 0 1 D 0 | |
373 | ||
374 | D: 1 = enable drag and drop | |
375 | ||
376 | * reg_11 | |
377 | ||
378 | bit 7 6 5 4 3 2 1 0 | |
379 | 1 0 0 0 S 0 1 0 | |
380 | ||
381 | S: 1 = enable vertical scroll | |
382 | ||
383 | * reg_21 | |
384 | ||
385 | unknown (0x00) | |
386 | ||
387 | * reg_22 | |
388 | ||
389 | drag and drop release time out (short: 0x70 ... long 0x7e; | |
390 | 0x7f = never i.e. tap again to release) | |
391 | ||
392 | ||
71c6d188 | 393 | 5.2 Native absolute mode 6 byte packet format |
2a0bd75e | 394 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
71c6d188 ÉP |
395 | 5.2.1 Parity checking and packet re-synchronization |
396 | There is no parity checking, however some consistency checks can be performed. | |
397 | ||
398 | For instance for EF113: | |
399 | SA1= packet[0]; | |
400 | A1 = packet[1]; | |
401 | B1 = packet[2]; | |
402 | SB1= packet[3]; | |
403 | C1 = packet[4]; | |
404 | D1 = packet[5]; | |
405 | if( (((SA1 & 0x3C) != 0x3C) && ((SA1 & 0xC0) != 0x80)) || // check Byte 1 | |
406 | (((SA1 & 0x0C) != 0x0C) && ((SA1 & 0xC0) == 0x80)) || // check Byte 1 (one finger pressed) | |
407 | (((SA1 & 0xC0) != 0x80) && (( A1 & 0xF0) != 0x00)) || // check Byte 2 | |
408 | (((SB1 & 0x3E) != 0x38) && ((SA1 & 0xC0) != 0x80)) || // check Byte 4 | |
409 | (((SB1 & 0x0E) != 0x08) && ((SA1 & 0xC0) == 0x80)) || // check Byte 4 (one finger pressed) | |
410 | (((SA1 & 0xC0) != 0x80) && (( C1 & 0xF0) != 0x00)) ) // check Byte 5 | |
411 | // error detected | |
412 | ||
413 | For all the other ones, there are just a few constant bits: | |
414 | if( ((packet[0] & 0x0C) != 0x04) || | |
415 | ((packet[3] & 0x0f) != 0x02) ) | |
416 | // error detected | |
417 | ||
418 | ||
419 | In case an error is detected, all the packets are shifted by one (and packet[0] is discarded). | |
420 | ||
28f49616 | 421 | 5.2.2 One/Three finger touch |
2a0bd75e AO |
422 | ~~~~~~~~~~~~~~~~ |
423 | ||
424 | byte 0: | |
425 | ||
426 | bit 7 6 5 4 3 2 1 0 | |
71c6d188 | 427 | n1 n0 w3 w2 . . R L |
2a0bd75e AO |
428 | |
429 | L, R = 1 when Left, Right mouse button pressed | |
28f49616 | 430 | n1..n0 = number of fingers on touchpad |
2a0bd75e AO |
431 | |
432 | byte 1: | |
433 | ||
434 | bit 7 6 5 4 3 2 1 0 | |
11559619 | 435 | p7 p6 p5 p4 x11 x10 x9 x8 |
2a0bd75e AO |
436 | |
437 | byte 2: | |
438 | ||
439 | bit 7 6 5 4 3 2 1 0 | |
71c6d188 | 440 | x7 x6 x5 x4 x3 x2 x1 x0 |
2a0bd75e | 441 | |
11559619 | 442 | x11..x0 = absolute x value (horizontal) |
2a0bd75e AO |
443 | |
444 | byte 3: | |
445 | ||
446 | bit 7 6 5 4 3 2 1 0 | |
71c6d188 ÉP |
447 | n4 vf w1 w0 . . . b2 |
448 | ||
449 | n4 = set if more than 3 fingers (only in 3 fingers mode) | |
450 | vf = a kind of flag ? (only on EF123, 0 when finger is over one | |
451 | of the buttons, 1 otherwise) | |
452 | w3..w0 = width of the finger touch (not EF113) | |
453 | b2 (on EF113 only, 0 otherwise), b2.R.L indicates one button pressed: | |
454 | 0 = none | |
455 | 1 = Left | |
456 | 2 = Right | |
457 | 3 = Middle (Left and Right) | |
458 | 4 = Forward | |
459 | 5 = Back | |
460 | 6 = Another one | |
461 | 7 = Another one | |
2a0bd75e AO |
462 | |
463 | byte 4: | |
464 | ||
465 | bit 7 6 5 4 3 2 1 0 | |
11559619 | 466 | p3 p1 p2 p0 y11 y10 y9 y8 |
71c6d188 ÉP |
467 | |
468 | p7..p0 = pressure (not EF113) | |
2a0bd75e AO |
469 | |
470 | byte 5: | |
471 | ||
472 | bit 7 6 5 4 3 2 1 0 | |
473 | y7 y6 y5 y4 y3 y2 y1 y0 | |
474 | ||
11559619 | 475 | y11..y0 = absolute y value (vertical) |
2a0bd75e AO |
476 | |
477 | ||
28f49616 | 478 | 5.2.3 Two finger touch |
2a0bd75e AO |
479 | ~~~~~~~~~~~~~~~~ |
480 | ||
71c6d188 ÉP |
481 | Note that the two pairs of coordinates are not exactly the coordinates of the |
482 | two fingers, but only the pair of the lower-left and upper-right coordinates. | |
483 | So the actual fingers might be situated on the other diagonal of the square | |
484 | defined by these two points. | |
485 | ||
2a0bd75e AO |
486 | byte 0: |
487 | ||
488 | bit 7 6 5 4 3 2 1 0 | |
489 | n1 n0 ay8 ax8 . . R L | |
490 | ||
491 | L, R = 1 when Left, Right mouse button pressed | |
28f49616 | 492 | n1..n0 = number of fingers on touchpad |
2a0bd75e AO |
493 | |
494 | byte 1: | |
495 | ||
496 | bit 7 6 5 4 3 2 1 0 | |
497 | ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0 | |
498 | ||
71c6d188 | 499 | ax8..ax0 = lower-left finger absolute x value |
2a0bd75e AO |
500 | |
501 | byte 2: | |
502 | ||
503 | bit 7 6 5 4 3 2 1 0 | |
504 | ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0 | |
505 | ||
71c6d188 | 506 | ay8..ay0 = lower-left finger absolute y value |
2a0bd75e AO |
507 | |
508 | byte 3: | |
509 | ||
510 | bit 7 6 5 4 3 2 1 0 | |
511 | . . by8 bx8 . . . . | |
512 | ||
513 | byte 4: | |
514 | ||
515 | bit 7 6 5 4 3 2 1 0 | |
516 | bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0 | |
517 | ||
71c6d188 | 518 | bx8..bx0 = upper-right finger absolute x value |
2a0bd75e AO |
519 | |
520 | byte 5: | |
521 | ||
522 | bit 7 6 5 4 3 2 1 0 | |
523 | by7 by8 by5 by4 by3 by2 by1 by0 | |
524 | ||
71c6d188 | 525 | by8..by0 = upper-right finger absolute y value |
28f49616 JD |
526 | |
527 | ///////////////////////////////////////////////////////////////////////////// | |
528 | ||
529 | 6. Hardware version 3 | |
530 | ================== | |
531 | ||
532 | 6.1 Registers | |
533 | ~~~~~~~~~ | |
534 | * reg_10 | |
535 | ||
536 | bit 7 6 5 4 3 2 1 0 | |
36189cc3 | 537 | 0 0 0 0 R F T A |
28f49616 JD |
538 | |
539 | A: 1 = enable absolute tracking | |
36189cc3 HG |
540 | T: 1 = enable two finger mode auto correct |
541 | F: 1 = disable ABS Position Filter | |
542 | R: 1 = enable real hardware resolution | |
28f49616 JD |
543 | |
544 | 6.2 Native absolute mode 6 byte packet format | |
545 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
546 | 1 and 3 finger touch shares the same 6-byte packet format, except that | |
547 | 3 finger touch only reports the position of the center of all three fingers. | |
548 | ||
549 | Firmware would send 12 bytes of data for 2 finger touch. | |
550 | ||
551 | Note on debounce: | |
552 | In case the box has unstable power supply or other electricity issues, or | |
553 | when number of finger changes, F/W would send "debounce packet" to inform | |
554 | driver that the hardware is in debounce status. | |
555 | The debouce packet has the following signature: | |
556 | byte 0: 0xc4 | |
557 | byte 1: 0xff | |
558 | byte 2: 0xff | |
559 | byte 3: 0x02 | |
560 | byte 4: 0xff | |
561 | byte 5: 0xff | |
562 | When we encounter this kind of packet, we just ignore it. | |
563 | ||
564 | 6.2.1 One/Three finger touch | |
565 | ~~~~~~~~~~~~~~~~~~~~~~ | |
566 | ||
567 | byte 0: | |
568 | ||
569 | bit 7 6 5 4 3 2 1 0 | |
570 | n1 n0 w3 w2 0 1 R L | |
571 | ||
572 | L, R = 1 when Left, Right mouse button pressed | |
573 | n1..n0 = number of fingers on touchpad | |
574 | ||
575 | byte 1: | |
576 | ||
577 | bit 7 6 5 4 3 2 1 0 | |
578 | p7 p6 p5 p4 x11 x10 x9 x8 | |
579 | ||
580 | byte 2: | |
581 | ||
582 | bit 7 6 5 4 3 2 1 0 | |
583 | x7 x6 x5 x4 x3 x2 x1 x0 | |
584 | ||
585 | x11..x0 = absolute x value (horizontal) | |
586 | ||
587 | byte 3: | |
588 | ||
589 | bit 7 6 5 4 3 2 1 0 | |
590 | 0 0 w1 w0 0 0 1 0 | |
591 | ||
592 | w3..w0 = width of the finger touch | |
593 | ||
594 | byte 4: | |
595 | ||
596 | bit 7 6 5 4 3 2 1 0 | |
597 | p3 p1 p2 p0 y11 y10 y9 y8 | |
598 | ||
599 | p7..p0 = pressure | |
600 | ||
601 | byte 5: | |
602 | ||
603 | bit 7 6 5 4 3 2 1 0 | |
604 | y7 y6 y5 y4 y3 y2 y1 y0 | |
605 | ||
606 | y11..y0 = absolute y value (vertical) | |
607 | ||
608 | 6.2.2 Two finger touch | |
609 | ~~~~~~~~~~~~~~~~ | |
610 | ||
611 | The packet format is exactly the same for two finger touch, except the hardware | |
612 | sends two 6 byte packets. The first packet contains data for the first finger, | |
613 | the second packet has data for the second finger. So for two finger touch a | |
614 | total of 12 bytes are sent. | |
1dc6edec JD |
615 | |
616 | ///////////////////////////////////////////////////////////////////////////// | |
617 | ||
618 | 7. Hardware version 4 | |
619 | ================== | |
620 | ||
621 | 7.1 Registers | |
622 | ~~~~~~~~~ | |
623 | * reg_07 | |
624 | ||
625 | bit 7 6 5 4 3 2 1 0 | |
626 | 0 0 0 0 0 0 0 A | |
627 | ||
628 | A: 1 = enable absolute tracking | |
629 | ||
630 | 7.2 Native absolute mode 6 byte packet format | |
631 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
632 | v4 hardware is a true multitouch touchpad, capable of tracking up to 5 fingers. | |
633 | Unfortunately, due to PS/2's limited bandwidth, its packet format is rather | |
634 | complex. | |
635 | ||
636 | Whenever the numbers or identities of the fingers changes, the hardware sends a | |
637 | status packet to indicate how many and which fingers is on touchpad, followed by | |
638 | head packets or motion packets. A head packet contains data of finger id, finger | |
639 | position (absolute x, y values), width, and pressure. A motion packet contains | |
640 | two fingers' position delta. | |
641 | ||
642 | For example, when status packet tells there are 2 fingers on touchpad, then we | |
643 | can expect two following head packets. If the finger status doesn't change, | |
644 | the following packets would be motion packets, only sending delta of finger | |
645 | position, until we receive a status packet. | |
646 | ||
647 | One exception is one finger touch. when a status packet tells us there is only | |
648 | one finger, the hardware would just send head packets afterwards. | |
649 | ||
650 | 7.2.1 Status packet | |
651 | ~~~~~~~~~~~~~ | |
652 | ||
653 | byte 0: | |
654 | ||
655 | bit 7 6 5 4 3 2 1 0 | |
656 | . . . . 0 1 R L | |
657 | ||
658 | L, R = 1 when Left, Right mouse button pressed | |
659 | ||
660 | byte 1: | |
661 | ||
662 | bit 7 6 5 4 3 2 1 0 | |
663 | . . . ft4 ft3 ft2 ft1 ft0 | |
664 | ||
665 | ft4 ft3 ft2 ft1 ft0 ftn = 1 when finger n is on touchpad | |
666 | ||
667 | byte 2: not used | |
668 | ||
669 | byte 3: | |
670 | ||
671 | bit 7 6 5 4 3 2 1 0 | |
672 | . . . 1 0 0 0 0 | |
673 | ||
674 | constant bits | |
675 | ||
676 | byte 4: | |
677 | ||
678 | bit 7 6 5 4 3 2 1 0 | |
679 | p . . . . . . . | |
680 | ||
681 | p = 1 for palm | |
682 | ||
683 | byte 5: not used | |
684 | ||
685 | 7.2.2 Head packet | |
686 | ~~~~~~~~~~~ | |
687 | ||
688 | byte 0: | |
689 | ||
690 | bit 7 6 5 4 3 2 1 0 | |
691 | w3 w2 w1 w0 0 1 R L | |
692 | ||
693 | L, R = 1 when Left, Right mouse button pressed | |
694 | w3..w0 = finger width (spans how many trace lines) | |
695 | ||
696 | byte 1: | |
697 | ||
698 | bit 7 6 5 4 3 2 1 0 | |
699 | p7 p6 p5 p4 x11 x10 x9 x8 | |
700 | ||
701 | byte 2: | |
702 | ||
703 | bit 7 6 5 4 3 2 1 0 | |
704 | x7 x6 x5 x4 x3 x2 x1 x0 | |
705 | ||
706 | x11..x0 = absolute x value (horizontal) | |
707 | ||
708 | byte 3: | |
709 | ||
710 | bit 7 6 5 4 3 2 1 0 | |
711 | id2 id1 id0 1 0 0 0 1 | |
712 | ||
713 | id2..id0 = finger id | |
714 | ||
715 | byte 4: | |
716 | ||
717 | bit 7 6 5 4 3 2 1 0 | |
718 | p3 p1 p2 p0 y11 y10 y9 y8 | |
719 | ||
720 | p7..p0 = pressure | |
721 | ||
722 | byte 5: | |
723 | ||
724 | bit 7 6 5 4 3 2 1 0 | |
725 | y7 y6 y5 y4 y3 y2 y1 y0 | |
726 | ||
727 | y11..y0 = absolute y value (vertical) | |
728 | ||
729 | 7.2.3 Motion packet | |
730 | ~~~~~~~~~~~~~ | |
731 | ||
732 | byte 0: | |
733 | ||
734 | bit 7 6 5 4 3 2 1 0 | |
735 | id2 id1 id0 w 0 1 R L | |
736 | ||
737 | L, R = 1 when Left, Right mouse button pressed | |
738 | id2..id0 = finger id | |
739 | w = 1 when delta overflows (> 127 or < -128), in this case | |
740 | firmware sends us (delta x / 5) and (delta y / 5) | |
741 | ||
742 | byte 1: | |
743 | ||
744 | bit 7 6 5 4 3 2 1 0 | |
745 | x7 x6 x5 x4 x3 x2 x1 x0 | |
746 | ||
747 | x7..x0 = delta x (two's complement) | |
748 | ||
749 | byte 2: | |
750 | ||
751 | bit 7 6 5 4 3 2 1 0 | |
752 | y7 y6 y5 y4 y3 y2 y1 y0 | |
753 | ||
754 | y7..y0 = delta y (two's complement) | |
755 | ||
756 | byte 3: | |
757 | ||
758 | bit 7 6 5 4 3 2 1 0 | |
759 | id2 id1 id0 1 0 0 1 0 | |
760 | ||
761 | id2..id0 = finger id | |
762 | ||
763 | byte 4: | |
764 | ||
765 | bit 7 6 5 4 3 2 1 0 | |
766 | x7 x6 x5 x4 x3 x2 x1 x0 | |
767 | ||
768 | x7..x0 = delta x (two's complement) | |
769 | ||
770 | byte 5: | |
771 | ||
772 | bit 7 6 5 4 3 2 1 0 | |
773 | y7 y6 y5 y4 y3 y2 y1 y0 | |
774 | ||
775 | y7..y0 = delta y (two's complement) | |
776 | ||
777 | byte 0 ~ 2 for one finger | |
778 | byte 3 ~ 5 for another | |
c6c748ef UDB |
779 | |
780 | ||
781 | 8. Trackpoint (for Hardware version 3 and 4) | |
782 | ========================================= | |
783 | 8.1 Registers | |
784 | ~~~~~~~~~ | |
785 | No special registers have been identified. | |
786 | ||
787 | 8.2 Native relative mode 6 byte packet format | |
788 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
789 | 8.2.1 Status Packet | |
790 | ~~~~~~~~~~~~~ | |
791 | ||
792 | byte 0: | |
793 | bit 7 6 5 4 3 2 1 0 | |
794 | 0 0 sx sy 0 M R L | |
795 | byte 1: | |
796 | bit 7 6 5 4 3 2 1 0 | |
797 | ~sx 0 0 0 0 0 0 0 | |
798 | byte 2: | |
799 | bit 7 6 5 4 3 2 1 0 | |
800 | ~sy 0 0 0 0 0 0 0 | |
801 | byte 3: | |
802 | bit 7 6 5 4 3 2 1 0 | |
803 | 0 0 ~sy ~sx 0 1 1 0 | |
804 | byte 4: | |
805 | bit 7 6 5 4 3 2 1 0 | |
806 | x7 x6 x5 x4 x3 x2 x1 x0 | |
807 | byte 5: | |
808 | bit 7 6 5 4 3 2 1 0 | |
809 | y7 y6 y5 y4 y3 y2 y1 y0 | |
810 | ||
811 | ||
812 | x and y are written in two's complement spread | |
813 | over 9 bits with sx/sy the relative top bit and | |
814 | x7..x0 and y7..y0 the lower bits. | |
815 | ~sx is the inverse of sx, ~sy is the inverse of sy. | |
816 | The sign of y is opposite to what the input driver | |
817 | expects for a relative movement |