Hide Forgot
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.
Dell XPS 13 9350. Not 6350 sorry. System Information Manufacturer: Dell Inc. Product Name: XPS 13 9350
No change in loaded Kernel modules before and after resume. e
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.
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.
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.
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.
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
Ok, looks like my issue is: #1429236
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 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?
Or here's another thought. Both my touchpad and my touchscreen are synaptics devices. Could they be conflicting on resume?
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.
*** Bug 1471032 has been marked as a duplicate of this bug. ***
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.
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?
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)
Is there a way I can disable my touch screen to test if the synaptics touch screen is conflicting with the synaptics touchpad?
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.
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.
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
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.
Anything one can do to get things moving?
Any information missing one can provide in addition to the above?
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.
Yeah, appears to be resolved for me. Close?
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.
*** Bug 1490672 has been marked as a duplicate of this bug. ***
I have a Dell xps 13 9333 developer edition, fresh install of Ubuntu 17.10. The touchpad does not work after suspend/resume.
(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?
Created attachment 1354941 [details] Output from dmesg on T440p after suspend and resume
The problem is fixed on Dell XPS 13 9333 with Ubuntu 17.10 after kernel update to 4.13.0-17.
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.
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)
(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
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.
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.
Created attachment 1405223 [details] Log of resume after suspend - 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.
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.
(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
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
Sorry, wrong link! https://www.spinics.net/lists/linux-input/msg55311.html
(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.
(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.
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.
What kernel should fix this issue without needing to have a workaround with psmouse.synaptics_intertouch=0 parameter?
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"
(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.
*** Bug 1508705 has been marked as a duplicate of this bug. ***