Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1442699 - Touchpad unresponsive after resume [NEEDINFO]
Touchpad unresponsive after resume
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
27
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 1471032 1490672 1508705 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-04-17 03:46 EDT by Brendan Shephard
Modified: 2018-03-13 15:01 EDT (History)
43 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-03-12 11:28:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mnovotny: needinfo? (kernel-maint)


Attachments (Terms of Use)
Evemu recording of touchpad events after Resume (4.11 KB, text/plain)
2017-04-18 04:28 EDT, Brendan Shephard
no flags Details
Output from dmesg on T440p after suspend and resume (69.36 KB, text/plain)
2017-11-18 16:47 EST, Trey Tabner
no flags Details
Log of resume after suspend - T460p (93.02 KB, text/plain)
2018-03-07 05:15 EST, Marek Marusic
no flags Details

  None (edit)
Description Brendan Shephard 2017-04-17 03:46:23 EDT
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.
Comment 1 Brendan Shephard 2017-04-17 03:47:53 EDT
Dell XPS 13 9350. Not 6350 sorry.

System Information
	Manufacturer: Dell Inc.
	Product Name: XPS 13 9350
Comment 2 Brendan Shephard 2017-04-18 04:26:08 EDT
No change in loaded Kernel modules before and after resume. e
Comment 3 Brendan Shephard 2017-04-18 04:28 EDT
Created attachment 1272243 [details]
Evemu recording of touchpad events after Resume

Evemu recording shows that no input is being detected by the touchpad after Resume.
Comment 4 Martin Kretzschmar 2017-04-27 14:09:31 EDT
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.
Comment 5 Brendan Shephard 2017-04-27 22:18:36 EDT
(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.
Comment 6 Martin Kretzschmar 2017-04-28 12:30:13 EDT
Oh. I checked and found I was still running rc6. Updated to rc8, left laptop suspended for a couple hours. Touchpad resumes correctly again. Thanks for the followup, Brendan.
Comment 7 Cédric Bellegarde 2017-05-11 01:48:51 EDT
Here with Linux xps13 4.11.0-1.fc26.x86_64 #1 SMP Mon May 1 17:34:37 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Bug is always present. XPS 13 too.
Comment 8 Cédric Bellegarde 2017-05-11 02:32:45 EDT
I can find this in logs, not sure if it's related:
mai 11 08:06:51 xps13 kernel: usb 2-6:1.1: rebind failed: -517
mai 11 08:06:51 xps13 kernel: usb 2-6:1.0: rebind failed: -517
mai 11 08:06:51 xps13 kernel: PM: resume of devices complete after 5656.062 msecs
mai 11 08:06:51 xps13 kernel: PM: Device i2c-DLL060A:00 failed to resume async: error -11
mai 11 08:06:51 xps13 kernel: dpm_run_callback(): i2c_hid_resume+0x0/0xe0 [i2c_hid] returns -11
mai 11 08:06:51 xps13 kernel: rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask.
mai 11 08:06:51 xps13 kernel: hid-rmi 0018:06CB:2734.0002: rmi_hid_read_block: timeout elapsed
mai 11 08:06:51 xps13 kernel: hid-rmi 0018:06CB:2734.0002: rmi_hid_read_block: timeout elapsed
mai 11 08:06:51 xps13 kernel: hid-rmi 0018:06CB:2734.0002: rmi_hid_read_block: timeout elapsed
mai 11 08:06:51 xps13 kernel: hid-rmi 0018:06CB:2734.0002: rmi_hid_read_block: timeout elapsed
mai 11 08:06:51 xps13 kernel: hid-rmi 0018:06CB:2734.0002: rmi_hid_read_block: timeout elapsed
mai 11 08:06:51 xps13 kernel: usb 2-5: reset high-speed USB device number 3 using xhci_hcd
mai 11 08:06:51 xps13 kernel: usb 2-6: reset full-speed USB device number 4 using xhci_hcd
mai 11 08:06:51 xps13 kernel: usb 2-3: reset full-speed USB device number 2 using xhci_hcd
Comment 9 Cédric Bellegarde 2017-05-11 02:35:13 EDT
Ok, looks like my issue is: #1429236
Comment 10 Luis Villa 2017-05-31 00:35:33 EDT
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 :/
Comment 11 Rodd Clarkson 2017-07-14 05:10:13 EDT
I think I'm seeing this on Fedora 26 on a Dell XPS 13 9333.

This is definitely need escalation.  Could it be related to the change to synaptics that occurred moving from fedora 25 to 26?
Comment 12 Rodd Clarkson 2017-07-14 05:26:23 EDT
Or here's another thought.

Both my touchpad and my touchscreen are synaptics devices.  Could they be conflicting on resume?
Comment 13 Luis Villa 2017-07-17 00:34:44 EDT
FWIW, I've also got a touchscreen XPS. The symptoms (fixed by reboots, usually, if fast enough) would be consistent with some sort of race condition, so Rodd may have a good thought.
Comment 14 Peter Hutterer 2017-07-17 23:13:38 EDT
*** Bug 1471032 has been marked as a duplicate of this bug. ***
Comment 15 Rodd Clarkson 2017-07-19 02:00:30 EDT
I'm pretty keen to see suspend / resume working properly, so if there is any information I can provide and testing I can do please ask.
Comment 16 Rodd Clarkson 2017-07-20 22:06:50 EDT
I've just tested libinput-1.8.0-2.fc26.x86_64 and then kernel-4.11.11-300.fc26.x86_64 in updates-testing but they are no better.

Is there some debug I can supply that might help isolate this bug?
Comment 17 Rodd Clarkson 2017-07-20 22:09:47 EDT
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)
Comment 18 Rodd Clarkson 2017-07-20 22:26:17 EDT
Is there a way I can disable my touch screen to test if the synaptics touch screen is conflicting with the synaptics touchpad?
Comment 19 Sebastien Chapuis 2017-07-20 23:44:42 EDT
I disabled the touchscreen on my XPS 13 9350 since I bought it.
I updated to F26 last week and I never had this bug so far.

Rodd you can disable the touchscreen in the BIOS, that's what I did.
Comment 20 Peter Hutterer 2017-07-21 00:09:27 EDT
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.
Comment 21 Rodd Clarkson 2017-07-23 02:05:35 EDT
Ah, here's something.

Noticed that my touchpad is a i2c_hid device (and not usb or pci).  Did a little searching on this and discovered this closes bug: https://bugzilla.redhat.com/show_bug.cgi?id=1250213

Turns out, if I do the following the touchpad starts working again:

$ sudo rmmod i2c_hid
$ sudo modprobe i2c_hid

If I run lsmod after a restart is shows i2c_hid in the output, but it doesn't work without the above.  Does this help track down the problem?

Also, the output from `ls -la /dev/input/by-path/` might be helpful

$ ls -la /dev/input/by-path/
total 0
drwxr-xr-x. 2 root root 160 Jul 23 16:00 .
drwxr-xr-x. 4 root root 500 Jul 23 16:00 ..
lrwxrwxrwx. 1 root root   9 Jul 23 15:57 pci-0000:00:14.0-usb-0:2:1.2-event-mouse -> ../event4
lrwxrwxrwx. 1 root root   9 Jul 23 15:57 pci-0000:00:14.0-usb-0:2:1.2-mouse -> ../mouse0
lrwxrwxrwx. 1 root root   9 Jul 23 15:57 pci-0000:00:14.0-usb-0:3:1.0-event -> ../event6
lrwxrwxrwx. 1 root root  10 Jul 23 15:57 pci-0000:00:14.0-usb-0:5:1.0-event -> ../event14
lrwxrwxrwx. 1 root root  10 Jul 23 16:00 platform-INT33C3:00-event-mouse -> ../event16
lrwxrwxrwx. 1 root root   9 Jul 23 16:00 platform-INT33C3:00-mouse -> ../mouse2

along with this output from dmesg:

[    4.802368] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: s3203, fw id: 1522295
[    4.864404] input: Synaptics s3203 as /devices/pci0000:00/INT33C3:00/i2c-8/i2c-DLL060A:00/0018:06CB:2734.0006/input/input23
[    4.864805] hid-rmi 0018:06CB:2734.0006: input,hidraw3: I2C HID v1.00 Pointer [DLL060A:00 06CB:2734] on i2c-DLL060A:00
Comment 22 Bernhard Schuster 2017-07-28 13:10:10 EDT
I can confirm that (Dell Chromebook 13)

$ sudo rmmod i2c_hid
$ sudo modprobe i2c_hid

temporarily resolves the issue. The nexte lid close/sleep triggers the issue again though.

dmesg:
[26268.059822] rmi4_f01 rmi4-01.fn01: WARNING: Non-zero sleep mode found. Clearing...
[26268.073725] rmi4_f01 rmi4-01.fn01: found RMI device, manufacturer: Synaptics, product: TM3141-001, fw id: 1985184
[26268.144116] input: Synaptics TM3141-001 as /devices/pci0000:00/INT3432:00/i2c-5/i2c-SYNA0000:00/0018:06CB:7AB3.0004/input/input16
[26268.145449] hid-rmi 0018:06CB:7AB3.0004: input,hidraw0: I2C HID v1.00 Mouse [SYNA0000:00 06CB:7AB3] on i2c-SYNA0000:00

The WARNING hints that the i2c-hid device never wakes up, but this might be a red hering.
Comment 23 Bernhard Schuster 2017-08-02 15:44:11 EDT
Anything one can do to get things moving?
Comment 24 Bernhard Schuster 2017-08-02 15:44:50 EDT
Any information missing one can provide in addition to the above?
Comment 25 Luis Villa 2017-08-06 21:59:39 EDT
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...)
Comment 26 Rodd Clarkson 2017-08-15 05:16:38 EDT
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.
Comment 27 Luis Villa 2017-08-19 13:03:44 EDT
Yeah, appears to be resolved for me. Close?
Comment 28 slartibart70 2017-08-24 10:21:43 EDT
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!
Comment 29 slartibart70 2017-08-28 04:33:56 EDT
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.
Comment 30 hamming.dolf 2017-09-07 17:07:55 EDT
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.
Comment 31 Peter Hutterer 2017-10-09 21:45:52 EDT
*** Bug 1490672 has been marked as a duplicate of this bug. ***
Comment 32 Davide Spinello 2017-10-24 15:03:23 EDT
I have a Dell xps 13 9333 developer edition, fresh install of Ubuntu 17.10. The touchpad does not work after suspend/resume.
Comment 33 Trey Tabner 2017-11-18 10:59:18 EST
(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?
Comment 34 Andrew Duggan 2017-11-18 16:25:00 EST
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?
Comment 35 Trey Tabner 2017-11-18 16:47 EST
Created attachment 1354941 [details]
Output from dmesg on T440p after suspend and resume
Comment 36 Davide Spinello 2017-11-21 20:54:17 EST
The problem is fixed on Dell XPS 13 9333 with Ubuntu 17.10 after kernel update to 4.13.0-17.
Comment 37 hamming.dolf 2017-12-12 12:34:15 EST
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.
Comment 38 bztdlinux 2018-01-08 22:23:13 EST
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.
Comment 39 Laura Abbott 2018-02-27 22:45:46 EST
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.
Comment 40 Trey Tabner 2018-02-27 23:37:57 EST
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.
Comment 41 Marek Novotny 2018-03-01 09:18:04 EST
Hi, I have similar experience with not working touchpad after resuming of the system on Fedora 27 (kernel 4.15.4-300.fc27.x86_64)
Comment 42 Marek Novotny 2018-03-01 09:23:49 EST
(In reply to Marek Novotny from comment #41)
> Hi, I have similar experience with not working touchpad after resuming of
> the system on Fedora 27 (kernel 4.15.4-300.fc27.x86_64)

The notebook is T460p
Comment 43 Marek Novotny 2018-03-02 02:48:12 EST
One additional experience is that on kernel 4.14.18-300.fc27.x86_64 touchpad works fine between suspend and resume repeatedly, so this issue affects only 4.15.x kernels for me.
Comment 44 bztdlinux 2018-03-02 03:08:38 EST
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)
Comment 45 Marek Novotny 2018-03-02 03:20:59 EST
(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.
Comment 46 Marek Marusic 2018-03-07 05:15 EST
Created attachment 1405223 [details]
Log of resume after suspend - T460p
Comment 47 Marek Marusic 2018-03-07 05:24:05 EST
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.
Comment 48 Gilles Dubreuil 2018-03-07 23:34:55 EST
Same issue with Fedora 27 on Lenovo T460p lately with 4.15.6-300.fc27.x86_64

After adding the kernel parameter suggested above, for instance:
$ grubby --update-kernel=DEFAULT --args=psmouse.synaptics_intertouch=0

Mouse pad works normally after resume.
Comment 49 Marek Novotny 2018-03-08 03:47:49 EST
(In reply to Gilles Dubreuil from comment #48)
> Same issue with Fedora 27 on Lenovo T460p lately with 4.15.6-300.fc27.x86_64
> 
> After adding the kernel parameter suggested above, for instance:
> $ grubby --update-kernel=DEFAULT --args=psmouse.synaptics_intertouch=0
> 
> Mouse pad works normally after resume.

That config doesn't work for me.

I have updated kernel to 4.15.6-300.fc27.x86_64, added psmouse.synaptics_intertouch=0 into all existing kernels in grub.

and after rebooting and suspending on the latest kernel and resuming, touchpad still doesn't work.

Here is the log from dmesg where psmouse fails
[   98.933192] psmouse: probe of serio3 failed with error -1

context of the above message:

  98.688700] rmi4_smbus 9-002c: failed to get SMBus version number!
[   98.688708] rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask.
[   98.688716] rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -16.
[   98.688719] rmi4_f01 rmi4-00.fn01: Resume failed with code -16.
[   98.688722] rmi4_physical rmi4-00: Failed to suspend functions: -16
[   98.688725] rmi4_smbus 9-002c: Failed to resume device: -16
[   98.688766] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-16).
[   98.688803] rmi4_physical rmi4-00: rmi_driver_clear_irq_bits: Failed to change enabled interrupts!
[   98.732713] usb 1-3.4: reset high-speed USB device number 8 using xhci_hcd
[   98.926085] usb 1-7:1.0: rebind failed: -517
[   98.926092] usb 1-7:1.1: rebind failed: -517
[   98.926505] PM: resume devices took 2.883 seconds
[   98.926850] OOM killer enabled.
[   98.926852] Restarting tasks ... 
[   98.933184] rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts!
[   98.933192] psmouse: probe of serio3 failed with error -1
[   98.933202] done.
[   98.934248] thermal thermal_zone3: failed to read out thermal zone (-61)
[   98.956221] bbswitch: disabling discrete graphics
[   99.028437] PM: suspend exit
Comment 50 Vladyslav Shtabovenko 2018-03-08 07:02:14 EST
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.
Comment 51 Gilles Dubreuil 2018-03-08 18:16:48 EST
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
Comment 52 Andrew Duggan 2018-03-08 20:04:47 EST
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
Comment 53 Andrew Duggan 2018-03-08 20:05:20 EST
Sorry, wrong link!

https://www.spinics.net/lists/linux-input/msg55311.html
Comment 54 Marek Novotny 2018-03-09 10:23:32 EST
(In reply to Gilles Dubreuil from comment #51)
> 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


I actually have the same HW as I can see

1.487962] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps: 0xf006a3/0x943300/0x12e800/0x10000, board id: 3053, fw id: 2010421
[    1.487974] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0

but without external USB mouse i would have only keyboard while booted 4.15.6-300.fc27.x86_64.
Comment 55 Marek Novotny 2018-03-09 10:41:02 EST
(In reply to Marek Novotny from comment #54)
> (In reply to Gilles Dubreuil from comment #51)
> > 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
> 
> 
> I actually have the same HW as I can see
> 
> 1.487962] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id:
> 0x1e2b1, caps: 0xf006a3/0x943300/0x12e800/0x10000, board id: 3053, fw id:
> 2010421
> [    1.487974] psmouse serio1: synaptics: serio: Synaptics pass-through port
> at isa0060/serio1/input0
> 
> but without external USB mouse i would have only keyboard while booted
> 4.15.6-300.fc27.x86_64.

Ok, I had to do something wrong in setting of kernel parameter, I checked again and now I can agree that the psmouse.synaptics_intertouch=0 is workaround even for me, sorry for false alarm on that.
Comment 56 Brendan Shephard 2018-03-12 07:15:38 EDT
This issue doesn't exist for me any more. It was resolved for me in Fedora 26 stable and hasn't been an issue since.
Comment 57 Marek Novotny 2018-03-12 11:32:45 EDT
What kernel should fix this issue without needing to have a workaround with psmouse.synaptics_intertouch=0 parameter?
Comment 58 Jaron Gao 2018-03-12 17:45:38 EDT
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"
Comment 59 Jaron Gao 2018-03-13 10:53:05 EDT
(In reply to Marek Novotny from comment #57)
> What kernel should fix this issue without needing to have a workaround with
> psmouse.synaptics_intertouch=0 parameter?

According to https://bugzilla.redhat.com/show_bug.cgi?id=1548867,
the fix (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5444a992b4a73aa5246a432c482b20b89bce93a5.) will be in the next stable, 4.15.10.
Comment 60 bztdlinux 2018-03-13 15:01:30 EDT
*** Bug 1508705 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.