Elantech touchpad does not work on Asus

Hi all,

I looked at the bugzilla bugreport on
https://bugzilla.kernel.org/show_bug.cgi?id=84491
"Elantech touchpad does not work on Asus TransformerBook Flip 500"

There are problems reported on two variants:
Asus TransformerBook Flip TP500LN
Asus TP500LN

George (in CC:) helped me to investigate on his hardware what happened by trying a few patches and reporting what happens.

It seems that the absolute mode setting somehow gets cancelled after the elantech drivers initializes. This results in relative motion packets coming in, elantech driver not recognizing them and consequentially "lost sync at byte 6" messages.

When one, after the psmouse driver is loaded, does the following:
echo 1 > /sys/devices/platform/i8042/serio4/reg_07
,the touchpad will work like a charm until suspend2ram. After a suspend2ram, another echo is required.

This exact same value is written during initialization of v4 hardware. As a test, I even read it back in elantech_set_absolute_mode after writing and at that moment in the driver the value 1 is read.

But when one performs the read later on the commandline of reg_07, value 0 is read, so probably for a reason unknown to me, the value goes to 0 because of some timeout or serio communiation.

I also tried putting elantech_set_input_params call in front of elantech_set_absolute_mode, but that didn't help either.

Also the suspend2ram seems to result in the same thing.

Anyone an idea why this reg_07 1 value could become a 0 between the time the function elantech_set_absolute_mode during loading of the psmouse module and the time when reading the value from sysfs from the command line ?

Hi Ulrik,

Quoted 34 lines · On Thu, Mar 19, 2015 at 11:05:46PM +0100, [email protected] wrote:

Hi all,

I looked at the bugzilla bugreport on
https://bugzilla.kernel.org/show_bug.cgi?id=84491
"Elantech touchpad does not work on Asus TransformerBook Flip 500"

There are problems reported on two variants:
Asus TransformerBook Flip TP500LN
Asus TP500LN

George (in CC:) helped me to investigate on his hardware what happened by trying a few patches and reporting what happens.

It seems that the absolute mode setting somehow gets cancelled after the elantech drivers initializes. This results in relative motion packets coming in, elantech driver not recognizing them and consequentially "lost sync at byte 6" messages.

When one, after the psmouse driver is loaded, does the following:
echo 1 > /sys/devices/platform/i8042/serio4/reg_07
,the touchpad will work like a charm until suspend2ram. After a suspend2ram, another echo is required.

This exact same value is written during initialization of v4 hardware. As a test, I even read it back in elantech_set_absolute_mode after writing and at that moment in the driver the value 1 is read.

But when one performs the read later on the commandline of reg_07, value 0 is read, so probably for a reason unknown to me, the value goes to 0 because of some timeout or serio communiation.

I also tried putting elantech_set_input_params call in front of elantech_set_absolute_mode, but that didn't help either.

Quoted 6 lines

Also the suspend2ram seems to result in the same thing.

Anyone an idea why this reg_07 1 value could become a 0 between the time the function elantech_set_absolute_mode during loading of the psmouse module and the time when reading the value from sysfs from the command line ?

Hmm, so after Elantech code has done with the init you see the correct value in r7? Psmouse driver does [re]set scale, rate and resolution after protocol has been initialized, maybe that confuses Elantech in the same fashion as it does Focaltech?

Thanks.

Signature · 1 line

Dmitry

On Asus TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done.

In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that perfoms the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware).

Also the asus TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c

Reported-and-tested-by George Moutsopoulos <[email protected]>

Signed-off-by Ulrik De Bie <[email protected]>

---
 drivers/input/mouse/elantech.c | 22 ++++++++++++++++++++++
 drivers/input/mouse/elantech.h |  1 +
 2 files changed, 23 insertions(+)

drivers/input/mouse/elantech.c +2 -0

index 6e22682..991dc6b 100644
@@ -893,6 +893,21 @@ static psmouse_ret_t elantech_process_byte(struct psmouse *psmouse)
 }
 
 /*
+ * This writes the reg_07 value again to the hardware at the end of every
+ * set_rate call because the register loses its value. reg_07 allows setting

Hi Ulrik,

Quoted 35 lines · Ulrik De Bie

On Asus TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done.

In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that perfoms the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware).

Also the asus TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c

Reported-and-tested-by George Moutsopoulos <[email protected]>

Signed-off-by Ulrik De Bie <[email protected]>

---
 drivers/input/mouse/elantech.c | 22 ++++++++++++++++++++++
 drivers/input/mouse/elantech.h |  1 +
 2 files changed, 23 insertions(+)

drivers/input/mouse/elantech.c +8 -0

index 6e22682..991dc6b 100644
@@ -893,6 +893,21 @@ static psmouse_ret_t elantech_process_byte(struct psmouse *psmouse)
 }
 
 /*
+ * This writes the reg_07 value again to the hardware at the end of every
+ * set_rate call because the register loses its value. reg_07 allows setting
+ * absolute mode on v4 hardware
+ */
+static void elantech_set_rate_restore_reg_07(struct psmouse *psmouse,
+		unsigned int rate)
+{
+	struct elantech_data *etd = psmouse->private;

drivers/input/mouse/elantech.c static psmouse_ret_t elantech_process_byte(struct psmouse *psmouse) · line 907

Quoted 4 lines

drivers/input/mouse/elantech.c +4 -0

+
+	etd->original_set_rate(psmouse, rate);
+	if (elantech_write_reg(psmouse, 0x07, etd->reg_07))
+		psmouse_err(psmouse, "restoring reg_07 failed\n");

I wonder if set rate is useful for Elantech and if it would not be simpler to just have an empty stub for set_rate, maybe even for all Elantech devices?

Quoted 38 lines · Dmitry Torokhov

Hi Ulrik,

Quoted 35 lines · Ulrik De Bie

On Asus TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done.

In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that perfoms the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware).

Also the asus TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c

Reported-and-tested-by George Moutsopoulos <[email protected]>

Signed-off-by Ulrik De Bie <[email protected]>

---
 drivers/input/mouse/elantech.c | 22 ++++++++++++++++++++++
 drivers/input/mouse/elantech.h |  1 +
 2 files changed, 23 insertions(+)

drivers/input/mouse/elantech.c +8 -0

index 6e22682..991dc6b 100644
@@ -893,6 +893,21 @@ static psmouse_ret_t elantech_process_byte(struct psmouse *psmouse)
 }
 
 /*
+ * This writes the reg_07 value again to the hardware at the end of every
+ * set_rate call because the register loses its value. reg_07 allows setting
+ * absolute mode on v4 hardware
+ */
+static void elantech_set_rate_restore_reg_07(struct psmouse *psmouse,
+		unsigned int rate)
+{
+	struct elantech_data *etd = psmouse->private;

Quoted 8 lines

drivers/input/mouse/elantech.c static psmouse_ret_t elantech_process_byte(struct psmouse *psmouse) · line 907

Quoted 4 lines

drivers/input/mouse/elantech.c +4 -0

+
+	etd->original_set_rate(psmouse, rate);
+	if (elantech_write_reg(psmouse, 0x07, etd->reg_07))
+		psmouse_err(psmouse, "restoring reg_07 failed\n");

I wonder if set rate is useful for Elantech and if it would not be simpler to just have an empty stub for set_rate, maybe even for all Elantech devices?

1) all Elantech devices ?
I've considered it for all elantech devices, but I've no idea how this might effect all elantech devices out there.
I did a simple test on my work laptop with elantech. Setting the rate to a value lower than 10 does disable the mouse, setting it to a value higher than 10 enables it again. I would not describe that as 'useful' but not performing a set_rate 100 could give issues on touchpads that do work now. => I think best not all elantech devices because of backwards compatibility issues

2) selectivity of Elantech device
In this patch I used the firmware version, which will probably match with all (and no more than the ) elantech chips out there that have this issue. I could go for dmi table code, but then we will probably have to extend this for a couple of years with more and more rows in the table.
=> preference for firmare version above dmi

3) empty stub instead of set_rate+fixup
Could work, but needs verification because currently set_rate is called with 100 and I don't know what the default is. Of course, ideally the sysfs would then report back that the rate reading/writing is not supported, or the rate sysfs file would not exist at all.
=> small preference for actually performing the set_rate