Description of problem: After resume from standby, touchpad is unresponsive. Dell XPS 13 6350
Version-Release number of selected component (if applicable): N: Name="Synaptics TM3038-002"
How reproducible:
Every time it resumes from Standy
Steps to Reproduce:
1. Shut laptop lid;
2. Open Laptop lid;
3.
Actual results: Unresponsive touchpad. Doesn't respond to clicks or movement.
Expected results: Touchpad should respond to clicks and movement.
Additional info:
I'm not sure what information I can give you here. There doesn't appear to be an obvious errors in dmesg. The same number of Kernel modules are loaded before and after standby. I'm unsure which module I should be looking at to troubleshoot this issue. Feel free to request any information that may assist getting this issue resolved.

I'm encountering this problem on a Dell XPS 9360/Synaptics TM3038-003.
- I did not have the problem on Fedora 25
- When the touchpad is unresponsive, I can get it back into a working state by suspending again and resuming quickly. i.e. it only repros after longer suspends.

(In reply to Martin Kretzschmar from comment #4)
> I'm encountering this problem on a Dell XPS 9360/Synaptics TM3038-003.
>
> - I did not have the problem on Fedora 25
>
> - When the touchpad is unresponsive, I can get it back into a working state
> by suspending again and resuming quickly. i.e. it only repros after longer
> suspends.
Hey Martin. Which Kernel are you running?
This issue seems to be resolved under kernel 4.11.0-0.rc8.git0.1.fc26.x86_64 and rc7. I was only having the issue under rc6.

I'm still having this with an XPS 13 on kernel 4.11.3-300.fc26.x86_64. The short suspend/resume trip works sometimes, but pretty rarely, so I've just gotten used to rebooting after every suspend :/
I no longer have the ability to adjust severity in this bugzilla, but if I did, I'd mark this "high": the user's operation is pretty significantly disrupted if, in 2017, they can't reliably use the computer after a suspend.
(Ironically, I upgraded from F25->F26a because in F25, gnome-shell would crash all the time after a suspend/resume, but at least that didn't require a reboot to fix :/

I should point out, I'm not convinced this bug is kernel related. I've upgraded from f25 to f26 and after the problem occurred, I used a couple of the older f25 kernels to see if it was the kernel and I still have the same issue, but suspend and resume was working fine in f25 with the same kernels.
I've also tried using the f26 live image booting from a usb stick, but it has the same issue too. (I was checking to see if a fresh install had the same issue, or if it was related to upgrading from f25 to f26)

Rodd: from comment #3> Evemu recording shows that no input is being detected by the touchpad after Resume.
This guarantees that it's a kernel related issue because if evemu doesn't see events, nothing else will either. Which means disabling the device in userspace (e.g. xinput disable <device name>) won't do anything.

Confirming that Bernard's "fix" (rmmod/modprobe) works here.
Unfortunately rmmod'ing hid_multitouch does not help; I'd hoped that would be the case (the multitouch is irritating way more than it is helpful, so I wouldn't mind disabling if that would "solve" this bug...)

Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing and this issue seems to have been resolved (for me).
I've done a couple of suspend and resume cycles and while the touch doesn't seem to be responsive initially, it does start working after a second or so.
Obviously, it would be good to hear from others about their experience too.
I'm not sure what this kernel was supposed be testing for.

No, do not close!
I am using kernel 4.12.8-300.fc26.x86_64 and still have this problem:
- synaptics touchpad on lenovo t440
- put laptop to sleep
- resume
- touchpad is working, but i cannot use 'right-click' and two-finger scrolling
xinput properties are the same after reboot (when touchpad is working fine) and after sleep/resume
My workaround so far is to do (as root) after every(!) resume:
echo -n "reconnect" > /sys/bus/serio/devices/serio1/drvctl
Then, all is fine again, two-finger scrolling, right click....
That is very annoying!

a short update:
kernel 4.12.9-300.fc26.x86_64 / plasma 5.10.5 seems to have some updates regarding the touchpad.
Now - after sleep/resume - the touchpad recognizes right-clicks and can scroll using two fingers, but it still seems not quite right.
After the 'reconnect' of comment 28 everyting is really good again.

For what it is worth:
Same issue since F26 on a Thinkpad T440s. Suspending and resuming results in a partly or fully unresponsive touchpad. Touchpad settings visible and correct after resume.
I am on kernel version 4.12.9-300.fc26.x86_64 with Gnome.
Out of frustration started changing settings in 'Power' (I am not technical enough to understand much of the logs etc.)
Changed the 'Suspend & Power button' setting 'When the power button is pressed from 'suspend' to 'nothing'.
After 3 suspend-resume cycles (closing the lid) the touchpad is working every time.
For me the best workaround so far. Hope this helps anyone else as well.

(In reply to slartibart70 from comment #28)
> My workaround so far is to do (as root) after every(!) resume:
> echo -n "reconnect" > /sys/bus/serio/devices/serio1/drvctl
Thank you! I have the same problem with a Thinkpad T440p and this works to make the touchpad useful again.
Is this a kernel issue, maybe something aduggan@synaptics.com can help with?

It looks like there are two separate issues here. The initial comments describe HID/I2C touchpads not working after resume. This issue was fixed upstream with commit cac72b990d34f4c70208998a86f910ba38253c94. It looks like this fix is not quite in Ubuntu 17.10, but should be soon when the release a new kernel which pulls in the fix.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1723145
The Thinkpads have PS2 / SMBus touchpads so while the behavior is similar the underlying cause is different. It sounds like the touchpad might not be in the correct mode after resuming. Can someone post dmesg output from after a resume from a T440?

The issue persists on T440s after a clean install of Fedora 27 Workstation and a fully updated installation. The behavior seems stochastic, ranging from a totally unresponsive touchpad to fully functional.

I have a similar problem (Thinkpad W540, touchpad two finger scrolling doesn't work after resume) and the above workaround fixes it. In addition, I found this upstream bug that suggests a kernel parameter to fix it:
https://bugs.freedesktop.org/show_bug.cgi?id=103149
I'm testing it now and will report back if it fixes it.

We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. The kernel moves very fast so bugs may get fixed as part of a kernel update. Due to this, we are doing a mass bug update across all of the Fedora 26 kernel bugs.
Fedora 26 has now been rebased to 4.15.4-200.fc26. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you have moved on to Fedora 27, and are still experiencing this issue, please change the version to Fedora 27.
If you experience different issues, please open a new bug report for those.

I'm still having the problem with 4.15.4-300.fc27.x86_64 on Fedora 27 -- how do I update the version to Fedora 27 for this issue? I don't want it to continue to be ignored. As much as I would like to just get rid of this laptop, I would appreciate someone from Red Hat or better yet Synaptics taking ownership of this issue instead of just ignoring it hoping it goes away.

As the Freedesktop bug said, booting with the kernel parameter psmouse.synaptics_intertouch=0 fixes the problem entirely for me.
(unfortunately 4.15.x won't reliably suspend anymore on my W540, so it's hard to test, but it did fix the problem on 4.14.x)

(In reply to bztdlinux from comment #44)
> As the Freedesktop bug said, booting with the kernel parameter
> psmouse.synaptics_intertouch=0 fixes the problem entirely for me.
>
> (unfortunately 4.15.x won't reliably suspend anymore on my W540, so it's
> hard to test, but it did fix the problem on 4.14.x)
well, as I wrote it works for me on 4.14 without that kernel parameter.
So the parameter itself is probably fix only for some other HW issues or different version of HW driver not for what is installed in T460p.

Hello, I have the same problem. My touchpad does not work after suspend on kernel-4.15.4 and kernel-4.15.6. Moreover I cant suspend again after I already suspended once since restart.
I have Lenovo T460p as well and fedora 26.
With the kernel-4.14.14 it worked as expected.
I tried to reload rmi_smbus to work around this problem like this:
sudo modprobe -r rmi_smbus && sudo modprobe rmi_smbus
It fixed the disability to suspend again, however the touchpad still didn't work.
I have attached the logs I got from dmesg after suspend.

My T460p running Fedora 26 is also affected. Kernel version is 4.15.6-200.fc26.x86_64. The trick with smouse.synaptics_intertouch=0 seems to fix the standby issues and makes the touchpad/trackpoint work after resume.

I've double checked and the kernel parameter 'psmouse.synaptics_intertouch=0' is a valid workaround on my Lenovo T460p.
For those with a T460p where the latter is not working, I'm running vanilla Fedora 27, and my T460p is almost 2 years old. So the only thing I can think of is a different Synaptics device.
[ 1.471715] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps: 0xf006a3/0x943300/0x12e800/0x10000, board id: 3053, fw id: 2010421
[ 1.471718] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0

Yes, setting the psmouse.synaptics_intertouch to 0 will disable using the SMBus interface for the touchpad which is causing this issue. It looks like the root cause is an issue in Lenovo's BIOS. More details in the following message.
https://bugzilla.redhat.com/show_bug.cgi?id=1442699

I updated to 4.15.7-300.fc27.x86_64 today and the bug still exists on my T460p.
The "psmouse.synaptics_intertouch=0" workaround still works for me.
I updated the kernel to 4.15.7, ran
sudo grubby --update-kernel=DEFAULT --args="psmouse.synaptics_intertouch=1" && shutdown -r now
to test if the kernel update has fixed the issue, and my touchpad went back to not responding & GNOME becomes unable to suspend after running "systemctl suspend" twice.
(I assume --remove-args="psmouse.synaptics_intertouch" would achieve the same result)
Thus, I added the workaround back again with
sudo grubby --update-kernel=DEFAULT --args="psmouse.synaptics_intertouch=0"