Description of problem: The problem first appeared on my Fedora 21 install, after what I assume was an update that installed libinput. The touchpad would randomly get disabled, and there was no apparent way turn it back on. I decided to update to Fedora 22 in the hopes of obtaining a fix, but the issues persisted. The touchpad no longer turned itself off, but at times it simply leaps from one part of the screen to the other, click along the way and wrecking havoc on my screen - closing windows, pasting clipboard contents (middle click). Version-Release number of selected component (if applicable): I'm currently running kernel 4.2.3-200 on Fedora 22 x86_64, with xorg-x11-drv-libinput version 0.14.0, release 1.fc22. How reproducible: My machine is a Thinkpad Edge E531.
if you think it's libinput, the easy test is to dnf remove xorg-x11-drv-libinput, then restart X. as long as xorg-x11-drv-evdev and -synaptics are installed, the server will automatically pick those and you don't break anything. When you do that, do the problems go away? Either way, I'll need the evemu-record output from one of these sequences. It'll show whether the jumps are at the hw/kernel level or in userspace.
Created attachment 1088414 [details] evemu-record for libinput
Created attachment 1088415 [details] evemu-record for synaptics
(In reply to Peter Hutterer from comment #1) > if you think it's libinput, the easy test is to dnf remove > xorg-x11-drv-libinput, then restart X. as long as xorg-x11-drv-evdev and > -synaptics are installed, the server will automatically pick those and you > don't break anything. When you do that, do the problems go away? > > Either way, I'll need the evemu-record output from one of these sequences. > It'll show whether the jumps are at the hw/kernel level or in userspace. I attached the logs for both scenarios; the one where the synaptics driver is enabled and the other one, with libinput enabled. I also tested the touchpad itself in Windows, to make sure it wasn't actually defective hardware causing the problem. I had to reinstall Windows on my machine (Fedora was the only OS installed on my laptop), but I confirmed that the touchpad works perfectly with Windows 10 and 8.1.
fwiw, the evemu recording for both drivers is the same, evemu sits below either. Follow up to comment 1, does the touchpad work fine with the synaptics driver or do you see the same issues?
Both drivers have the same issues, although problems seem to arise more frequently with the Synaptics driver. On the Synaptics one I can right-click using two fingers (during the rare intervals of time in which my cursor isn't possessed), but on libinput I can scroll horizontally, in addition to vertical scrolling which Synaptics also had. Both text files contain the evemu logs, I just cut the Synaptics one because it took a while until I could reproduce the issues I mentioned.
weird. There are two issues here: the evemu-record form attachment 1088414 [details] only shows BTN_TOOL_FINGER, no other events. Usually we should get x/y coordinates with the finger tool, unless you exactly put the finger down in the same location every time, which is unlikely. So I'll need you do re-do this recording please, ideally with some pointer movement included. the recording from attachment 1088415 [details] (the synaptics one) is missing the top description, so it's a bit hard to guess what this shows. plus, it's showing REL_X/Y, which the device can't send. are you sure you recorded the right device here, this looks like a normal mouse.
Created attachment 1088744 [details] evemu-record for libinput - 2
Created attachment 1088745 [details] evemu-record for synaptics - 2
Created attachment 1088746 [details] evemu-record for synaptics - 3
I added logs with the headers you requested, as well as a third log for the synaptics driver, when the touchpad stopped moving whatsoever, even though the events apparently kept being recorded in the log.
sorry, these logs are too long. The first one contains 5 minutes of recordings with just under 18000 events, it's a bit hard to find the event that upsets either driver in that sequence. I need you to restart evemu frequently if you can't reproduce it, so that the actual recording is as short as possible. Otherwise there's little hope of reproducing and debugging this