Description of problem: I recently installed the newest version of Fedora 20, which has a 3.15 kernel. Previously I had the last 3.14 version of Fedora 20. The behaviour of the touchpad on my Lenovo Yoga 2 Pro changed significantly, and for the worse, at this time when trying to do a two-finger click-drag. Previously I could click with one finger to initiate a drag and then use a second finger swipe (touch-drag) for the drag movement. Each second-finger swipe movement added to the drag distance no matter where the touch that started the swipe was. The drag finished when I released my first finger. However, now each second-finger touch resets the drag distance to the distance between the click point and the touch. This makes it impossible to move long distances in this fashion. The touchpad is a clickpad and does not have any external buttons. Version-Release number of selected component (if applicable): Linux idefix 3.15.4-200.fc20.x86_64 #1 SMP Mon Jul 7 14:24:41 How reproducible: always, also similar change for any click-drag (window move, text select, ...) Steps to Reproduce: 1. Click and hold in a window title using a finger click on the touchpad 2. Touch and drag and release with a second finger 3. Touch and drag and release with the second finger 4. Release the click Actual results: Total window move depends on distance between initial click and end of last drag Expected results: Total window move is sum of all the drag distances and not dependant at all on the drag locations Additional info: There are lots of moving parts here. First of all, I'm using XFCE, but given that window move and text select were both affected XFCE is not likely a contributor. dmesg | grep psmouse produces no output
Created attachment 919091 [details] evemu-record /dev/input/event4 under current Fedora 20 (3.15) I clicked on the touchpad. While maintaining the click I swiped (touch-drag-release) with a second finger four or so times.
Created attachment 919092 [details] evemu-record /dev/input/event4 under older Fedora 20 (3.14.7) Same finger actions as the other attachment. (Click-hold and four swipes)
Created attachment 919102 [details] synclient output
I guess that the kernel messages about the mouse had scrolled out of dmesg's range. Here is better information: idefix ~> dmesg | grep mouse [ 1.238433] mousedev: PS/2 mouse device common for all mice [ 1.892926] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd00123/0x840300/0x126c00, board id: 2132, fw id: 1180104 Going back to 3.14.7 changes the behaviour back to the expected one.
Hi, (In reply to Peter F. Patel-Schneider from comment #4) > I guess that the kernel messages about the mouse had scrolled out of dmesg's > range. Here is better information: > > idefix ~> dmesg | grep mouse > [ 1.238433] mousedev: PS/2 mouse device common for all mice > [ 1.892926] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: > 0x1e2b1, caps: 0xd00123/0x840300/0x126c00, board id: 2132, fw id: 1180104 > > Going back to 3.14.7 changes the behaviour back to the expected one. So your only booting the old resp. the new kernel to make the problem come and go, no other changes, right ? Can you do "cat /sys/bus/pnp/devices/00\:*/id" (under either kernel) and copy and paste the output here please ?
Yes, precisely. The only change was to boot into the older kernel. No other changes, not even modifying any kernel options. In 3.14.7-200 kernel idefix ~> cat /sys/bus/pnp/devices/00\:*/id PNP0200 INT0800 PNP0103 PNP0c02 PNP0b00 INT3f0d PNP0c02 PNP0303 SYN2b2c SYN2b00 SYN0002 PNP0f13 PNP0c02 PNP0c02
Hi, Are you sure you where running the wrong kernel when making the first evemu-record.log ? Both logs look fine and more or less identical. Then again I've been looking at the changelog of the kernel and there is nothing which would explain this there, so it does make some sort of sense that they are both fine ... Can you do "dmesg" with the new kernel after reproducing the problem and see if there is anything which stands out there ? Regards, Hans
So I booted back into 3.15.5-200 and the problem is gone. I'm attributing this to update gremlins. I did notice the problem immediately after upgrading so maybe there was some problem due to running software that was supposed to be for a different kernel. Anyway thanks for your help and sorry for taking up your time.
Could be some process was eating up a lot of cpu on the first boot after the update, see the mail to Peter I CC-ed you on. Anyways lets close this then.