Since 37548659bb2 moved the querying of the x_max/y_max
values from elantech_set_input_params to elantech_query_info,
the returned x_max/y_max values are different than before,
at least for some firmware versions.
The reason is likely that this is now done before
elantech_set_absolute_mode does run. So it may happen that
the returned values are exactly half of what they used to be,
which makes input_report_abs in PS/2 mode report ABS_X values which
exceed the x_max value, which is very annoying since the mouse stops
to move then, and ABS_Y value become negative, which is benign.
This was observed with a MSI GX70 laptop:
elantech: assuming hardware version 3 (with firmware version 0x250f01)
elantech: Synaptics capabilities query result 0x18, 0x17, 0x0b.
elantech: Elan sample query result 05, 0e, 00
input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio...
Correct this by doubling the returned x_max and y_max
value for this specific firmware version.
Fixes: 37548659bb2 ("Input: elantech - query the min/max
information beforehand too")
Signed-off-by: Bernd Edlinger <redacted>
---
drivers/input/mouse/elantech.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 2d8434b..3399db8 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1720,6 +1720,10 @@ static int elantech_query_info(struct psmouse *psmouse,
info->x_max = (0x0f & param[0]) << 8 | param[1];
info->y_max = (0xf0 & param[0]) << 4 | param[2];
+ if (info->fw_version == 0x250f01) {
+ info->x_max <<= 1;
+ info->y_max <<= 1;
+ }
break;
case 4:--
1.9.1
Hi Bernd,
[adding Dave and Jingle]
On Thu, Feb 27, 2020 at 12:59 PM Bernd Edlinger
[off-list ref] wrote:
Since 37548659bb2 moved the querying of the x_max/y_max
Hmm, I am pretty sure checkpatch.pl should have complained here: the
correct way of mentioning a previous commit is:
'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit
37548659bb22 ("Input: elantech - query the min/max information
beforehand too")'
values from elantech_set_input_params to elantech_query_info,
the returned x_max/y_max values are different than before,
at least for some firmware versions.
The reason is likely that this is now done before
elantech_set_absolute_mode does run. So it may happen that
the returned values are exactly half of what they used to be,
That is weird. Can we get confirmation from Dave or Jingle about that?
which makes input_report_abs in PS/2 mode report ABS_X values which
exceed the x_max value, which is very annoying since the mouse stops
to move then, and ABS_Y value become negative, which is benign.
This was observed with a MSI GX70 laptop:
elantech: assuming hardware version 3 (with firmware version 0x250f01)
elantech: Synaptics capabilities query result 0x18, 0x17, 0x0b.
elantech: Elan sample query result 05, 0e, 00
input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio...
Correct this by doubling the returned x_max and y_max
value for this specific firmware version.
Fixes: 37548659bb2 ("Input: elantech - query the min/max
information beforehand too")
Stephen will complain here: see multiple google results when you
search for "lkml linux-next: Fixes tag needs some work"
Basically:
- SHA1 should be at least 12 digits long
- the commit title should not be split, even if it gets longer than 80 columns.
Cheers,
Benjamin
quoted hunk
Signed-off-by: Bernd Edlinger <redacted>
---
drivers/input/mouse/elantech.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 2d8434b..3399db8 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1720,6 +1720,10 @@ static int elantech_query_info(struct psmouse *psmouse,
info->x_max = (0x0f & param[0]) << 8 | param[1];
info->y_max = (0xf0 & param[0]) << 4 | param[2];
+ if (info->fw_version == 0x250f01) {
+ info->x_max <<= 1;
+ info->y_max <<= 1;
+ }
break;
case 4:
--1.9.1