Skip to contentSkip to conversation

Bug: touchpad unresponsive after resume from S3 (psmouse driver)

DISCUSSION Daniel Manrique 2 participants 9 messages Nov 29, 2011 – Dec 2, 2011

Subsystems (2)
HID Input drivers
lore
Share & tools
lore

Daniel Manrique

author
#0 lore raw

Hello,

I apologize for sending this bug report directly; with the kernel.org bugtracker down I was told this was the best option for the time being. If this is not correct, could you please let me know of a good place to submit this bug report?

I have several Dell laptops with Synaptics touchpads, particularly a group of Vostro V13 systems. On these, after a suspend/resume cycle, the touchpad (Synaptics) is unresponsive; a workaround is to rmmod psmouse; modprobe psmouse.

This was first reported on kernel 2.6.38, although I think the issue has been present from as early as 2.6.32. I verified it for sure with Ubuntu 2.6.38 kernels, 3.0.0 kernels, and a 3.2.0 kernel from the development release, as well as a "mainline" 3.1.0-rc10 kernel.

Since this problem was seen on Ubuntu, it's filed on the Launchpad bug tracker. The first report I can find is this one:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/715267

This includes a series of log messages I don't see on my systems. I then filed this other bug:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/879650

The last one contains specific information from one of my systems (a Vostro V13).

I'd really appreciate any help or guidance on how to solve this problem. If you need me to collect any information or run any tests on these machines, please don't hesitate to ask, these systems are primarily used for testing.

Thanks in advance,

- Daniel Manrique
[email protected]

maintainer
#1 lore raw

Hi Daniel,

Quoted 23 lines · Daniel Manrique

Hello,

I apologize for sending this bug report directly; with the kernel.org bugtracker down I was told this was the best option for the time being. If this is not correct, could you please let me know of a good place to submit this bug report?

I have several Dell laptops with Synaptics touchpads, particularly a group of Vostro V13 systems. On these, after a suspend/resume cycle, the touchpad (Synaptics) is unresponsive; a workaround is to rmmod psmouse; modprobe psmouse.

This was first reported on kernel 2.6.38, although I think the issue has been present from as early as 2.6.32. I verified it for sure with Ubuntu 2.6.38 kernels, 3.0.0 kernels, and a 3.2.0 kernel from the development release, as well as a "mainline" 3.1.0-rc10 kernel.

Since this problem was seen on Ubuntu, it's filed on the Launchpad bug tracker. The first report I can find is this one:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/715267

This includes a series of log messages I don't see on my systems. I then filed this other bug:

Quoted 8 lines

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/879650

The last one contains specific information from one of my systems (a Vostro V13).

I'd really appreciate any help or guidance on how to solve this problem. If you need me to collect any information or run any tests on these machines, please don't hesitate to ask, these systems are primarily used for testing.

Please do:

- enable i8042 debug (echo 1 > /sys/module/i8042/parameters/debug)
- rmmod psmouse;
- suspend/resume;
- collect dmesg;
- suspend/resume;
- collect dmesg again

and we'll have to try and find what we do differently.

Thanks.

Signature · 1 line
Dmitry
author
#2 lore raw
Quoted 44 lines · Dmitry Torokhov

Hi Daniel,

Quoted 23 lines · Daniel Manrique

Hello,

I apologize for sending this bug report directly; with the kernel.org bugtracker down I was told this was the best option for the time being. If this is not correct, could you please let me know of a good place to submit this bug report?

I have several Dell laptops with Synaptics touchpads, particularly a group of Vostro V13 systems. On these, after a suspend/resume cycle, the touchpad (Synaptics) is unresponsive; a workaround is to rmmod psmouse; modprobe psmouse.

This was first reported on kernel 2.6.38, although I think the issue has been present from as early as 2.6.32. I verified it for sure with Ubuntu 2.6.38 kernels, 3.0.0 kernels, and a 3.2.0 kernel from the development release, as well as a "mainline" 3.1.0-rc10 kernel.

Since this problem was seen on Ubuntu, it's filed on the Launchpad bug tracker. The first report I can find is this one:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/715267

This includes a series of log messages I don't see on my systems. I then filed this other bug:

Quoted 8 lines

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/879650

The last one contains specific information from one of my systems (a Vostro V13).

I'd really appreciate any help or guidance on how to solve this problem. If you need me to collect any information or run any tests on these machines, please don't hesitate to ask, these systems are primarily used for testing.

Please do:

- enable i8042 debug (echo 1 > /sys/module/i8042/parameters/debug)
- rmmod psmouse;
- suspend/resume;
- collect dmesg;
- suspend/resume;
- collect dmesg again

Quoted 4 lines

and we'll have to try and find what we do differently.

Thanks.

Hi Dmitry,

Thanks so much for the quick reply!

I just ran the tests you requested with some extra steps which I hope won't confuse things. Here's the sequence I followed:

- Enabled i8042 debug
- sudo rmmod psmouse. Touchpad of course becomes unresponsive.
- sudo pm-suspend
- Wake the machine by pressing power
- At this point touchpad is unresponsive.
- Collected dmesg-1.txt
- sudo pm-suspend
- wake the machine by pressing power
- At this point touchpad is still unresponsive.
- Collected dmesg-2.txt
- sudo modprobe psmouse. Touchpad begins responding.
- Collected dmesg-3.txt
- sudo pm-suspend
- wake the machine by pressing power
- At this point touchpad is again unresponsive.
- Collected dmesg-4.txt

To avoid attaching largish files to this email, I put the logs on a publically-accessible http server at:
http://people.canonical.com/~roadmr/lp715267/. Please let me know if you prefer something else.

Thanks in advance for your help!

- Daniel Manrique

maintainer
#3 lore raw
Quoted 74 lines · Daniel Manrique
Quoted 44 lines · Dmitry Torokhov

Hi Daniel,

Quoted 23 lines · Daniel Manrique

Hello,

I apologize for sending this bug report directly; with the kernel.org bugtracker down I was told this was the best option for the time being. If this is not correct, could you please let me know of a good place to submit this bug report?

I have several Dell laptops with Synaptics touchpads, particularly a group of Vostro V13 systems. On these, after a suspend/resume cycle, the touchpad (Synaptics) is unresponsive; a workaround is to rmmod psmouse; modprobe psmouse.

This was first reported on kernel 2.6.38, although I think the issue has been present from as early as 2.6.32. I verified it for sure with Ubuntu 2.6.38 kernels, 3.0.0 kernels, and a 3.2.0 kernel from the development release, as well as a "mainline" 3.1.0-rc10 kernel.

Since this problem was seen on Ubuntu, it's filed on the Launchpad bug tracker. The first report I can find is this one:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/715267

This includes a series of log messages I don't see on my systems. I then filed this other bug:

Quoted 8 lines

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/879650

The last one contains specific information from one of my systems (a Vostro V13).

I'd really appreciate any help or guidance on how to solve this problem. If you need me to collect any information or run any tests on these machines, please don't hesitate to ask, these systems are primarily used for testing.

Please do:

- enable i8042 debug (echo 1 > /sys/module/i8042/parameters/debug)
- rmmod psmouse;
- suspend/resume;
- collect dmesg;
- suspend/resume;
- collect dmesg again

Quoted 4 lines

and we'll have to try and find what we do differently.

Thanks.

Hi Dmitry,

Thanks so much for the quick reply!

I just ran the tests you requested with some extra steps which I hope won't confuse things. Here's the sequence I followed:

- Enabled i8042 debug
- sudo rmmod psmouse. Touchpad of course becomes unresponsive.
- sudo pm-suspend
- Wake the machine by pressing power
- At this point touchpad is unresponsive.
- Collected dmesg-1.txt
- sudo pm-suspend
- wake the machine by pressing power
- At this point touchpad is still unresponsive.
- Collected dmesg-2.txt
- sudo modprobe psmouse. Touchpad begins responding.
- Collected dmesg-3.txt
- sudo pm-suspend
- wake the machine by pressing power
- At this point touchpad is again unresponsive.
- Collected dmesg-4.txt

Quoted 5 lines

To avoid attaching largish files to this email, I put the logs on a publically-accessible http server at:
http://people.canonical.com/~roadmr/lp715267/. Please let me know if you prefer something else.

Hmm, it just does not want to admit that it is synaptics after reset. Does the patch below help any?

Signature · 12 lines
Dmitry


Input: synaptics - delay in reconnect

From: Dmitry Torokhov <[email protected]>

Signed-off-by: Dmitry Torokhov <[email protected]>
---

 drivers/input/mouse/synaptics.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)
drivers/input/mouse/synaptics.c +12 -0
index 06c9ee5..fa127ec 100644
@@ -1279,6 +1279,7 @@ static void synaptics_disconnect(struct psmouse *psmouse)
 	psmouse->private = NULL;
 }
 
+#include <linux/delay.h>
 static int synaptics_reconnect(struct psmouse *psmouse)
 {
 	struct synaptics_data *priv = psmouse->private;

@@ -1288,6 +1289,17 @@ static int synaptics_reconnect(struct psmouse *psmouse)
 
 	do {
 		psmouse_reset(psmouse);
+		if (retry) {
+			unsigned char param[2];
+
+			psmouse_info(psmouse, "Delaying after reset.\n");
+			ssleep(1);
+
+			psmouse_info(psmouse, "Querying ID.\n");
+			param[0] = 0xa5;
+			error = ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_GETID);
+			psmouse_info(psmouse, "ID: %x %x (%d).\n", param[0], param[1], error);
+		}
 		error = synaptics_detect(psmouse, 0);
 	} while (error && ++retry < 3);
author
#4 lore raw
Quoted 75 lines · Dmitry Torokhov
Quoted 74 lines · Daniel Manrique
Quoted 44 lines · Dmitry Torokhov

Hi Daniel,

Quoted 23 lines · Daniel Manrique

Hello,

I apologize for sending this bug report directly; with the kernel.org bugtracker down I was told this was the best option for the time being. If this is not correct, could you please let me know of a good place to submit this bug report?

I have several Dell laptops with Synaptics touchpads, particularly a group of Vostro V13 systems. On these, after a suspend/resume cycle, the touchpad (Synaptics) is unresponsive; a workaround is to rmmod psmouse; modprobe psmouse.

This was first reported on kernel 2.6.38, although I think the issue has been present from as early as 2.6.32. I verified it for sure with Ubuntu 2.6.38 kernels, 3.0.0 kernels, and a 3.2.0 kernel from the development release, as well as a "mainline" 3.1.0-rc10 kernel.

Since this problem was seen on Ubuntu, it's filed on the Launchpad bug tracker. The first report I can find is this one:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/715267

This includes a series of log messages I don't see on my systems. I then filed this other bug:

Quoted 8 lines

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/879650

The last one contains specific information from one of my systems (a Vostro V13).

I'd really appreciate any help or guidance on how to solve this problem. If you need me to collect any information or run any tests on these machines, please don't hesitate to ask, these systems are primarily used for testing.

Please do:

- enable i8042 debug (echo 1 > /sys/module/i8042/parameters/debug)
- rmmod psmouse;
- suspend/resume;
- collect dmesg;
- suspend/resume;
- collect dmesg again

Quoted 4 lines

and we'll have to try and find what we do differently.

Thanks.

Hi Dmitry,

Thanks so much for the quick reply!

I just ran the tests you requested with some extra steps which I hope won't confuse things. Here's the sequence I followed:

- Enabled i8042 debug
- sudo rmmod psmouse. Touchpad of course becomes unresponsive.
- sudo pm-suspend
- Wake the machine by pressing power
- At this point touchpad is unresponsive.
- Collected dmesg-1.txt
- sudo pm-suspend
- wake the machine by pressing power
- At this point touchpad is still unresponsive.
- Collected dmesg-2.txt
- sudo modprobe psmouse. Touchpad begins responding.
- Collected dmesg-3.txt
- sudo pm-suspend
- wake the machine by pressing power
- At this point touchpad is again unresponsive.
- Collected dmesg-4.txt

Quoted 8 lines
Quoted 5 lines

To avoid attaching largish files to this email, I put the logs on a publically-accessible http server at:
http://people.canonical.com/~roadmr/lp715267/. Please let me know if you prefer something else.

Hmm, it just does not want to admit that it is synaptics after reset. Does the patch below help any?

Hi Dmitry,

I applied the patch to a 3.2-series kernel (based off 3.2-rc3 I think). It applied cleanly to psmouse.c, and after compiling the driver and putting it in place of the old psmouse.ko, the touchpad works after resuming from suspend!

I did a comparison test by swapping drivers (old vs. new) without rebooting, by rmmodding the existing psmouse driver, putting the old/new file in place, reloading the driver and doing a suspend/resume cycle. Consistently, with the old/original driver I still see the problem, but with the new/patched driver the touchpad is always enabled after resume.

i only tested this on one of the failing Vostro V13, please let me know if I should test for anything like possible misbehaviors on other previously-working systems or some other kind of regression.

But still, this patch seems to work fine, thanks for this! What's the next step for getting this fix into the official kernel? Anything I can do to help?

Thanks again,

- Daniel

maintainer
#5 lore raw
Quoted 97 lines · Daniel Manrique
Quoted 75 lines · Dmitry Torokhov
Quoted 74 lines · Daniel Manrique
Quoted 44 lines · Dmitry Torokhov

Hi Daniel,

Quoted 23 lines · Daniel Manrique

Hello,

I apologize for sending this bug report directly; with the kernel.org bugtracker down I was told this was the best option for the time being. If this is not correct, could you please let me know of a good place to submit this bug report?

I have several Dell laptops with Synaptics touchpads, particularly a group of Vostro V13 systems. On these, after a suspend/resume cycle, the touchpad (Synaptics) is unresponsive; a workaround is to rmmod psmouse; modprobe psmouse.

This was first reported on kernel 2.6.38, although I think the issue has been present from as early as 2.6.32. I verified it for sure with Ubuntu 2.6.38 kernels, 3.0.0 kernels, and a 3.2.0 kernel from the development release, as well as a "mainline" 3.1.0-rc10 kernel.

Since this problem was seen on Ubuntu, it's filed on the Launchpad bug tracker. The first report I can find is this one:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/715267

This includes a series of log messages I don't see on my systems. I then filed this other bug:

Quoted 8 lines

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/879650

The last one contains specific information from one of my systems (a Vostro V13).

I'd really appreciate any help or guidance on how to solve this problem. If you need me to collect any information or run any tests on these machines, please don't hesitate to ask, these systems are primarily used for testing.

Please do:

- enable i8042 debug (echo 1 > /sys/module/i8042/parameters/debug)
- rmmod psmouse;
- suspend/resume;
- collect dmesg;
- suspend/resume;
- collect dmesg again

Quoted 4 lines

and we'll have to try and find what we do differently.

Thanks.

Hi Dmitry,

Thanks so much for the quick reply!

I just ran the tests you requested with some extra steps which I hope won't confuse things. Here's the sequence I followed:

- Enabled i8042 debug
- sudo rmmod psmouse. Touchpad of course becomes unresponsive.
- sudo pm-suspend
- Wake the machine by pressing power
- At this point touchpad is unresponsive.
- Collected dmesg-1.txt
- sudo pm-suspend
- wake the machine by pressing power
- At this point touchpad is still unresponsive.
- Collected dmesg-2.txt
- sudo modprobe psmouse. Touchpad begins responding.
- Collected dmesg-3.txt
- sudo pm-suspend
- wake the machine by pressing power
- At this point touchpad is again unresponsive.
- Collected dmesg-4.txt

Quoted 8 lines
Quoted 5 lines

To avoid attaching largish files to this email, I put the logs on a publically-accessible http server at:
http://people.canonical.com/~roadmr/lp715267/. Please let me know if you prefer something else.

Hmm, it just does not want to admit that it is synaptics after reset. Does the patch below help any?

Hi Dmitry,

I applied the patch to a 3.2-series kernel (based off 3.2-rc3 I think). It applied cleanly to psmouse.c, and after compiling the driver and putting it in place of the old psmouse.ko, the touchpad works after resuming from suspend!

I did a comparison test by swapping drivers (old vs. new) without rebooting, by rmmodding the existing psmouse driver, putting the old/new file in place, reloading the driver and doing a suspend/resume cycle. Consistently, with the old/original driver I still see the problem, but with the new/patched driver the touchpad is always enabled after resume.

Quoted 7 lines

i only tested this on one of the failing Vostro V13, please let me know if I should test for anything like possible misbehaviors on other previously-working systems or some other kind of regression.

But still, this patch seems to work fine, thanks for this! What's the next step for getting this fix into the official kernel? Anything I can do to help?

Could you please try removing either ssleep(1) or querying of device ID from the patch and see which one of them actually fixes the issue?

Thanks!

Signature · 1 line
Dmitry
author
#6 lore raw
Quoted 102 lines · Dmitry Torokhov
Quoted 101 lines · Daniel Manrique
Quoted 75 lines · Dmitry Torokhov
Quoted 74 lines · Daniel Manrique
Quoted 44 lines · Dmitry Torokhov

Hi Daniel,

Quoted 23 lines · Daniel Manrique

Hello,

I apologize for sending this bug report directly; with the kernel.org bugtracker down I was told this was the best option for the time being. If this is not correct, could you please let me know of a good place to submit this bug report?

I have several Dell laptops with Synaptics touchpads, particularly a group of Vostro V13 systems. On these, after a suspend/resume cycle, the touchpad (Synaptics) is unresponsive; a workaround is to rmmod psmouse; modprobe psmouse.

This was first reported on kernel 2.6.38, although I think the issue has been present from as early as 2.6.32. I verified it for sure with Ubuntu 2.6.38 kernels, 3.0.0 kernels, and a 3.2.0 kernel from the development release, as well as a "mainline" 3.1.0-rc10 kernel.

Since this problem was seen on Ubuntu, it's filed on the Launchpad bug tracker. The first report I can find is this one:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/715267

This includes a series of log messages I don't see on my systems. I then filed this other bug:

Quoted 8 lines

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/879650

The last one contains specific information from one of my systems (a Vostro V13).

I'd really appreciate any help or guidance on how to solve this problem. If you need me to collect any information or run any tests on these machines, please don't hesitate to ask, these systems are primarily used for testing.

Please do:

- enable i8042 debug (echo 1 > /sys/module/i8042/parameters/debug)
- rmmod psmouse;
- suspend/resume;
- collect dmesg;
- suspend/resume;
- collect dmesg again

Quoted 4 lines

and we'll have to try and find what we do differently.

Thanks.

Hi Dmitry,

Thanks so much for the quick reply!

I just ran the tests you requested with some extra steps which I hope won't confuse things. Here's the sequence I followed:

- Enabled i8042 debug
- sudo rmmod psmouse. Touchpad of course becomes unresponsive.
- sudo pm-suspend
- Wake the machine by pressing power
- At this point touchpad is unresponsive.
- Collected dmesg-1.txt
- sudo pm-suspend
- wake the machine by pressing power
- At this point touchpad is still unresponsive.
- Collected dmesg-2.txt
- sudo modprobe psmouse. Touchpad begins responding.
- Collected dmesg-3.txt
- sudo pm-suspend
- wake the machine by pressing power
- At this point touchpad is again unresponsive.
- Collected dmesg-4.txt

Quoted 8 lines
Quoted 5 lines

To avoid attaching largish files to this email, I put the logs on a publically-accessible http server at:
http://people.canonical.com/~roadmr/lp715267/. Please let me know if you prefer something else.

Hmm, it just does not want to admit that it is synaptics after reset. Does the patch below help any?

Hi Dmitry,

I applied the patch to a 3.2-series kernel (based off 3.2-rc3 I think). It applied cleanly to psmouse.c, and after compiling the driver and putting it in place of the old psmouse.ko, the touchpad works after resuming from suspend!

I did a comparison test by swapping drivers (old vs. new) without rebooting, by rmmodding the existing psmouse driver, putting the old/new file in place, reloading the driver and doing a suspend/resume cycle. Consistently, with the old/original driver I still see the problem, but with the new/patched driver the touchpad is always enabled after resume.

i only tested this on one of the failing Vostro V13, please let me know if I should test for anything like possible misbehaviors on other previously-working systems or some other kind of regression.

Quoted 6 lines
Quoted 3 lines

But still, this patch seems to work fine, thanks for this! What's the next step for getting this fix into the official kernel? Anything I can do to help?

Could you please try removing either ssleep(1) or querying of device ID from the patch and see which one of them actually fixes the issue?

Hi Dmitry,

Certainly! I compiled and tested two new versions of the module, one with the "delaying after reset" code commented out, the other with the "querying ID" block commented out.

The ssleep(1); line is what appears to do the trick; the version that just queries the ID exhibits the same problem I reported initially, while the one that just ssleeps works fine, with the touchpad working OK after resuming.

I'll await further instructions on this, thanks so much for your help!

- Daniel

Quoted 2 lines

Thanks!

maintainer
#7 lore raw
Quoted 7 lines · Daniel Manrique

The ssleep(1); line is what appears to do the trick; the version that just queries the ID exhibits the same problem I reported initially, while the one that just ssleeps works fine, with the touchpad working OK after resuming.

I'll await further instructions on this, thanks so much for your help!

OK, great. Could you please try the patch below to make sure it works as intended and I'll queue it to upstream/stable?

Thanks.

Signature · 21 lines
Dmitry

Input: synaptics - fix touchpad not working after S2R on Vostro V13

From: Dmitry Torokhov <[email protected]>

Synaptics touchpads on several Dell laptops, particularly Vostro V13
systems, may not respond properly to PS/2 commands and queries immediately
after resuming from suspend to RAM. This leads to unresponsive touchpad
after suspend/resume cycle.

Adding a 1-second delay after resetting the device allows touchpad to
finish initializing (calibrating?) and start reacting properly.

Reported-by: Daniel Manrique <[email protected]>
Tested-by: Daniel Manrique <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
---

 drivers/input/mouse/synaptics.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)
drivers/input/mouse/synaptics.c +11 -0
index 06c9ee5..8081a0a 100644
@@ -24,6 +24,7 @@
  */
 
 #include <linux/module.h>
+#include <linux/delay.h>
 #include <linux/dmi.h>
 #include <linux/input/mt.h>
 #include <linux/serio.h>

@@ -1288,6 +1289,16 @@ static int synaptics_reconnect(struct psmouse *psmouse)
 
 	do {
 		psmouse_reset(psmouse);
+		if (retry) {
+			/*
+			 * On some boxes, right after resuming, the touchpad
+			 * needs some time to finish initializing (I assume
+			 * it needs time to calibrate) and start responding
+			 * to Synaptics-specific queries, so let's wait a
+			 * bit.
+			 */
+			ssleep(1);
+		}
 		error = synaptics_detect(psmouse, 0);
 	} while (error && ++retry < 3);
author
#8 lore raw
Quoted 6 lines · Dmitry Torokhov
Quoted 5 lines · Daniel Manrique

The ssleep(1); line is what appears to do the trick; the version that just queries the ID exhibits the same problem I reported initially, while the one that just ssleeps works fine, with the touchpad working OK after resuming.

Quoted 8 lines
Quoted 2 lines

I'll await further instructions on this, thanks so much for your help!

OK, great. Could you please try the patch below to make sure it works as intended and I'll queue it to upstream/stable?

Thanks.

Hi Dmitry!

I tried the attached patch and tested just as before, I created two versions of the module, one with the patch, one without, and tested them.

Yes, the code in the patch works as it did before, and the touchpad works fine after resuming. I tried several times with both modules to be sure, and results are consistent every time (i.e. patched module works, unpatched one always fails)

Thanks for this!

- Daniel