Bug 91875

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.