Hi list,
This is a series of patches to add support for newer generation of ELAN
touchpad.
Patches #1~5 are essentially fixes and cleanups that pave the way for
patch #6, which really adds code for v3 hardware support.
Any comments, suggestions are welcome.
Thank you.
JJ Ding (6):
Input: elantech - correct x, y value range for v2 hardware
Input: elantech - use firmware provided x, y ranges
Input: elantech - packet checking for v2 hardware
Input: elantech - work around EC buffer
Input: elantech - clean up elantech_init
Input: elantech - add v3 hardware support
Documentation/input/elantech.txt | 112 ++++++++++--
drivers/input/mouse/elantech.c | 373 ++++++++++++++++++++++++++++++++------
drivers/input/mouse/elantech.h | 15 ++-
3 files changed, 426 insertions(+), 74 deletions(-)
--
1.7.4.1
@@ -771,13 +813,14 @@ int elantech_init(struct psmouse *psmouse)pr_info("assuming hardware version %d, firmware version %d.%d.%d\n",etd->hw_version,param[0],param[1],param[2]);-if(synaptics_send_cmd(psmouse,ETP_CAPABILITIES_QUERY,param)){+if(synaptics_send_cmd(psmouse,ETP_CAPABILITIES_QUERY,+etd->capabilities)){pr_err("failed to query capabilities.\n");gotoinit_fail;}pr_info("Synaptics capabilities query result 0x%02x, 0x%02x, 0x%02x.\n",-param[0],param[1],param[2]);-etd->capabilities=param[0];+etd->capabilities[0],etd->capabilities[1],+etd->capabilities[2]);/**Thisfirmwaresuffersfrommisreportingcoordinateswhen
With some EC chips, when we resync due to bad packets, those bad bytes would
still remain in EC's buffer area. That makes us always get bad data back,
no matter what.
So shift packet for 1 byte when encounter bad packet, until we get rid of those
bytes.
Signed-off-by: JJ Ding <redacted>
---
drivers/input/mouse/elantech.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
@@ -791,6 +791,42 @@ static int elantech_reconnect(struct psmouse *psmouse)}/*+*determinehardwareversionandsetsomepropertiesaccordingtoit.+*/+staticvoidelantech_set_properties(structelantech_data*etd)+{+/*+*Assumeeveryversiongreaterthan0x020030isnewEeePCstyle+*hardwarewith6bytepackets,except0x020600+*/+if(etd->fw_version<0x020030||etd->fw_version==0x020600)+etd->hw_version=1;+else+etd->hw_version=2;++/*+*Turnonpacketcheckingbydefault.+*/+etd->paritycheck=1;++/*+*Thisfirmwaresuffersfrommisreportingcoordinateswhen+*atouchactionstartscausingthemousecursororscrolledpage+*tojump.Enableaworkaround.+*/+etd->jumpy_cursor=+(etd->fw_version==0x020022||etd->fw_version==0x020600);++if(etd->hw_version==2){+/* For now show extra debug information */+etd->debug=1;++if(etd->fw_version>=0x020800)+etd->reports_pressure=true;+}+}++/**Initializethetouchpadandcreatesysfsentries*/intelantech_init(structpsmouse*psmouse)
@@ -816,26 +852,9 @@ int elantech_init(struct psmouse *psmouse)}etd->fw_version=(param[0]<<16)|(param[1]<<8)|param[2];--/*-*AssumeeveryversiongreaterthanthisisnewEeePCstyle-*hardwarewith6bytepackets-*/-if(etd->fw_version>=0x020030){-etd->hw_version=2;-/* For now show extra debug information */-etd->debug=1;-etd->paritycheck=1;--if(etd->fw_version>=0x020800)-etd->reports_pressure=true;--}else{-etd->hw_version=1;-etd->paritycheck=1;-}--pr_info("assuming hardware version %d, firmware version %d.%d.%d\n",+elantech_set_properties(etd);+pr_info("assuming hardware version %d "+"(with firmware version 0x%02x%02x%02x)\n",etd->hw_version,param[0],param[1],param[2]);if(synaptics_send_cmd(psmouse,ETP_CAPABILITIES_QUERY,
@@ -847,16 +866,6 @@ int elantech_init(struct psmouse *psmouse)etd->capabilities[0],etd->capabilities[1],etd->capabilities[2]);-/*-*Thisfirmwaresuffersfrommisreportingcoordinateswhen-*atouchactionstartscausingthemousecursororscrolledpage-*tojump.Enableaworkaround.-*/-if(etd->fw_version==0x020022||etd->fw_version==0x020600){-pr_info("firmware version 2.0.34/2.6.0 detected, enabling jumpy cursor workaround\n");-etd->jumpy_cursor=true;-}-if(elantech_set_absolute_mode(psmouse)){pr_err("failed to put touchpad into absolute mode.\n");gotoinit_fail;
@@ -375,7 +382,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,7 +391,7 @@ 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:
@@ -432,7 +439,7 @@ byte 5: 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 +453,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 +487,76 @@ 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.++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.
@@ -582,10 +739,26 @@ static void elantech_set_input_params(struct psmouse *psmouse)input_set_abs_params(dev,ABS_MT_POSITION_X,x_min,x_max,0,0);input_set_abs_params(dev,ABS_MT_POSITION_Y,y_min,y_max,0,0);break;++case3:+input_set_abs_params(dev,ABS_X,x_min,x_max,0,0);+input_set_abs_params(dev,ABS_Y,y_min,y_max,0,0);+/* range of pressure and width is the same as v2 */+input_set_abs_params(dev,ABS_PRESSURE,ETP_PMIN_V2,+ETP_PMAX_V2,0,0);+input_set_abs_params(dev,ABS_TOOL_WIDTH,ETP_WMIN_V2,+ETP_WMAX_V2,0,0);+__set_bit(INPUT_PROP_SEMI_MT,dev->propbit);+input_mt_init_slots(dev,2);+input_set_abs_params(dev,ABS_MT_POSITION_X,x_min,x_max,0,0);+input_set_abs_params(dev,ABS_MT_POSITION_Y,y_min,y_max,0,0);+break;}etd->y_max=y_max;etd->y_2ft_max=y_2ft_max;++return0;}structelantech_attr_data{
@@ -727,7 +900,8 @@ int elantech_detect(struct psmouse *psmouse, bool set_properties)*ReportthisincasethereareElantechmodelsthatuseadifferent*setofmagicnumbers*/-if(param[0]!=0x3c||param[1]!=0x03||param[2]!=0xc8){+if(param[0]!=0x3c||param[1]!=0x03||+(param[2]!=0xc8&¶m[2]!=0x00)){pr_debug("unexpected magic knock result 0x%02x, 0x%02x, 0x%02x.\n",param[0],param[1],param[2]);return-1;
@@ -793,16 +967,16 @@ static int elantech_reconnect(struct psmouse *psmouse)/**determinehardwareversionandsetsomepropertiesaccordingtoit.*/-staticvoidelantech_set_properties(structelantech_data*etd)+staticintelantech_set_properties(structelantech_data*etd){-/*-*Assumeeveryversiongreaterthan0x020030isnewEeePCstyle-*hardwarewith6bytepackets,except0x020600-*/if(etd->fw_version<0x020030||etd->fw_version==0x020600)etd->hw_version=1;-else+elseif(etd->fw_version<0x150600)etd->hw_version=2;+elseif((etd->fw_version&0x0f0000)>>16==5)+etd->hw_version=3;+else+return-1;/**Turnonpacketcheckingbydefault.
@@ -817,13 +991,15 @@ static void elantech_set_properties(struct elantech_data *etd)etd->jumpy_cursor=(etd->fw_version==0x020022||etd->fw_version==0x020600);-if(etd->hw_version==2){+if(etd->hw_version>1){/* For now show extra debug information */etd->debug=1;if(etd->fw_version>=0x020800)etd->reports_pressure=true;}++return0;}/*
@@ -850,9 +1026,12 @@ int elantech_init(struct psmouse *psmouse)pr_err("failed to query firmware version.\n");gotoinit_fail;}-etd->fw_version=(param[0]<<16)|(param[1]<<8)|param[2];-elantech_set_properties(etd);++if(elantech_set_properties(etd)){+pr_err("unknown hardware version, aborting...\n");+gotoinit_fail;+}pr_info("assuming hardware version %d ""(with firmware version 0x%02x%02x%02x)\n",etd->hw_version,param[0],param[1],param[2]);
@@ -871,7 +1050,10 @@ int elantech_init(struct psmouse *psmouse)gotoinit_fail;}-elantech_set_input_params(psmouse);+if(elantech_set_input_params(psmouse)){+pr_err("failed to query touchpad range.\n");+gotoinit_fail;+}error=sysfs_create_group(&psmouse->ps2dev.serio->dev.kobj,&elantech_attr_group);
@@ -883,7 +1065,7 @@ int elantech_init(struct psmouse *psmouse)psmouse->protocol_handler=elantech_process_byte;psmouse->disconnect=elantech_disconnect;psmouse->reconnect=elantech_reconnect;-psmouse->pktsize=etd->hw_version==2?6:4;+psmouse->pktsize=etd->hw_version>1?6:4;return0;
For v2 hardware, there is no real parity check, but we can still check
some constant bits for data integrity.
Signed-off-by: JJ Ding <redacted>
---
drivers/input/mouse/elantech.c | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
@@ -376,6 +376,25 @@ static int elantech_check_parity_v1(struct psmouse *psmouse)etd->parity[packet[3]]==p3;}+staticintpacket_simple_check_v2(structpsmouse*psmouse)+{+structelantech_data*etd=psmouse->private;+unsignedchar*packet=psmouse->packet;++if(etd->reports_pressure)+return(packet[0]&0x0c)==0x04&&+(packet[3]&0x0f)==0x02;++if((packet[0]&0xc0)==0x80)+return(packet[0]&0x0c)==0x0c&&+(packet[3]&0x0e)==0x08;++return(packet[0]&0x3c)==0x3c&&+(packet[1]&0xf0)==0x00&&+(packet[3]&0x3e)==0x38&&+(packet[4]&0xf0)==0x00;+}+/**Processbytestreamfrommouseandhandlecompletepackets*/
@@ -398,7 +417,9 @@ static psmouse_ret_t elantech_process_byte(struct psmouse *psmouse)break;case2:-/* We don't know how to check parity in protocol v2 */+if(etd->paritycheck&&!packet_simple_check_v2(psmouse))+returnPSMOUSE_BAD_DATA;+elantech_report_absolute_v2(psmouse);break;}
@@ -799,8 +820,7 @@ int elantech_init(struct psmouse *psmouse)etd->hw_version=2;/* For now show extra debug information */etd->debug=1;-/* Don't know how to do parity checking for version 2 */-etd->paritycheck=0;+etd->paritycheck=1;if(etd->fw_version>=0x020800)etd->reports_pressure=true;
From: Daniel Kurtz <hidden> Date: 2011-08-18 02:49:53
On Thu, Aug 18, 2011 at 9:57 AM, JJ Ding [off-list ref] wrote:
quoted hunk
For v2 hardware, there is no real parity check, but we can still check
some constant bits for data integrity.
Signed-off-by: JJ Ding <redacted>
---
drivers/input/mouse/elantech.c | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
@@ -376,6 +376,25 @@ static int elantech_check_parity_v1(struct psmouse *psmouse)etd->parity[packet[3]]==p3;}+staticintpacket_simple_check_v2(structpsmouse*psmouse)+{+structelantech_data*etd=psmouse->private;+unsignedchar*packet=psmouse->packet;++if(etd->reports_pressure)+return(packet[0]&0x0c)==0x04&&+(packet[3]&0x0f)==0x02;++if((packet[0]&0xc0)==0x80)+return(packet[0]&0x0c)==0x0c&&+(packet[3]&0x0e)==0x08;++return(packet[0]&0x3c)==0x3c&&+(packet[1]&0xf0)==0x00&&+(packet[3]&0x3e)==0x38&&+(packet[4]&0xf0)==0x00;+}+/**Processbytestreamfrommouseandhandlecompletepackets*/
@@ -398,7 +417,9 @@ static psmouse_ret_t elantech_process_byte(struct psmouse *psmouse)break;case2:-/* We don't know how to check parity in protocol v2 */+if(etd->paritycheck&&!packet_simple_check_v2(psmouse))+returnPSMOUSE_BAD_DATA;+elantech_report_absolute_v2(psmouse);break;}
@@ -799,8 +820,7 @@ int elantech_init(struct psmouse *psmouse)etd->hw_version=2;/* For now show extra debug information */etd->debug=1;-/* Don't know how to do parity checking for version 2 */-etd->paritycheck=0;+etd->paritycheck=1;
If we always do some sort of check, can we just remove etd->paritycheck now?
if (etd->fw_version >= 0x020800)
etd->reports_pressure = true;
--
1.7.4.1
From: Daniel Kurtz <hidden> Date: 2011-08-18 02:51:12
On Thu, Aug 18, 2011 at 9:57 AM, JJ Ding [off-list ref] wrote:
With some EC chips, when we resync due to bad packets, those bad bytes would
still remain in EC's buffer area. That makes us always get bad data back,
no matter what.
So shift packet for 1 byte when encounter bad packet, until we get rid of those
bytes.
Signed-off-by: JJ Ding <redacted>
@@ -375,7 +382,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,7 +391,7 @@ 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:
@@ -432,7 +439,7 @@ byte 5: 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 +453,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 +487,76 @@ 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.++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.
@@ -727,7 +900,8 @@ int elantech_detect(struct psmouse *psmouse, bool set_properties) * Report this in case there are Elantech models that use a different * set of magic numbers */- if (param[0] != 0x3c || param[1] != 0x03 || param[2] != 0xc8) {+ if (param[0] != 0x3c || param[1] != 0x03 ||+ (param[2] != 0xc8 && param[2] != 0x00)) { pr_debug("unexpected magic knock result 0x%02x, 0x%02x, 0x%02x.\n", param[0], param[1], param[2]); return -1;
@@ -793,16 +967,16 @@ static int elantech_reconnect(struct psmouse *psmouse) /* * determine hardware version and set some properties according to it. */-static void elantech_set_properties(struct elantech_data *etd)+static int elantech_set_properties(struct elantech_data *etd) {- /*- * Assume every version greater than 0x020030 is new EeePC style- * hardware with 6 byte packets, except 0x020600- */ if (etd->fw_version < 0x020030 || etd->fw_version == 0x020600) etd->hw_version = 1;- else+ else if (etd->fw_version < 0x150600) etd->hw_version = 2;+ else if ((etd->fw_version & 0x0f0000) >> 16 == 5)+ etd->hw_version = 3;+ else+ return -1; /* * Turn on packet checking by default.
@@ -817,13 +991,15 @@ static void elantech_set_properties(struct elantech_data *etd) etd->jumpy_cursor = (etd->fw_version == 0x020022 || etd->fw_version == 0x020600);- if (etd->hw_version == 2) {+ if (etd->hw_version > 1) { /* For now show extra debug information */ etd->debug = 1; if (etd->fw_version >= 0x020800) etd->reports_pressure = true; }++ return 0; } /*
@@ -375,7 +382,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,7 +391,7 @@ 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:
@@ -432,7 +439,7 @@ byte 5: 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 +453,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 +487,76 @@ 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.++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.
@@ -727,7 +900,8 @@ int elantech_detect(struct psmouse *psmouse, bool set_properties) * Report this in case there are Elantech models that use a different * set of magic numbers */- if (param[0] != 0x3c || param[1] != 0x03 || param[2] != 0xc8) {+ if (param[0] != 0x3c || param[1] != 0x03 ||+ (param[2] != 0xc8&& param[2] != 0x00)) { pr_debug("unexpected magic knock result 0x%02x, 0x%02x, 0x%02x.\n", param[0], param[1], param[2]); return -1;
@@ -793,16 +967,16 @@ static int elantech_reconnect(struct psmouse *psmouse) /* * determine hardware version and set some properties according to it. */-static void elantech_set_properties(struct elantech_data *etd)+static int elantech_set_properties(struct elantech_data *etd) {- /*- * Assume every version greater than 0x020030 is new EeePC style- * hardware with 6 byte packets, except 0x020600- */ if (etd->fw_version< 0x020030 || etd->fw_version == 0x020600) etd->hw_version = 1;- else+ else if (etd->fw_version< 0x150600) etd->hw_version = 2;+ else if ((etd->fw_version& 0x0f0000)>> 16 == 5)+ etd->hw_version = 3;+ else+ return -1; /* * Turn on packet checking by default.
@@ -817,13 +991,15 @@ static void elantech_set_properties(struct elantech_data *etd) etd->jumpy_cursor = (etd->fw_version == 0x020022 || etd->fw_version == 0x020600);- if (etd->hw_version == 2) {+ if (etd->hw_version> 1) { /* For now show extra debug information */ etd->debug = 1; if (etd->fw_version>= 0x020800) etd->reports_pressure = true; }++ return 0; } /*
@@ -850,9 +1026,12 @@ int elantech_init(struct psmouse *psmouse) pr_err("failed to query firmware version.\n"); goto init_fail; }- etd->fw_version = (param[0]<< 16) | (param[1]<< 8) | param[2];- elantech_set_properties(etd);++ if (elantech_set_properties(etd)) {+ pr_err("unknown hardware version, aborting...\n");+ goto init_fail;+ } pr_info("assuming hardware version %d " "(with firmware version 0x%02x%02x%02x)\n", etd->hw_version, param[0], param[1], param[2]);
@@ -871,7 +1050,10 @@ int elantech_init(struct psmouse *psmouse) goto init_fail; }- elantech_set_input_params(psmouse);+ if (elantech_set_input_params(psmouse)) {+ pr_err("failed to query touchpad range.\n");+ goto init_fail;+ } error = sysfs_create_group(&psmouse->ps2dev.serio->dev.kobj, &elantech_attr_group);
@@ -375,7 +382,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,7 +391,7 @@ 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:
@@ -432,7 +439,7 @@ byte 5: 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 +453,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 +487,76 @@ 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.++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.
@@ -727,7 +900,8 @@ int elantech_detect(struct psmouse *psmouse, bool set_properties) * Report this in case there are Elantech models that use a different * set of magic numbers */- if (param[0] != 0x3c || param[1] != 0x03 || param[2] != 0xc8) {+ if (param[0] != 0x3c || param[1] != 0x03 ||+ (param[2] != 0xc8&& param[2] != 0x00)) { pr_debug("unexpected magic knock result 0x%02x, 0x%02x, 0x%02x.\n", param[0], param[1], param[2]); return -1;
@@ -793,16 +967,16 @@ static int elantech_reconnect(struct psmouse *psmouse) /* * determine hardware version and set some properties according to it. */-static void elantech_set_properties(struct elantech_data *etd)+static int elantech_set_properties(struct elantech_data *etd) {- /*- * Assume every version greater than 0x020030 is new EeePC style- * hardware with 6 byte packets, except 0x020600- */ if (etd->fw_version< 0x020030 || etd->fw_version == 0x020600) etd->hw_version = 1;- else+ else if (etd->fw_version< 0x150600) etd->hw_version = 2;+ else if ((etd->fw_version& 0x0f0000)>> 16 == 5)+ etd->hw_version = 3;+ else+ return -1; /* * Turn on packet checking by default.
@@ -817,13 +991,15 @@ static void elantech_set_properties(struct elantech_data *etd) etd->jumpy_cursor = (etd->fw_version == 0x020022 || etd->fw_version == 0x020600);- if (etd->hw_version == 2) {+ if (etd->hw_version> 1) { /* For now show extra debug information */ etd->debug = 1; if (etd->fw_version>= 0x020800) etd->reports_pressure = true; }++ return 0; } /*
@@ -850,9 +1026,12 @@ int elantech_init(struct psmouse *psmouse) pr_err("failed to query firmware version.\n"); goto init_fail; }- etd->fw_version = (param[0]<< 16) | (param[1]<< 8) | param[2];- elantech_set_properties(etd);++ if (elantech_set_properties(etd)) {+ pr_err("unknown hardware version, aborting...\n");+ goto init_fail;+ } pr_info("assuming hardware version %d " "(with firmware version 0x%02x%02x%02x)\n", etd->hw_version, param[0], param[1], param[2]);
@@ -871,7 +1050,10 @@ int elantech_init(struct psmouse *psmouse) goto init_fail; }- elantech_set_input_params(psmouse);+ if (elantech_set_input_params(psmouse)) {+ pr_err("failed to query touchpad range.\n");+ goto init_fail;+ } error = sysfs_create_group(&psmouse->ps2dev.serio->dev.kobj, &elantech_attr_group);
@@ -113,6 +122,8 @@ struct elantech_data { unsigned int single_finger_reports; unsigned int y_max; unsigned int y_2ft_max;+ unsigned int prev_x;+ unsigned int prev_y; unsigned char parity[256]; };--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
With some EC chips, when we resync due to bad packets, those bad bytes would
still remain in EC's buffer area. That makes us always get bad data back,
no matter what.
So shift packet for 1 byte when encounter bad packet, until we get rid of those
bytes.
Signed-off-by: JJ Ding<redacted>
---
drivers/input/mouse/elantech.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
@@ -791,6 +791,42 @@ static int elantech_reconnect(struct psmouse *psmouse)}/*+*determinehardwareversionandsetsomepropertiesaccordingtoit.+*/+staticvoidelantech_set_properties(structelantech_data*etd)+{+/*+*Assumeeveryversiongreaterthan0x020030isnewEeePCstyle+*hardwarewith6bytepackets,except0x020600+*/+if(etd->fw_version<0x020030||etd->fw_version==0x020600)+etd->hw_version=1;+else+etd->hw_version=2;++/*+*Turnonpacketcheckingbydefault.+*/+etd->paritycheck=1;
Assuming paritycheck goes away:
Agree.
Reviewed-by: Daniel Kurtz<redacted>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
@@ -375,7 +382,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,7 +391,7 @@ 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:
@@ -432,7 +439,7 @@ byte 5:
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 +453,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 +487,76 @@ 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.
+
+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.
diff --git a/drivers/input/mouse/elantech.c
b/drivers/input/mouse/elantech.c
index ddd40eb..e13a719 100644
@@ -727,7 +900,8 @@ int elantech_detect(struct psmouse *psmouse, bool
set_properties)
* Report this in case there are Elantech models that use a
different
* set of magic numbers
*/
- if (param[0] != 0x3c || param[1] != 0x03 || param[2] != 0xc8) {
+ if (param[0] != 0x3c || param[1] != 0x03 ||
+ (param[2] != 0xc8&& param[2] != 0x00)) {
pr_debug("unexpected magic knock result 0x%02x, 0x%02x,
0x%02x.\n",
param[0], param[1], param[2]);
return -1;
@@ -793,16 +967,16 @@ static int elantech_reconnect(struct psmouse
*psmouse)
/*
* determine hardware version and set some properties according to it.
*/
-static void elantech_set_properties(struct elantech_data *etd)
+static int elantech_set_properties(struct elantech_data *etd)
{
- /*
- * Assume every version greater than 0x020030 is new EeePC style
- * hardware with 6 byte packets, except 0x020600
- */
if (etd->fw_version< 0x020030 || etd->fw_version == 0x020600)
etd->hw_version = 1;
- else
+ else if (etd->fw_version< 0x150600)
etd->hw_version = 2;
+ else if ((etd->fw_version& 0x0f0000)>> 16 == 5)
+ etd->hw_version = 3;
+ else
+ return -1;
/*
* Turn on packet checking by default.
unsigned int single_finger_reports;
unsigned int y_max;
unsigned int y_2ft_max;
+ unsigned int prev_x;
+ unsigned int prev_y;
unsigned char parity[256];
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks
Wanlong Gao
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
v3 hardware's packet format is almost identical to v2 (one/three finger touch),
except when sensing two finger touch, the hardware sends 12 bytes of data.
Signed-off-by: JJ Ding<redacted>
---
Documentation/input/elantech.txt | 104 ++++++++++++++++--
drivers/input/mouse/elantech.c | 218 ++++++++++++++++++++++++++++++++++---
drivers/input/mouse/elantech.h | 11 ++
3 files changed, 303 insertions(+), 30 deletions(-)
quoted hunk
+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.
Hi Wanlong Gao,
On Thu, 18 Aug 2011 11:01:52 +0800, Wanlong Gao [off-list ref] wrote:
On 08/18/2011 09:57 AM, JJ Ding wrote:
quoted
v3 hardware's packet format is almost identical to v2 (one/three finger touch),
except when sensing two finger touch, the hardware sends 12 bytes of data.
Signed-off-by: JJ Ding<redacted>
---
Documentation/input/elantech.txt | 104 ++++++++++++++++--
drivers/input/mouse/elantech.c | 218 ++++++++++++++++++++++++++++++++++---
drivers/input/mouse/elantech.h | 11 ++
3 files changed, 303 insertions(+), 30 deletions(-)
+static int determine_packet_v3(struct psmouse *psmouse)
elantech_check_parity_v1
packet_simple_check_v2
determine_packet_v3
Why not consistent them?
OK, how do these names sound to you?
elantech_check_parity_v1
elantech_packet_check_v2
elantech_packet_check_v3
Thanks,
jj
--
Thanks
Wanlong Gao
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Wanlong Gao, Daniel,
On Thu, 18 Aug 2011 11:08:08 +0800, Wanlong Gao [off-list ref] wrote:
On 08/18/2011 11:04 AM, Daniel Kurtz wrote:
quoted
On Thu, Aug 18, 2011 at 9:57 AM, JJ Ding[off-list ref] wrote:
quoted
/*
+ * determine hardware version and set some properties according to it.
+ */
+static void elantech_set_properties(struct elantech_data *etd)
+{
+ /*
+ * Assume every version greater than 0x020030 is new EeePC style
+ * hardware with 6 byte packets, except 0x020600
+ */
+ if (etd->fw_version< 0x020030 || etd->fw_version == 0x020600)
+ etd->hw_version = 1;
+ else
+ etd->hw_version = 2;
+
+ /*
+ * Turn on packet checking by default.
+ */
+ etd->paritycheck = 1;
Assuming paritycheck goes away:
Agree.
I thought about removing it, too. But it occured to me that v1 and v2
hardware can still have the sysfs entry to turn off parity check.
And since it's exposed in sysfs, I suppose there might be some init
scripts relying on it.
What do you think, Dmitry?
Shall I remove it?
Thanks,
jj
quoted
Reviewed-by: Daniel Kurtz<redacted>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Wanlong Gao, Daniel,
On Thu, 18 Aug 2011 11:08:08 +0800, Wanlong Gao[off-list ref] wrote:
quoted
On 08/18/2011 11:04 AM, Daniel Kurtz wrote:
quoted
On Thu, Aug 18, 2011 at 9:57 AM, JJ Ding[off-list ref] wrote:
quoted
/*
+ * determine hardware version and set some properties according to it.
+ */
+static void elantech_set_properties(struct elantech_data *etd)
+{
+ /*
+ * Assume every version greater than 0x020030 is new EeePC style
+ * hardware with 6 byte packets, except 0x020600
+ */
+ if (etd->fw_version< 0x020030 || etd->fw_version == 0x020600)
+ etd->hw_version = 1;
+ else
+ etd->hw_version = 2;
+
+ /*
+ * Turn on packet checking by default.
+ */
+ etd->paritycheck = 1;
Assuming paritycheck goes away:
Agree.
I thought about removing it, too. But it occured to me that v1 and v2
hardware can still have the sysfs entry to turn off parity check.
And since it's exposed in sysfs, I suppose there might be some init
scripts relying on it.
What do you think, Dmitry?
Shall I remove it?
Thanks,
jj
aha, maybe you can make the sysfs entry func to be noop, and mark it to
be obsoleted, or just remove it?
Thanks
-Wanlong Gao
quoted
quoted
Reviewed-by: Daniel Kurtz<redacted>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks
Wanlong Gao
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 18, 2011 at 1:31 PM, Wanlong Gao[off-list ref] wrote:
quoted
On 08/18/2011 01:26 PM, JJ Ding wrote:
quoted
Hi Wanlong Gao,
On Thu, 18 Aug 2011 11:01:52 +0800, Wanlong Gao[off-list ref]
wrote:
quoted
On 08/18/2011 09:57 AM, JJ Ding wrote:
quoted
v3 hardware's packet format is almost identical to v2 (one/three finger
touch),
except when sensing two finger touch, the hardware sends 12 bytes of
data.
Signed-off-by: JJ Ding<redacted>
---
Documentation/input/elantech.txt | 104 ++++++++++++++++--
drivers/input/mouse/elantech.c | 218
++++++++++++++++++++++++++++++++++---
drivers/input/mouse/elantech.h | 11 ++
3 files changed, 303 insertions(+), 30 deletions(-)
+static int determine_packet_v3(struct psmouse *psmouse)
elantech_check_parity_v1
packet_simple_check_v2
determine_packet_v3
Why not consistent them?
OK, how do these names sound to you?
elantech_check_parity_v1
elantech_packet_check_v2
elantech_packet_check_v3
Thanks,
jj
Yeah, sounds perfectly.
Or just:
elantech_packet_check_v1
elantech_packet_check_v2
elantech_packet_check_v3
:)
Hmm... maybe they can go into an elantech_packet_check()?
like:
case 1:
...
case 2:
...
What do you think? ;)
Thanks
-Wanlong Gao
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 18, 2011 at 01:35:55PM +0800, JJ Ding wrote:
Hi Wanlong Gao, Daniel,
On Thu, 18 Aug 2011 11:08:08 +0800, Wanlong Gao [off-list ref] wrote:
quoted
On 08/18/2011 11:04 AM, Daniel Kurtz wrote:
quoted
On Thu, Aug 18, 2011 at 9:57 AM, JJ Ding[off-list ref] wrote:
quoted
/*
+ * determine hardware version and set some properties according to it.
+ */
+static void elantech_set_properties(struct elantech_data *etd)
+{
+ /*
+ * Assume every version greater than 0x020030 is new EeePC style
+ * hardware with 6 byte packets, except 0x020600
+ */
+ if (etd->fw_version< 0x020030 || etd->fw_version == 0x020600)
+ etd->hw_version = 1;
+ else
+ etd->hw_version = 2;
+
+ /*
+ * Turn on packet checking by default.
+ */
+ etd->paritycheck = 1;
Assuming paritycheck goes away:
Agree.
I thought about removing it, too. But it occured to me that v1 and v2
hardware can still have the sysfs entry to turn off parity check.
And since it's exposed in sysfs, I suppose there might be some init
scripts relying on it.
What do you think, Dmitry?
Shall I remove it?
No, we should not remove it, since it is useful for V1 hardware which we
still support.
How confident are we in the V2/V3 checking not tripping on valid packets?
Thanks.
--
Dmitry
From: Daniel Kurtz <hidden> Date: 2011-08-18 06:02:09
On Thu, Aug 18, 2011 at 1:44 PM, Wanlong Gao [off-list ref] wrote:
On 08/18/2011 01:34 PM, Daniel Kurtz wrote:
quoted
On Thu, Aug 18, 2011 at 1:31 PM, Wanlong Gao[off-list ref]
wrote:
quoted
On 08/18/2011 01:26 PM, JJ Ding wrote:
quoted
Hi Wanlong Gao,
On Thu, 18 Aug 2011 11:01:52 +0800, Wanlong
Gao[off-list ref]
wrote:
quoted
On 08/18/2011 09:57 AM, JJ Ding wrote:
quoted
v3 hardware's packet format is almost identical to v2 (one/three
finger
touch),
except when sensing two finger touch, the hardware sends 12 bytes of
data.
Signed-off-by: JJ Ding<redacted>
---
Documentation/input/elantech.txt | 104 ++++++++++++++++--
drivers/input/mouse/elantech.c | 218
++++++++++++++++++++++++++++++++++---
drivers/input/mouse/elantech.h | 11 ++
3 files changed, 303 insertions(+), 30 deletions(-)
+static int determine_packet_v3(struct psmouse *psmouse)
elantech_check_parity_v1
packet_simple_check_v2
determine_packet_v3
Why not consistent them?
OK, how do these names sound to you?
elantech_check_parity_v1
elantech_packet_check_v2
elantech_packet_check_v3
Thanks,
jj
Yeah, sounds perfectly.
Or just:
elantech_packet_check_v1
elantech_packet_check_v2
elantech_packet_check_v3
:)
Hmm... maybe they can go into an elantech_packet_check()?
like:
case 1:
...
case 2:
...
What do you think? ;)
Thanks
-Wanlong Gao
Since we've already parsed the hardware type at this point, it seems
inefficient to parse it again inside another function.
I would prefer individual functions.
Thanks,
-Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 18, 2011 at 1:44 PM, Wanlong Gao[off-list ref] wrote:
quoted
On 08/18/2011 01:34 PM, Daniel Kurtz wrote:
quoted
On Thu, Aug 18, 2011 at 1:31 PM, Wanlong Gao[off-list ref]
wrote:
quoted
On 08/18/2011 01:26 PM, JJ Ding wrote:
quoted
Hi Wanlong Gao,
On Thu, 18 Aug 2011 11:01:52 +0800, Wanlong
Gao[off-list ref]
wrote:
quoted
On 08/18/2011 09:57 AM, JJ Ding wrote:
quoted
v3 hardware's packet format is almost identical to v2 (one/three
finger
touch),
except when sensing two finger touch, the hardware sends 12 bytes of
data.
Signed-off-by: JJ Ding<redacted>
---
Documentation/input/elantech.txt | 104 ++++++++++++++++--
drivers/input/mouse/elantech.c | 218
++++++++++++++++++++++++++++++++++---
drivers/input/mouse/elantech.h | 11 ++
3 files changed, 303 insertions(+), 30 deletions(-)
+static int determine_packet_v3(struct psmouse *psmouse)
elantech_check_parity_v1
packet_simple_check_v2
determine_packet_v3
Why not consistent them?
OK, how do these names sound to you?
elantech_check_parity_v1
elantech_packet_check_v2
elantech_packet_check_v3
Thanks,
jj
Yeah, sounds perfectly.
Or just:
elantech_packet_check_v1
elantech_packet_check_v2
elantech_packet_check_v3
:)
Hmm... maybe they can go into an elantech_packet_check()?
like:
case 1:
...
case 2:
...
What do you think? ;)
Thanks
-Wanlong Gao
Since we've already parsed the hardware type at this point, it seems
inefficient to parse it again inside another function.
I would prefer individual functions.
Thanks,
-Daniel
On Thu, Aug 18, 2011 at 09:57:06AM +0800, JJ Ding wrote:
quoted hunk
For v2 hardware, there is no real parity check, but we can still check
some constant bits for data integrity.
Signed-off-by: JJ Ding <redacted>
---
drivers/input/mouse/elantech.c | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
On Thu, Aug 18, 2011 at 09:57:07AM +0800, JJ Ding wrote:
With some EC chips, when we resync due to bad packets, those bad bytes would
still remain in EC's buffer area. That makes us always get bad data back,
no matter what.
So shift packet for 1 byte when encounter bad packet, until we get rid of those
bytes.
If we want to do this I think it should be done in psmouse core.
Thanks.
--
Dmitry
Hi Wanlong Gao,
On Thu, 18 Aug 2011 11:07:23 +0800, Wanlong Gao [off-list ref] wrote:
On 08/18/2011 09:57 AM, JJ Ding wrote:
quoted
return PSMOUSE_FULL_PACKET;
+
+ bad_packet:
You may introduce space here.
Sorry, I am following you here.
Do you want me to add one more line below bad_packet:,
or you want me to remove the space before bad_packet?
I keep that space to make the goto tags look consistent with other
places in this file.
Should I remove all starting spaces in goto tags in the file?
Thanks,
jj
Hi Dmitry,
On Wed, 17 Aug 2011 23:39:18 -0700, Dmitry Torokhov [off-list ref] wrote:
On Thu, Aug 18, 2011 at 09:57:07AM +0800, JJ Ding wrote:
quoted
With some EC chips, when we resync due to bad packets, those bad bytes would
still remain in EC's buffer area. That makes us always get bad data back,
no matter what.
So shift packet for 1 byte when encounter bad packet, until we get rid of those
bytes.
If we want to do this I think it should be done in psmouse core.
Thanks.
OK. That sounds more appropriate.
I will remove this patch from the series.
Thanks,
jj
Hi Wanlong Gao,
On Thu, 18 Aug 2011 11:07:23 +0800, Wanlong Gao[off-list ref] wrote:
quoted
On 08/18/2011 09:57 AM, JJ Ding wrote:
quoted
return PSMOUSE_FULL_PACKET;
+
+ bad_packet:
You may introduce space here.
Sorry, I am following you here.
Do you want me to add one more line below bad_packet:,
or you want me to remove the space before bad_packet?
I keep that space to make the goto tags look consistent with other
places in this file.
Should I remove all starting spaces in goto tags in the file?
Thanks,
jj
aha, I see that some with space but some without.
Now, I'm not sure....;)
Thanks
-Wanlong Gao
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Dmitry,
On Wed, 17 Aug 2011 23:38:18 -0700, Dmitry Torokhov [off-list ref] wrote:
On Thu, Aug 18, 2011 at 09:57:06AM +0800, JJ Ding wrote:
quoted
For v2 hardware, there is no real parity check, but we can still check
some constant bits for data integrity.
Signed-off-by: JJ Ding <redacted>
---
drivers/input/mouse/elantech.c | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
Can we please spell out the assumptions under which we decide that
packet is invalid?
Thanks.
--
Dmitry
V2 hardware has two flavors. Older ones that do not report pressure,
and newer ones that reports pressure and width.
With newer ones, all packets (1, 2, 3 finger touch) have the same
constant bits.
With older ones, 1/3 finger touch packets and 2 finger touch packets have
different constant bits.
With all three cases, if the constant bits are not exactly what I
expected, I consider them invalid.
Dmitry, how do you want me to improve this? not enough comments?
Thanks
jj
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Dmitry,
On Wed, 17 Aug 2011 23:00:38 -0700, Dmitry Torokhov [off-list ref] wrote:
On Thu, Aug 18, 2011 at 01:35:55PM +0800, JJ Ding wrote:
quoted
Hi Wanlong Gao, Daniel,
On Thu, 18 Aug 2011 11:08:08 +0800, Wanlong Gao [off-list ref] wrote:
quoted
On 08/18/2011 11:04 AM, Daniel Kurtz wrote:
quoted
Assuming paritycheck goes away:
Agree.
I thought about removing it, too. But it occured to me that v1 and v2
hardware can still have the sysfs entry to turn off parity check.
And since it's exposed in sysfs, I suppose there might be some init
scripts relying on it.
What do you think, Dmitry?
Shall I remove it?
No, we should not remove it, since it is useful for V1 hardware which we
still support.
How confident are we in the V2/V3 checking not tripping on valid packets?
Thanks.
With V2 it should work reasonbaly well. Although I don't have test data,
I didn't encounter any problem turning paritycheck off when testing V2.
With V3 we use the check to distinguish first 2-finger packet and the
second one. So it's mandatory with V3.
Thanks
jj
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 18, 2011 at 03:31:27PM +0800, JJ Ding wrote:
Hi Dmitry,
On Wed, 17 Aug 2011 23:38:18 -0700, Dmitry Torokhov [off-list ref] wrote:
quoted
On Thu, Aug 18, 2011 at 09:57:06AM +0800, JJ Ding wrote:
quoted
For v2 hardware, there is no real parity check, but we can still check
some constant bits for data integrity.
Signed-off-by: JJ Ding <redacted>
---
drivers/input/mouse/elantech.c | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
Can we please spell out the assumptions under which we decide that
packet is invalid?
Thanks.
--
Dmitry
V2 hardware has two flavors. Older ones that do not report pressure,
and newer ones that reports pressure and width.
With newer ones, all packets (1, 2, 3 finger touch) have the same
constant bits.
With older ones, 1/3 finger touch packets and 2 finger touch packets have
different constant bits.
With all three cases, if the constant bits are not exactly what I
expected, I consider them invalid.
Dmitry, how do you want me to improve this? not enough comments?
Right, if you could put the above into comments right in the
packet_simple_check_v2() that woudl be great.
Thanks.
--
Dmitry
Hi JJ
On Thu, 2011-08-18 at 14:06 +0800, Wanlong Gao wrote:
On 08/18/2011 02:01 PM, Daniel Kurtz wrote:
quoted
On Thu, Aug 18, 2011 at 1:44 PM, Wanlong Gao[off-list ref] wrote:
quoted
On 08/18/2011 01:34 PM, Daniel Kurtz wrote:
quoted
On Thu, Aug 18, 2011 at 1:31 PM, Wanlong Gao[off-list ref]
wrote:
quoted
On 08/18/2011 01:26 PM, JJ Ding wrote:
quoted
Hi Wanlong Gao,
On Thu, 18 Aug 2011 11:01:52 +0800, Wanlong
Gao[off-list ref]
wrote:
quoted
On 08/18/2011 09:57 AM, JJ Ding wrote:
quoted
v3 hardware's packet format is almost identical to v2 (one/three
finger
touch),
except when sensing two finger touch, the hardware sends 12 bytes of
data.
Signed-off-by: JJ Ding<redacted>
---
Documentation/input/elantech.txt | 104 ++++++++++++++++--
drivers/input/mouse/elantech.c | 218
++++++++++++++++++++++++++++++++++---
drivers/input/mouse/elantech.h | 11 ++
3 files changed, 303 insertions(+), 30 deletions(-)
+static int determine_packet_v3(struct psmouse *psmouse)
elantech_check_parity_v1
packet_simple_check_v2
determine_packet_v3
Why not consistent them?
OK, how do these names sound to you?
elantech_check_parity_v1
elantech_packet_check_v2
elantech_packet_check_v3
Thanks,
jj
Yeah, sounds perfectly.
Or just:
elantech_packet_check_v1
elantech_packet_check_v2
elantech_packet_check_v3
I prefer this way.
quoted
quoted
quoted
:)
Hmm... maybe they can go into an elantech_packet_check()?
like:
case 1:
...
case 2:
...
What do you think? ;)
Thanks
-Wanlong Gao
Since we've already parsed the hardware type at this point, it seems
inefficient to parse it again inside another function.
I would prefer individual functions.
Thanks,
-Daniel
Hi Dmitry,
On Thu, 18 Aug 2011 00:52:26 -0700, Dmitry Torokhov [off-list ref] wrote:
On Thu, Aug 18, 2011 at 03:31:27PM +0800, JJ Ding wrote:
quoted
Hi Dmitry,
On Wed, 17 Aug 2011 23:38:18 -0700, Dmitry Torokhov [off-list ref] wrote:
quoted
On Thu, Aug 18, 2011 at 09:57:06AM +0800, JJ Ding wrote:
quoted
For v2 hardware, there is no real parity check, but we can still check
some constant bits for data integrity.
Signed-off-by: JJ Ding <redacted>
---
drivers/input/mouse/elantech.c | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
Can we please spell out the assumptions under which we decide that
packet is invalid?
Thanks.
--
Dmitry
V2 hardware has two flavors. Older ones that do not report pressure,
and newer ones that reports pressure and width.
With newer ones, all packets (1, 2, 3 finger touch) have the same
constant bits.
With older ones, 1/3 finger touch packets and 2 finger touch packets have
different constant bits.
With all three cases, if the constant bits are not exactly what I
expected, I consider them invalid.
Dmitry, how do you want me to improve this? not enough comments?
Right, if you could put the above into comments right in the
packet_simple_check_v2() that woudl be great.
Thanks.
No problem. I will do that.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 18, 2011 at 09:57:09AM +0800, JJ Ding wrote:
v3 hardware's packet format is almost identical to v2 (one/three finger touch),
except when sensing two finger touch, the hardware sends 12 bytes of data.
This looks mostly similar in substance to the patch I sent, although
with some good improvements resulting from your better knowledge of the
hardware :)
One suggestion below. I'll test as soon as my build finishes.
quoted hunk
@@ -582,10 +739,26 @@ static void elantech_set_input_params(struct psmouse *psmouse) input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0); input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0); break;++ case 3:+ input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);+ input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);+ /* range of pressure and width is the same as v2 */+ input_set_abs_params(dev, ABS_PRESSURE, ETP_PMIN_V2,+ ETP_PMAX_V2, 0, 0);+ input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2,+ ETP_WMAX_V2, 0, 0);+ __set_bit(INPUT_PROP_SEMI_MT, dev->propbit);+ input_mt_init_slots(dev, 2);+ input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0);+ input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0);+ break;
The case 3 code is nearly identical to case 2. How about this?
case 2:
__set_bit(BTN_TOOL_QUADTAP, dev->keybit);
/* fall through */
case 3:
input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);
/* range of pressure and width is the same as v2 */
input_set_abs_params(dev, ABS_PRESSURE, ETP_PMIN_V2,
ETP_PMAX_V2, 0, 0);
input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2,
ETP_WMAX_V2, 0, 0);
__set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
input_mt_init_slots(dev, 2);
input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0);
break;
On Thu, Aug 18, 2011 at 08:58:53AM -0500, Seth Forshee wrote:
The case 3 code is nearly identical to case 2. How about this?
case 2:
__set_bit(BTN_TOOL_QUADTAP, dev->keybit);
/* fall through */
case 3:
input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);
/* range of pressure and width is the same as v2 */
input_set_abs_params(dev, ABS_PRESSURE, ETP_PMIN_V2,
ETP_PMAX_V2, 0, 0);
input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2,
ETP_WMAX_V2, 0, 0);
__set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
input_mt_init_slots(dev, 2);
input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0);
break;
Sorry, that should have been:
case 2:
__set_bit(BTN_TOOL_QUADTAP, dev->keybit);
/* fall through */
case 3:
input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);
if (etd->reports_pressure) {
input_set_abs_params(dev, ABS_PRESSURE, ETP_PMIN_V2,
ETP_PMAX_V2, 0, 0);
input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2,
ETP_WMAX_V2, 0, 0);
}
__set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
input_mt_init_slots(dev, 2);
input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0);
break;
On Thu, Aug 18, 2011 at 09:57:09AM +0800, JJ Ding wrote:
quoted hunk
@@ -352,6 +374,94 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse) input_sync(dev); }+/*+ * firmware tells us there's noise.+ */+static inline int debounce(unsigned int x, unsigned int y)+{+ return (x == 0xfff) && (y == 0xfff);+}
This is problematic in my testing, in two ways.
First, it never actually triggers, because the y values passed to it are
not the raw data from the packets and as such are not 0xfff anymore in
the cases you're trying to detect.
Second, I get these packets with 1 and 2 finger touches on the Samsung
NF310, but you only check it in the 3 finger case.
As a result, I'm getting some reports with negative values for the y
position.
You should only report the ABS_[XY] coordinates when fingers != 0. The
xorg synaptics module sees the values reported in that case as
legitimate. This is causing me to see strange behaviors when scrolling
with two-finger drags.
On Thu, Aug 18, 2011 at 08:58:53AM -0500, Seth Forshee wrote:
quoted
The case 3 code is nearly identical to case 2. How about this?
case 2:
__set_bit(BTN_TOOL_QUADTAP, dev->keybit);
/* fall through */
case 3:
input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);
/* range of pressure and width is the same as v2 */
input_set_abs_params(dev, ABS_PRESSURE, ETP_PMIN_V2,
ETP_PMAX_V2, 0, 0);
input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2,
ETP_WMAX_V2, 0, 0);
__set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
input_mt_init_slots(dev, 2);
input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0);
break;
Sorry, that should have been:
case 2:
__set_bit(BTN_TOOL_QUADTAP, dev->keybit);
/* fall through */
case 3:
input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);
if (etd->reports_pressure) {
input_set_abs_params(dev, ABS_PRESSURE, ETP_PMIN_V2,
ETP_PMAX_V2, 0, 0);
input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2,
ETP_WMAX_V2, 0, 0);
}
__set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
input_mt_init_slots(dev, 2);
input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0);
break;
simplify, seems good.
Thanks
-Wanlong Gao
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Seth,
On Thu, 18 Aug 2011 12:39:59 -0500, Seth Forshee [off-list ref] wrote:
On Thu, Aug 18, 2011 at 09:57:09AM +0800, JJ Ding wrote:
quoted
@@ -352,6 +374,94 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse) input_sync(dev); }+/*+ * firmware tells us there's noise.+ */+static inline int debounce(unsigned int x, unsigned int y)+{+ return (x == 0xfff) && (y == 0xfff);+}
This is problematic in my testing, in two ways.
First, it never actually triggers, because the y values passed to it are
not the raw data from the packets and as such are not 0xfff anymore in
the cases you're trying to detect.
Second, I get these packets with 1 and 2 finger touches on the Samsung
NF310, but you only check it in the 3 finger case.
As a result, I'm getting some reports with negative values for the y
position.
Thank you for reporting this bug.
As for now, the following should fix this issue.
I will correct this in v2.
---
You should only report the ABS_[XY] coordinates when fingers != 0. The
xorg synaptics module sees the values reported in that case as
legitimate. This is causing me to see strange behaviors when scrolling
with two-finger drags.
AFAIK, though v2 and v3 differ in packet format, they really report the
same data to the userspace. In this version of v3 support, I even try to
make v2 and v3 report all the data in the same sequnce. If you're seeing
this issue, maybe we should do the same with v2?
Hmm, we should have the same range for ST and MT data and scale MT data
if it has lower resolution to match ST.
So I should just remove y_2ft_max and those ETP_2FT_XXXX in elantech.h,
and do the scale in elantech_report_absolute_v2?
If so, I will create another patch for this change.
Is this OK with you?
Thanks.
jj
On Fri, Aug 19, 2011 at 04:29:57PM +0800, JJ Ding wrote:
quoted
You should only report the ABS_[XY] coordinates when fingers != 0. The
xorg synaptics module sees the values reported in that case as
legitimate. This is causing me to see strange behaviors when scrolling
with two-finger drags.
AFAIK, though v2 and v3 differ in packet format, they really report the
same data to the userspace. In this version of v3 support, I even try to
make v2 and v3 report all the data in the same sequnce. If you're seeing
this issue, maybe we should do the same with v2?
Actually neither v1 nor v2 reports ABS_[XY] unless fingers != 0. In v2
the reporting is in a switch statement on the number of fingers, and 0
is unhandled.
Hmm, we should have the same range for ST and MT data and scale MT data
if it has lower resolution to match ST.
So I should just remove y_2ft_max and those ETP_2FT_XXXX in elantech.h,
and do the scale in elantech_report_absolute_v2?
Humm, yes, I think what Dmitry wants is that both ABS_MT_POSITION_Y and
ABS_Y have the same min and max, and the scaling is done when reading
the data. However, it seems this already what is being tried to be done,
excepted that I mess it up in the latest patch set I sent. I just
noticed it now, sorry :-S
You can see in elantech_report_absolute_v2() in case of 2 fingers:
The part for updating ABS_X, ABS_Y is correct:
input_report_abs(dev, ABS_X, x1 << 2);
input_report_abs(dev, ABS_Y, y1 << 2);
But I forgot to do the same for MT:
elantech_report_semi_mt_data(dev, fingers, x1, y1, x2, y2);
That should be:
elantech_report_semi_mt_data(dev, fingers, x1 << 2, y1 << 2, x2 << 2,
y2 << 2);
Or, even more clean, just move the shift directly into the computation,
like:
y1 = etd->y_max - ((((packet[0] & 0x20) << 3) | packet[2]) << 2);
In such case you can drop completely y_2ft_max, and move the
input_report_abs() outside of the switch.
In addition, I have a couple of more remarks on this patch:
Actually these variables are defined as:
#define ETP_YMAX_V2 ( 768 - ETP_EDGE_FUZZ_V2)
I'd suggest to remove trying being too clever and remove the
ETP_EDGE_FUZZ_V2. They should be just the raw resolution of the device.
Otherwise, they can cause underflow on the Y axis.
Finally, a minor style suggestion, in "case 2:" above, only use one
single "break;" and put the two part in a complete "if-else" statement,
with xmin, y_min all explicit. E.g.:
case 2:
if (etd->fw_version == 0x020800 ||
etd->fw_version == 0x020b00 ||
etd->fw_version == 0x020030) {
*x_min = ETP_XMIN_V2;
*y_min = ETP_YMIN_V2;
*x_max = ETP_XMAX_V2;
*y_max = ETP_YMAX_V2;
} else {
i = (etd->fw_version > 0x020800 &&
etd->fw_version < 0x020900) ? 1 : 2;
*x_min = 0;
*y_min = 0;
*x_max = (etd->capabilities[1] - i) * 64;
*y_max = (etd->capabilities[2] - i) * 64;
}
break;
If so, I will create another patch for this change.
If you could send a new version of this patch with these changes, it'd
be great :-)
Cheers,
Éric
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -376,6 +376,25 @@ static int elantech_check_parity_v1(struct psmouse *psmouse)etd->parity[packet[3]]==p3;}+staticintpacket_simple_check_v2(structpsmouse*psmouse)+{+structelantech_data*etd=psmouse->private;+unsignedchar*packet=psmouse->packet;++if(etd->reports_pressure)+return(packet[0]&0x0c)==0x04&&+(packet[3]&0x0f)==0x02;++if((packet[0]&0xc0)==0x80)+return(packet[0]&0x0c)==0x0c&&+(packet[3]&0x0e)==0x08;++return(packet[0]&0x3c)==0x3c&&+(packet[1]&0xf0)==0x00&&+(packet[3]&0x3e)==0x38&&+(packet[4]&0xf0)==0x00;+}+/**Processbytestreamfrommouseandhandlecompletepackets*/
@@ -398,7 +417,9 @@ static psmouse_ret_t elantech_process_byte(struct psmouse *psmouse)break;case2:-/* We don't know how to check parity in protocol v2 */+if(etd->paritycheck&&!packet_simple_check_v2(psmouse))+returnPSMOUSE_BAD_DATA;+elantech_report_absolute_v2(psmouse);break;}
@@ -799,8 +820,7 @@ int elantech_init(struct psmouse *psmouse)etd->hw_version=2;/* For now show extra debug information */etd->debug=1;-/* Don't know how to do parity checking for version 2 */-etd->paritycheck=0;+etd->paritycheck=1;if(etd->fw_version>=0x020800)etd->reports_pressure=true;
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -791,6 +791,42 @@ static int elantech_reconnect(struct psmouse *psmouse)}/*+*determinehardwareversionandsetsomepropertiesaccordingtoit.+*/+staticvoidelantech_set_properties(structelantech_data*etd)+{+/*+*Assumeeveryversiongreaterthan0x020030isnewEeePCstyle+*hardwarewith6bytepackets,except0x020600+*/+if(etd->fw_version<0x020030||etd->fw_version==0x020600)+etd->hw_version=1;+else+etd->hw_version=2;++/*+*Turnonpacketcheckingbydefault.+*/+etd->paritycheck=1;++/*+*Thisfirmwaresuffersfrommisreportingcoordinateswhen+*atouchactionstartscausingthemousecursororscrolledpage+*tojump.Enableaworkaround.+*/+etd->jumpy_cursor=+(etd->fw_version==0x020022||etd->fw_version==0x020600);++if(etd->hw_version==2){+/* For now show extra debug information */+etd->debug=1;++if(etd->fw_version>=0x020800)+etd->reports_pressure=true;+}+}++/**Initializethetouchpadandcreatesysfsentries*/intelantech_init(structpsmouse*psmouse)
@@ -816,26 +852,9 @@ int elantech_init(struct psmouse *psmouse)}etd->fw_version=(param[0]<<16)|(param[1]<<8)|param[2];--/*-*AssumeeveryversiongreaterthanthisisnewEeePCstyle-*hardwarewith6bytepackets-*/-if(etd->fw_version>=0x020030){-etd->hw_version=2;-/* For now show extra debug information */-etd->debug=1;-etd->paritycheck=1;--if(etd->fw_version>=0x020800)-etd->reports_pressure=true;--}else{-etd->hw_version=1;-etd->paritycheck=1;-}--pr_info("assuming hardware version %d, firmware version %d.%d.%d\n",+elantech_set_properties(etd);+pr_info("assuming hardware version %d "+"(with firmware version 0x%02x%02x%02x)\n",etd->hw_version,param[0],param[1],param[2]);if(synaptics_send_cmd(psmouse,ETP_CAPABILITIES_QUERY,
@@ -847,16 +866,6 @@ int elantech_init(struct psmouse *psmouse)etd->capabilities[0],etd->capabilities[1],etd->capabilities[2]);-/*-*Thisfirmwaresuffersfrommisreportingcoordinateswhen-*atouchactionstartscausingthemousecursororscrolledpage-*tojump.Enableaworkaround.-*/-if(etd->fw_version==0x020022||etd->fw_version==0x020600){-pr_info("firmware version 2.0.34/2.6.0 detected, enabling jumpy cursor workaround\n");-etd->jumpy_cursor=true;-}-if(elantech_set_absolute_mode(psmouse)){pr_err("failed to put touchpad into absolute mode.\n");gotoinit_fail;
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 19, 2011 at 04:29:57PM +0800, JJ Ding wrote:
quoted
quoted
You should only report the ABS_[XY] coordinates when fingers != 0. The
xorg synaptics module sees the values reported in that case as
legitimate. This is causing me to see strange behaviors when scrolling
with two-finger drags.
AFAIK, though v2 and v3 differ in packet format, they really report the
same data to the userspace. In this version of v3 support, I even try to
make v2 and v3 report all the data in the same sequnce. If you're seeing
this issue, maybe we should do the same with v2?
Actually neither v1 nor v2 reports ABS_[XY] unless fingers != 0. In v2
the reporting is in a switch statement on the number of fingers, and 0
is unhandled.
Yes, in other words, in the case of v1 or v2, the switch(fingers) does
nothing if fingers == 0.
Maybe you could do put these 3 lines inside a "if (fingers != 0)":
+ input_report_abs(dev, ABS_X, x1);
+ input_report_abs(dev, ABS_Y, y1);
+ elantech_report_semi_mt_data(dev, fingers, x1, y1, x2, y2);
Éric
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 19, 2011 at 02:41:01PM +0200, Éric Piel wrote:
Op 19-08-11 14:13, Seth Forshee schreef:
quoted
On Fri, Aug 19, 2011 at 04:29:57PM +0800, JJ Ding wrote:
quoted
quoted
You should only report the ABS_[XY] coordinates when fingers != 0. The
xorg synaptics module sees the values reported in that case as
legitimate. This is causing me to see strange behaviors when scrolling
with two-finger drags.
AFAIK, though v2 and v3 differ in packet format, they really report the
same data to the userspace. In this version of v3 support, I even try to
make v2 and v3 report all the data in the same sequnce. If you're seeing
this issue, maybe we should do the same with v2?
Actually neither v1 nor v2 reports ABS_[XY] unless fingers != 0. In v2
the reporting is in a switch statement on the number of fingers, and 0
is unhandled.
Yes, in other words, in the case of v1 or v2, the switch(fingers)
does nothing if fingers == 0.
Maybe you could do put these 3 lines inside a "if (fingers != 0)":
+ input_report_abs(dev, ABS_X, x1);
+ input_report_abs(dev, ABS_Y, y1);
+ elantech_report_semi_mt_data(dev, fingers, x1, y1, x2, y2);
I don't think elantech_report_semi_mt_data() should be moved inside the
condition. It's doing the right thing when fingers is 0.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
v3 hardware's packet format is almost identical to v2 (one/three finger touch),
except when sensing two finger touch, the hardware sends 12 bytes of data.
Signed-off-by: JJ Ding<redacted>
/*
* Set the appropriate event bits for the input subsystem
*/
-static void elantech_set_input_params(struct psmouse *psmouse)
+static int elantech_set_input_params(struct psmouse *psmouse)
{
struct input_dev *dev = psmouse->dev;
struct elantech_data *etd = psmouse->private;
unsigned int x_min = 0, y_min = 0, x_max = 0, y_max = 0, y_2ft_max = 0;
- set_range(psmouse,&x_min,&y_min,&x_max,&y_max,&y_2ft_max);
+ if (set_range(psmouse,&x_min,&y_min,&x_max,&y_max,&y_2ft_max))
+ return -1;
__set_bit(EV_KEY, dev->evbit);
__set_bit(EV_ABS, dev->evbit);
@@ -582,10 +739,26 @@ static void elantech_set_input_params(struct psmouse *psmouse) input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0); input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0); break;++ case 3:+ input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);+ input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);+ /* range of pressure and width is the same as v2 */+ input_set_abs_params(dev, ABS_PRESSURE, ETP_PMIN_V2,+ ETP_PMAX_V2, 0, 0);+ input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2,+ ETP_WMAX_V2, 0, 0);+ __set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
Does v3 have the same limitation in MT about only reporting the edges of
the bounding box? Or are the two fingers always reported independently?
If that is so, you can drop this line :-)
Cheers,
Éric
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Yes, in other words, in the case of v1 or v2, the switch(fingers)
does nothing if fingers == 0.
Maybe you could do put these 3 lines inside a "if (fingers != 0)":
+ input_report_abs(dev, ABS_X, x1);
+ input_report_abs(dev, ABS_Y, y1);
+ elantech_report_semi_mt_data(dev, fingers, x1, y1, x2, y2);
I don't think elantech_report_semi_mt_data() should be moved inside the
condition. It's doing the right thing when fingers is 0.
Oh, right, it already tests for this case :-) My mistake.
Éric
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Seth,
On Fri, 19 Aug 2011 07:13:08 -0500, Seth Forshee [off-list ref] wrote:
On Fri, Aug 19, 2011 at 04:29:57PM +0800, JJ Ding wrote:
quoted
quoted
You should only report the ABS_[XY] coordinates when fingers != 0. The
xorg synaptics module sees the values reported in that case as
legitimate. This is causing me to see strange behaviors when scrolling
with two-finger drags.
AFAIK, though v2 and v3 differ in packet format, they really report the
same data to the userspace. In this version of v3 support, I even try to
make v2 and v3 report all the data in the same sequnce. If you're seeing
this issue, maybe we should do the same with v2?
Actually neither v1 nor v2 reports ABS_[XY] unless fingers != 0. In v2
the reporting is in a switch statement on the number of fingers, and 0
is unhandled.
Yes, You are right. Sorry I misread your reply about this. I will fix
this as you suggested.
jj
Hi Éric,
Thanks for your comments, a few lines below:
On Fri, 19 Aug 2011 15:03:04 +0200, Éric Piel [off-list ref] wrote:
Op 18-08-11 03:57, JJ Ding schreef:
quoted
v3 hardware's packet format is almost identical to v2 (one/three finger touch),
except when sensing two finger touch, the hardware sends 12 bytes of data.
Signed-off-by: JJ Ding<redacted>
I like this compact version, but it seems to me this is not as straight
forward as the original switch case. I am OK with either. Is there
anyone who has more to say about this?
/*
* Set the appropriate event bits for the input subsystem
*/
-static void elantech_set_input_params(struct psmouse *psmouse)
+static int elantech_set_input_params(struct psmouse *psmouse)
{
struct input_dev *dev = psmouse->dev;
struct elantech_data *etd = psmouse->private;
unsigned int x_min = 0, y_min = 0, x_max = 0, y_max = 0, y_2ft_max = 0;
- set_range(psmouse,&x_min,&y_min,&x_max,&y_max,&y_2ft_max);
+ if (set_range(psmouse,&x_min,&y_min,&x_max,&y_max,&y_2ft_max))
+ return -1;
__set_bit(EV_KEY, dev->evbit);
__set_bit(EV_ABS, dev->evbit);
@@ -582,10 +739,26 @@ static void elantech_set_input_params(struct psmouse *psmouse) input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0); input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0); break;++ case 3:+ input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);+ input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);+ /* range of pressure and width is the same as v2 */+ input_set_abs_params(dev, ABS_PRESSURE, ETP_PMIN_V2,+ ETP_PMAX_V2, 0, 0);+ input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2,+ ETP_WMAX_V2, 0, 0);+ __set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
Does v3 have the same limitation in MT about only reporting the edges of
the bounding box? Or are the two fingers always reported independently?
If that is so, you can drop this line :-)
I suppose it's the same as v2, but I have to comfirm with our firmware team.
I will ckeck this.
Cheers,
Éric
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi JJ
On Mon, 2011-08-22 at 14:05 +0800, JJ Ding wrote:
Hi Éric,
Thanks for your comments, a few lines below:
On Fri, 19 Aug 2011 15:03:04 +0200, Éric Piel [off-list ref] wrote:
quoted
Op 18-08-11 03:57, JJ Ding schreef:
quoted
v3 hardware's packet format is almost identical to v2 (one/three finger touch),
except when sensing two finger touch, the hardware sends 12 bytes of data.
Signed-off-by: JJ Ding<redacted>
I like this compact version, but it seems to me this is not as straight
forward as the original switch case. I am OK with either. Is there
anyone who has more to say about this?
Éric's version is compact but this is not straight forward as original
code and does not improve more performances. Then other versions of
"elantech_report_absolute" also needed to modify the same style . so I
prefer original style.
/*
* Set the appropriate event bits for the input subsystem
*/
-static void elantech_set_input_params(struct psmouse *psmouse)
+static int elantech_set_input_params(struct psmouse *psmouse)
{
struct input_dev *dev = psmouse->dev;
struct elantech_data *etd = psmouse->private;
unsigned int x_min = 0, y_min = 0, x_max = 0, y_max = 0, y_2ft_max = 0;
- set_range(psmouse,&x_min,&y_min,&x_max,&y_max,&y_2ft_max);
+ if (set_range(psmouse,&x_min,&y_min,&x_max,&y_max,&y_2ft_max))
+ return -1;
__set_bit(EV_KEY, dev->evbit);
__set_bit(EV_ABS, dev->evbit);
@@ -582,10 +739,26 @@ static void elantech_set_input_params(struct psmouse *psmouse) input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0); input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0); break;++ case 3:+ input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);+ input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);+ /* range of pressure and width is the same as v2 */+ input_set_abs_params(dev, ABS_PRESSURE, ETP_PMIN_V2,+ ETP_PMAX_V2, 0, 0);+ input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2,+ ETP_WMAX_V2, 0, 0);+ __set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
Does v3 have the same limitation in MT about only reporting the edges of
the bounding box? Or are the two fingers always reported independently?
If that is so, you can drop this line :-)
I suppose it's the same as v2, but I have to comfirm with our firmware team.
I will ckeck this.
Cheers,
Éric
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hmm, we should have the same range for ST and MT data and scale MT data
if it has lower resolution to match ST.
I saw this go by a while back and it made sense to me at the time.
However, I've had some thoughts that give me pause.
Seth Forshee has been working on getting a semi-mt driver for ALPS
devices. The ALPS devices have an interesting mechanism for providing
multitouch data, but it boils down to having a resolution of only 15
values in the X axis and 11 in the Y axis (it looks possible to
extrapolate and get double the resolution, but my point will remain).
Let's take the X synaptics module as an example of the repercussions of
in-kernel axis scaling. The X synaptics module translates two touch
drags into scroll events. Synaptics will want to use the highest
resolution axis for generating scroll events. If both the MT and ST axes
have the same resolution, it might pick the MT axes for scrolling. On
ALPS devices with in-kernel axis scaling that would be a bad choice.
It's trivial to project the MT and ST axes onto each other in userspace.
I suggest we report the real range and resolution of ST and MT axes
independently.
-- Chase
Hmm, we should have the same range for ST and MT data and scale MT data
if it has lower resolution to match ST.
I saw this go by a while back and it made sense to me at the time.
However, I've had some thoughts that give me pause.
Seth Forshee has been working on getting a semi-mt driver for ALPS
devices. The ALPS devices have an interesting mechanism for providing
multitouch data, but it boils down to having a resolution of only 15
values in the X axis and 11 in the Y axis (it looks possible to
extrapolate and get double the resolution, but my point will remain).
Let's take the X synaptics module as an example of the repercussions of
in-kernel axis scaling. The X synaptics module translates two touch
drags into scroll events. Synaptics will want to use the highest
resolution axis for generating scroll events. If both the MT and ST axes
have the same resolution, it might pick the MT axes for scrolling. On
ALPS devices with in-kernel axis scaling that would be a bad choice.
I don't know about the ALPS devices, but since we already report
ABS_MT_POSITION_{X,Y} with elantech v2, we have to do the scaling in
kernel anyway to adhere to multitouch protocol. So I would say it is
still more appropriate to have the same resolution for ST and MT with
respect to elantech v2. Maybe ALPS should be considered an exception to this?
It's trivial to project the MT and ST axes onto each other in userspace.
I suggest we report the real range and resolution of ST and MT axes
independently.
Hmm, we should have the same range for ST and MT data and scale MT data
if it has lower resolution to match ST.
I saw this go by a while back and it made sense to me at the time.
However, I've had some thoughts that give me pause.
Seth Forshee has been working on getting a semi-mt driver for ALPS
devices. The ALPS devices have an interesting mechanism for providing
multitouch data, but it boils down to having a resolution of only 15
values in the X axis and 11 in the Y axis (it looks possible to
extrapolate and get double the resolution, but my point will remain).
Let's take the X synaptics module as an example of the repercussions of
in-kernel axis scaling. The X synaptics module translates two touch
drags into scroll events. Synaptics will want to use the highest
resolution axis for generating scroll events. If both the MT and ST axes
have the same resolution, it might pick the MT axes for scrolling. On
ALPS devices with in-kernel axis scaling that would be a bad choice.
I don't know about the ALPS devices, but since we already report
ABS_MT_POSITION_{X,Y} with elantech v2, we have to do the scaling in
kernel anyway to adhere to multitouch protocol. So I would say it is
still more appropriate to have the same resolution for ST and MT with
respect to elantech v2. Maybe ALPS should be considered an exception to this?
The multitouch protocol doesn't require scaling of axes to match, at
least not according to the protocol documentation.
I see that the current code scales the coordinates for v2, but it's only
half-resolution. That's not a huge deal since the resolution of modern
touchpads is very high. We could leave it scaled to not break abi, if
that was a concern. However, with new devices it makes sense to state
the ranges in terms of what the device actually supports. Otherwise,
we're just masking out useful data that userspace could be using.
-- Chase
Hmm, we should have the same range for ST and MT data and scale MT data
if it has lower resolution to match ST.
I saw this go by a while back and it made sense to me at the time.
However, I've had some thoughts that give me pause.
Seth Forshee has been working on getting a semi-mt driver for ALPS
devices. The ALPS devices have an interesting mechanism for providing
multitouch data, but it boils down to having a resolution of only 15
values in the X axis and 11 in the Y axis (it looks possible to
extrapolate and get double the resolution, but my point will remain).
Let's take the X synaptics module as an example of the repercussions of
in-kernel axis scaling. The X synaptics module translates two touch
drags into scroll events. Synaptics will want to use the highest
resolution axis for generating scroll events. If both the MT and ST axes
have the same resolution, it might pick the MT axes for scrolling. On
ALPS devices with in-kernel axis scaling that would be a bad choice.
I don't know about the ALPS devices, but since we already report
ABS_MT_POSITION_{X,Y} with elantech v2, we have to do the scaling in
kernel anyway to adhere to multitouch protocol. So I would say it is
still more appropriate to have the same resolution for ST and MT with
respect to elantech v2. Maybe ALPS should be considered an exception to this?
The multitouch protocol doesn't require scaling of axes to match, at
least not according to the protocol documentation.
I see that the current code scales the coordinates for v2, but it's only
half-resolution. That's not a huge deal since the resolution of modern
touchpads is very high. We could leave it scaled to not break abi, if
that was a concern. However, with new devices it makes sense to state
the ranges in terms of what the device actually supports. Otherwise,
we're just masking out useful data that userspace could be using.
I disagree. I believe that ST and MT ranges reported for the same
working surface should match, especially since many devices derive ST
data from MT.
As far as devices that have ranges 0-15 in MT mode - I am not sure how
useful such MT steam anyway and if we are better of just ignore them
(maybe just use the data to report number of fingers on the surface but
otherwise use standard ST protocol).
Thanks.
--
Dmitry
Hmm, we should have the same range for ST and MT data and scale MT data
if it has lower resolution to match ST.
I saw this go by a while back and it made sense to me at the time.
However, I've had some thoughts that give me pause.
Seth Forshee has been working on getting a semi-mt driver for ALPS
devices. The ALPS devices have an interesting mechanism for providing
multitouch data, but it boils down to having a resolution of only 15
values in the X axis and 11 in the Y axis (it looks possible to
extrapolate and get double the resolution, but my point will remain).
Let's take the X synaptics module as an example of the repercussions of
in-kernel axis scaling. The X synaptics module translates two touch
drags into scroll events. Synaptics will want to use the highest
resolution axis for generating scroll events. If both the MT and ST axes
have the same resolution, it might pick the MT axes for scrolling. On
ALPS devices with in-kernel axis scaling that would be a bad choice.
I don't know about the ALPS devices, but since we already report
ABS_MT_POSITION_{X,Y} with elantech v2, we have to do the scaling in
kernel anyway to adhere to multitouch protocol. So I would say it is
still more appropriate to have the same resolution for ST and MT with
respect to elantech v2. Maybe ALPS should be considered an exception to this?
The multitouch protocol doesn't require scaling of axes to match, at
least not according to the protocol documentation.
I see that the current code scales the coordinates for v2, but it's only
half-resolution. That's not a huge deal since the resolution of modern
touchpads is very high. We could leave it scaled to not break abi, if
that was a concern. However, with new devices it makes sense to state
the ranges in terms of what the device actually supports. Otherwise,
we're just masking out useful data that userspace could be using.
I disagree. I believe that ST and MT ranges reported for the same
working surface should match, especially since many devices derive ST
data from MT.
As far as devices that have ranges 0-15 in MT mode - I am not sure how
useful such MT steam anyway and if we are better of just ignore them
(maybe just use the data to report number of fingers on the surface but
otherwise use standard ST protocol).
The MT data could still be useful for pinch to zoom or potentially
rotate (though most low res devices probably are only semi-mt). I don't
want to forsake pinch to zoom just because we can't pass on the
resolution of MT data properly.
-- Chase
Hmm, we should have the same range for ST and MT data and scale MT data
if it has lower resolution to match ST.
I saw this go by a while back and it made sense to me at the time.
However, I've had some thoughts that give me pause.
Seth Forshee has been working on getting a semi-mt driver for ALPS
devices. The ALPS devices have an interesting mechanism for providing
multitouch data, but it boils down to having a resolution of only 15
values in the X axis and 11 in the Y axis (it looks possible to
extrapolate and get double the resolution, but my point will remain).
Let's take the X synaptics module as an example of the repercussions of
in-kernel axis scaling. The X synaptics module translates two touch
drags into scroll events. Synaptics will want to use the highest
resolution axis for generating scroll events. If both the MT and ST axes
have the same resolution, it might pick the MT axes for scrolling. On
ALPS devices with in-kernel axis scaling that would be a bad choice.
I don't know about the ALPS devices, but since we already report
ABS_MT_POSITION_{X,Y} with elantech v2, we have to do the scaling in
kernel anyway to adhere to multitouch protocol. So I would say it is
still more appropriate to have the same resolution for ST and MT with
respect to elantech v2. Maybe ALPS should be considered an exception to this?
The multitouch protocol doesn't require scaling of axes to match, at
least not according to the protocol documentation.
I see that the current code scales the coordinates for v2, but it's only
half-resolution. That's not a huge deal since the resolution of modern
touchpads is very high. We could leave it scaled to not break abi, if
that was a concern. However, with new devices it makes sense to state
the ranges in terms of what the device actually supports. Otherwise,
we're just masking out useful data that userspace could be using.
I disagree. I believe that ST and MT ranges reported for the same
working surface should match, especially since many devices derive ST
data from MT.
As far as devices that have ranges 0-15 in MT mode - I am not sure how
useful such MT steam anyway and if we are better of just ignore them
(maybe just use the data to report number of fingers on the surface but
otherwise use standard ST protocol).
The MT data could still be useful for pinch to zoom or potentially
rotate (though most low res devices probably are only semi-mt). I don't
want to forsake pinch to zoom just because we can't pass on the
resolution of MT data properly.
How would userspace know that MT data should only be used for gestures
but nothign else? By examining range? What is the "too small range"
then? It would be different for different devices. I do not want
userspace portions of the drivers to turn into unmanageble collection of
quirks.
Some hardware is just hopeless... And pinch to zoom is cute but hardly
most used function on a laptop (as opposed to phone/tablet), I'd just
leave it be.
Thanks.
--
Dmitry
From: Henrik Rydberg <hidden> Date: 2011-09-06 18:44:54
quoted
quoted
I see that the current code scales the coordinates for v2, but it's only
half-resolution. That's not a huge deal since the resolution of modern
touchpads is very high. We could leave it scaled to not break abi, if
that was a concern. However, with new devices it makes sense to state
the ranges in terms of what the device actually supports. Otherwise,
we're just masking out useful data that userspace could be using.
I disagree. I believe that ST and MT ranges reported for the same
working surface should match, especially since many devices derive ST
data from MT.
As far as devices that have ranges 0-15 in MT mode - I am not sure how
useful such MT steam anyway and if we are better of just ignore them
(maybe just use the data to report number of fingers on the surface but
otherwise use standard ST protocol).
The MT data could still be useful for pinch to zoom or potentially
rotate (though most low res devices probably are only semi-mt). I don't
want to forsake pinch to zoom just because we can't pass on the
resolution of MT data properly.
We are not forsaking anything. At best, the detail missed out by using
the same scaling for ST and MT is the ability to distinguish the axis
with the best or poorest resolution. However, some devices report
higher MT than ST resolution, not because it is better (it is indeed
worse), but simply to not lose bits in the filtering process. In other
words: the logic is not without corner cases, and it only makes a
difference to the transitional devices that are not fully MT
capable. If this really was a concern, userspace could use the ST
coordinates for some transformations instead.
Henrik
From: Chase Douglas <hidden> Date: 2011-09-06 18:58:44
On 09/06/2011 11:47 AM, Henrik Rydberg wrote:
quoted
quoted
quoted
I see that the current code scales the coordinates for v2, but it's only
half-resolution. That's not a huge deal since the resolution of modern
touchpads is very high. We could leave it scaled to not break abi, if
that was a concern. However, with new devices it makes sense to state
the ranges in terms of what the device actually supports. Otherwise,
we're just masking out useful data that userspace could be using.
I disagree. I believe that ST and MT ranges reported for the same
working surface should match, especially since many devices derive ST
data from MT.
As far as devices that have ranges 0-15 in MT mode - I am not sure how
useful such MT steam anyway and if we are better of just ignore them
(maybe just use the data to report number of fingers on the surface but
otherwise use standard ST protocol).
The MT data could still be useful for pinch to zoom or potentially
rotate (though most low res devices probably are only semi-mt). I don't
want to forsake pinch to zoom just because we can't pass on the
resolution of MT data properly.
We are not forsaking anything. At best, the detail missed out by using
the same scaling for ST and MT is the ability to distinguish the axis
with the best or poorest resolution. However, some devices report
higher MT than ST resolution, not because it is better (it is indeed
worse), but simply to not lose bits in the filtering process. In other
words: the logic is not without corner cases, and it only makes a
difference to the transitional devices that are not fully MT
capable. If this really was a concern, userspace could use the ST
coordinates for some transformations instead.
So what do we want userspace to do? In the absence of supplying this
information we need to provide guidelines. We could say:
* Always use ST coords + finger count for drag gestures (i.e. scrolling)
* Use MT coords for pinch and rotate
If this is acceptable, we should add it to the documentation. Thoughts?
-- Chase
Hmm, we should have the same range for ST and MT data and scale MT data
if it has lower resolution to match ST.
I saw this go by a while back and it made sense to me at the time.
However, I've had some thoughts that give me pause.
Seth Forshee has been working on getting a semi-mt driver for ALPS
devices. The ALPS devices have an interesting mechanism for providing
multitouch data, but it boils down to having a resolution of only 15
values in the X axis and 11 in the Y axis (it looks possible to
extrapolate and get double the resolution, but my point will remain).
Let's take the X synaptics module as an example of the repercussions of
in-kernel axis scaling. The X synaptics module translates two touch
drags into scroll events. Synaptics will want to use the highest
resolution axis for generating scroll events. If both the MT and ST axes
have the same resolution, it might pick the MT axes for scrolling. On
ALPS devices with in-kernel axis scaling that would be a bad choice.
I don't know about the ALPS devices, but since we already report
ABS_MT_POSITION_{X,Y} with elantech v2, we have to do the scaling in
kernel anyway to adhere to multitouch protocol. So I would say it is
still more appropriate to have the same resolution for ST and MT with
respect to elantech v2. Maybe ALPS should be considered an exception to this?
The multitouch protocol doesn't require scaling of axes to match, at
least not according to the protocol documentation.
I see that the current code scales the coordinates for v2, but it's only
half-resolution. That's not a huge deal since the resolution of modern
touchpads is very high. We could leave it scaled to not break abi, if
that was a concern. However, with new devices it makes sense to state
the ranges in terms of what the device actually supports. Otherwise,
we're just masking out useful data that userspace could be using.
I disagree. I believe that ST and MT ranges reported for the same
working surface should match, especially since many devices derive ST
data from MT.
As far as devices that have ranges 0-15 in MT mode - I am not sure how
useful such MT steam anyway and if we are better of just ignore them
(maybe just use the data to report number of fingers on the surface but
otherwise use standard ST protocol).
The MT data could still be useful for pinch to zoom or potentially
rotate (though most low res devices probably are only semi-mt). I don't
want to forsake pinch to zoom just because we can't pass on the
resolution of MT data properly.
How would userspace know that MT data should only be used for gestures
but nothign else? By examining range? What is the "too small range"
then? It would be different for different devices. I do not want
userspace portions of the drivers to turn into unmanageble collection of
quirks.
I wasn't suggesting that it have a big switch that enables or disables
gestures. I just want userspace to be able to figure out whether ST or
MT data would be better for a given task. If the range of the ST and MT
axes could provide this data, then it makes sense to do so. The test
wouldn't be like "is MT range big enough", it would be "is MT range
better than ST or vice versa".
However, Henrik pointed out that some devices report ranges that aren't
representative of how accurate or precise they really are. That
invalidates this approach.
Some hardware is just hopeless... And pinch to zoom is cute but hardly
most used function on a laptop (as opposed to phone/tablet), I'd just
leave it be.
Just because a piece of hardware is imprecise does not mean it is
useless for gestures. Sure, it may not work that great for precision
zooming, but it would be good enough for threshold matching. The Unity
window manager uses these thresholds to fire actions like spread (or
"expose" in OS X terms).
-- Chase
Hmm, we should have the same range for ST and MT data and scale MT data
if it has lower resolution to match ST.
I saw this go by a while back and it made sense to me at the time.
However, I've had some thoughts that give me pause.
Seth Forshee has been working on getting a semi-mt driver for ALPS
devices. The ALPS devices have an interesting mechanism for providing
multitouch data, but it boils down to having a resolution of only 15
values in the X axis and 11 in the Y axis (it looks possible to
extrapolate and get double the resolution, but my point will remain).
Let's take the X synaptics module as an example of the repercussions of
in-kernel axis scaling. The X synaptics module translates two touch
drags into scroll events. Synaptics will want to use the highest
resolution axis for generating scroll events. If both the MT and ST axes
have the same resolution, it might pick the MT axes for scrolling. On
ALPS devices with in-kernel axis scaling that would be a bad choice.
I don't know about the ALPS devices, but since we already report
ABS_MT_POSITION_{X,Y} with elantech v2, we have to do the scaling in
kernel anyway to adhere to multitouch protocol. So I would say it is
still more appropriate to have the same resolution for ST and MT with
respect to elantech v2. Maybe ALPS should be considered an exception to this?
The multitouch protocol doesn't require scaling of axes to match, at
least not according to the protocol documentation.
I see that the current code scales the coordinates for v2, but it's only
half-resolution. That's not a huge deal since the resolution of modern
touchpads is very high. We could leave it scaled to not break abi, if
that was a concern. However, with new devices it makes sense to state
the ranges in terms of what the device actually supports. Otherwise,
we're just masking out useful data that userspace could be using.
I disagree. I believe that ST and MT ranges reported for the same
working surface should match, especially since many devices derive ST
data from MT.
As far as devices that have ranges 0-15 in MT mode - I am not sure how
useful such MT steam anyway and if we are better of just ignore them
(maybe just use the data to report number of fingers on the surface but
otherwise use standard ST protocol).
The MT data could still be useful for pinch to zoom or potentially
rotate (though most low res devices probably are only semi-mt). I don't
want to forsake pinch to zoom just because we can't pass on the
resolution of MT data properly.
How would userspace know that MT data should only be used for gestures
but nothign else? By examining range? What is the "too small range"
then? It would be different for different devices. I do not want
userspace portions of the drivers to turn into unmanageble collection of
quirks.
I wasn't suggesting that it have a big switch that enables or disables
gestures. I just want userspace to be able to figure out whether ST or
MT data would be better for a given task. If the range of the ST and MT
axes could provide this data, then it makes sense to do so. The test
wouldn't be like "is MT range big enough", it would be "is MT range
better than ST or vice versa".
However, Henrik pointed out that some devices report ranges that aren't
representative of how accurate or precise they really are. That
invalidates this approach.
quoted
Some hardware is just hopeless... And pinch to zoom is cute but hardly
most used function on a laptop (as opposed to phone/tablet), I'd just
leave it be.
Just because a piece of hardware is imprecise does not mean it is
useless for gestures. Sure, it may not work that great for precision
zooming, but it would be good enough for threshold matching. The Unity
window manager uses these thresholds to fire actions like spread (or
"expose" in OS X terms).
-- Chase
As far as I can tell, when the pad reports exactly 2 fingers, it
reports them both with half the resolution with which it would report
a single finger (in the 1 finger or 3 fingers cases).
It sounded like Chase was recommending to report "ST" at full
resolution and "MT" at half resolution. Thus, if there is 1 finger,
we would throw away 1 bit for the MT report. If there were 2 fingers,
we would inflate the ST reported finger by one bit.
I prefer the original behavior of this patch, which just always
reports ST and MT using the ST scale.
-Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html