Created attachment 118077 [details] evemu file I am mostly using a mouse but the very rare times I try to use my touchpad, it is driving me crazy: basically, I think after trying to scroll with two fingers, the touchpad often get stuck in scrolling mode, it is impossible to move the cursor, unless I keep holding the touchpad and move my finger at the same time, or sometimes it also work again after I ALT-TAB. I'm not sure if this is only related to scrolling, sometimes the cursor just get stuck, I'm trying everything to get it unstuck and nothing seem to work, although after holding the touchpad button multiple times, alt tabbing and doing all sort of things it usually end up working again. Disabling the touchpad with the Fn key and reenabling it also seem to fix the issue. I'm on Arch Linux, with the Plasma 5 DE. libinput 1.0 and xf86-input-libinput 0.14. I can't remember a time where I didn't have this issue, I think I've always had it (although I rarely use my touchpad). My laptop is a Acer Aspire V3-772GTX. I have recorded the touchpad with evemu while reproducing the issue, and it also reproduces when using evemu-play. cat /sys/class/dmi/id/modalias dmi:bvnInsydeCorp.:bvrV1.15:bd03/07/2014:svnAcer:pnAspireV3-772G:pvrV1.15:rvnAcer:rnVA70_HW:rvrType2-BoardVersion:cvnChassisManufacturer:ct10:cvrChassisVersion: libinput settings: Device 'SynPS/2 Synaptics TouchPad': Device Enabled (138): 0 Coordinate Transformation Matrix (140): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (275): 0 libinput Tapping Enabled Default (276): 0 libinput Tapping Drag Lock Enabled (277): 0 libinput Tapping Drag Lock Enabled Default (278): 0 libinput Accel Speed (279): 0.000000 libinput Accel Speed Default (280): 0.000000 libinput Natural Scrolling Enabled (281): 0 libinput Natural Scrolling Enabled Default (282): 0 libinput Send Events Modes Available (259): 1, 1 libinput Send Events Mode Enabled (260): 0, 0 libinput Send Events Mode Enabled Default (261): 0, 0 libinput Left Handed Enabled (283): 0 libinput Left Handed Enabled Default (284): 0 libinput Scroll Methods Available (285): 1, 1, 0 libinput Scroll Method Enabled (286): 1, 0, 0 libinput Scroll Method Enabled Default (287): 1, 0, 0 libinput Click Methods Available (288): 1, 1 libinput Click Method Enabled (289): 1, 0 libinput Click Method Enabled Default (290): 1, 0 libinput Disable While Typing Enabled (291): 1 libinput Disable While Typing Enabled Default (292): 1 Device Node (262): "/dev/input/event14" Device Product ID (263): 2, 7 libinput Drag Lock Buttons (293): <no items> libinput Horizonal Scroll Enabled (264): 1
sorry, I think this recording is incomplete. to replay this here (and reproduce the issue) you'll need to start from a neutral state, i.e without any finger on the touchpad, and finish in a neutral state. This one looks like when you started the recording one finger was already down. although, if you didn't have any finger down when you started the recording the issue would be obvious and it's not in libinput. Looks like the touchpad never releases one finger. Not sure yet whether that's a kernel or hw issue.
I really doubt I had any finger down when starting the record, so this might be a kernel issue as you said. Which event are you looking at exactly which say that a finger would be down? If that's indeed a kernel issue, any ideas how I could debug it?
The first finger down sets BTN_TOOL_FINGER and BTN_TOUCH, the second finger sets BTN_TOOL_DOUBLETAP and unsets FINGER, then it keeps going with TRIPLETAP/QUADTAP. your recording starts with axis events immediately, without BTN_TOUCH set first. that suggests that the kernel or the device think a finger is still down. https://github.com/Lyude/ps2emu you can try ps2emu, that should narrow down whether it truly is a HW issue
Testing again I do see BTN_TOUCH, although I haven't been able to reproduce the issue so far. Sometimes it reproduces easily, sometimes it's harder. I'll try some more times and I'll upload another evemu file.
Now it's actually even worse, I can't use my touchpad at all. Apparently the click seem to work, but I can't move the cursor around. This used to happen from time to time and I had to reboot my computer, but I can't get it to work at all now. Using evemu-record I see a lot of ABS_MT_PRESSURE and ABS_PRESSURE events, even when I'm not touching the touchpad.
Actually it's pretty random, now it works again, but it's stuck in scrolling mode, so I have to press at least 2 fingers to make it move. Should I just do a ps2emu-record and upload it here?
(In reply to AnAkkk from comment #6) > Should I just do a ps2emu-record and upload it here? Yes, please do. Ideally, upload the logs while triggering the bug (from working state to non-working state). It might not be easy but that should help a lot. Having the logs while the system is stuck is also interesting because that will help knowing if the firmware or the kernel is stuck in a bad state.
Created attachment 118903 [details] ps2emu record I've been trying to reproduce it while ps2emu was recording, and my touchpad was working perfectly all the time. Then I've stopped ps2emu, and for some reason few minutes later the cursor started jumping and behaving weirdly, sometimes being in scroll mode apparently. I tried to start ps2emu again after that, and had the issue, although I'm not sure if the bug was present or not when I started it since it's very random. I've attached the file.
urgh, sorry about the delay. Is this still an issue, have you tried a newer kernel since? Benjamin, can you look at the ps2emu recording?
Yep, sorry for the delay :( I just had a look at the ps2emu recoring, and I must say, I am not very confident in being able to solve this: Right after the touchpad has been reset by PS/2 and before you even start using it, there are 2 touches that are continuously sent at positions (1997,3253) and (1700,2904) (more or less). When you start using the touchpad, we see your fingers but those ghost positions are still there and are interfering with the proper parsing of the events. My guess is that the firmware of the touchpad gets lost at some point and you need to effectively cut power (fn key combination) to restart it properly. Not sure we can do much further analysis/fixing at our level :(
(In reply to Peter Hutterer from comment #9) > urgh, sorry about the delay. Is this still an issue, have you tried a newer > kernel since? Benjamin, can you look at the ps2emu recording? Yes, I just reproduced the issue again on a 4.3.3 kernel. After plugging in a mouse (which disables my touchpad), and plugging it out, it also fixes the issue.
Hi, I am experiencing the same issue on Kernel 4.6.1 with Arch Linux, X Server and Gnome. It is still a problem to the point that I have to re-init the touchpad in order to make it work again.
I guess it'd be interesting to try the RMI4 patches to see if that is an issue with those too. Benjamin, do you have a kernel tree available to test this? I think this one was the most recent one I tested: https://github.com/bentiss/linux/tree/synaptics-rmi4-smbus-v4.7-rc4%2B
I just pushed the branch synaptics-rmi4-smbus-v4.7+ on my github tree (https://github.com/bentiss/linux). Once installed, add the kernel parameter psmouse.synaptics_intertouch=1 to force binding RMI4 over SMBus.
any updates? did anyone test benjamin's kernel?
I don't use the touchpad that often...I will try to test this next week. Is there a plan to submit these patches upstream, or has it already been done?
the patches will go upstream, but they are not in Linus' tree yet. they'll go upstream anyway because of the myriad of other issues the patches fix but it'd be nice to know whether this bug is fixed or whether we still have to work out how to fix it once RMI4 is in place
Ok, I'm closing this bug because there's nothing here to do other than waiting until the kernel has support for RMI4 - still hoping for 4.10 here. Once you have a 4.10 kernel and it still is an issue, please re-open but otherwise I consider this done from the libinput side.
(In reply to Peter Hutterer from comment #18) > Ok, I'm closing this bug because there's nothing here to do other than > waiting until the kernel has support for RMI4 - still hoping for 4.10 here. > Once you have a 4.10 kernel and it still is an issue, please re-open but > otherwise I consider this done from the libinput side. I doubt v4.10 will contain the fixes. We are getting closer, but given that the merge window opens next week or the week after, I doubt Dmitry will take the changes without a full cycle of tests. So hopefully they will be in v4.11.
So it looks like the commits are in Linus’ tree now? ``` $ git log […] commit 27a67e0f983567574ef659520d930f82cf65125a Merge: 59da2a0 53f724b Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon Feb 20 17:16:43 2017 -0800 […] - hid-rmi is now generic transport driver, used by synaptics-rmi4; Support the Lenovo Thinkpad X1 Tablet dock follows on top, from Andrew Duggan […] $ git tag --contains 27a67e0f983567574ef659520d930f82cf65125a v4.11-rc1 ``` With a Linux kernel built from commit 86292b33d4 (Merge branch 'akpm' (patches from Andrew)), on a Dell XPS 13 9360 I get the Linux messages below, and the touchpad still gets stuck in scroll mode from time to time. ``` $ journalctl -k | grep -i syna Mar 07 11:43:28 xps13 kernel: psmouse serio1: synaptics: queried max coordinates: x [..5666], y [..4734] Mar 07 11:43:28 xps13 kernel: psmouse serio1: synaptics: queried min coordinates: x [1276..], y [1118..] Mar 07 11:43:28 xps13 kernel: psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2a1, caps: 0xf00323/0x840300/0x12e800/0x0, board id: 3038, fw id: 2375007 Mar 07 11:43:28 xps13 kernel: input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input2 Mar 07 11:43:29 xps13 kernel: rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM3038-003, fw id: 2375007 Mar 07 11:43:29 xps13 kernel: input: Synaptics TM3038-003 as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-DLL075B:01/0018:06CB:76AF.0002/input/input23 ``` AnAkkk, what about you? So this is a Linux kernel issue, right?
Unfortunately I don't currently have time to build a kernel to check if it's fixed. I will try to do that when I have some spare time.
Well, unfortunately, the last 3 commits missed the merge window and might come in v4.12. The commit you are referring to is one for devices using hid-rmi, while here we need a binding from PS/2 to rmi_smbus.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.