Bug 1121143 - change in behaviour of touchpad (phantom)
Summary: change in behaviour of touchpad (phantom)
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-18 13:23 UTC by Peter F. Patel-Schneider
Modified: 2014-07-19 13:56 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-19 13:54:48 UTC


Attachments (Terms of Use)
evemu-record /dev/input/event4 under current Fedora 20 (3.15) (133.75 KB, text/plain)
2014-07-18 13:41 UTC, Peter F. Patel-Schneider
no flags Details
evemu-record /dev/input/event4 under older Fedora 20 (3.14.7) (91.94 KB, text/x-log)
2014-07-18 13:42 UTC, Peter F. Patel-Schneider
no flags Details
synclient output (2.20 KB, text/x-c)
2014-07-18 14:03 UTC, Peter F. Patel-Schneider
no flags Details

Description Peter F. Patel-Schneider 2014-07-18 13:23:07 UTC
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

Comment 1 Peter F. Patel-Schneider 2014-07-18 13:41:10 UTC
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.

Comment 2 Peter F. Patel-Schneider 2014-07-18 13:42:44 UTC
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)

Comment 3 Peter F. Patel-Schneider 2014-07-18 14:03:57 UTC
Created attachment 919102 [details]
synclient output

Comment 4 Peter F. Patel-Schneider 2014-07-18 14:04:48 UTC
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.

Comment 5 Hans de Goede 2014-07-18 14:19:53 UTC
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 ?

Comment 6 Peter F. Patel-Schneider 2014-07-18 14:54:06 UTC
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

Comment 7 Hans de Goede 2014-07-19 13:42:18 UTC
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

Comment 8 Peter F. Patel-Schneider 2014-07-19 13:52:54 UTC
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.

Comment 9 Hans de Goede 2014-07-19 13:54:48 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.