Bug 842096

Summary:	Odd touchpad behavior after initial boot
Product:	[Fedora] Fedora	Reporter:	Dan Doel <dan.doel>
Component:	xorg-x11	Assignee:	Peter Hutterer <peter.hutterer>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	17	CC:	peter.hutterer
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-31 22:55:15 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dan Doel 2012-07-22 02:33:11 UTC

Since upgrading to Fedora 17, I've noticed some odd behavior with the touchpad clicking (and possibly other behavior) in the first X session after booting up.

For instance, normally, if one slowly drags the mouse pointer across the top panel of a window, and clicks one of the touchpad buttons during the process, the window will be grabbed and start moving with the cursor. However, during the first X session after booting (only!) the grab will be delayed indefinitely until the movement stops. This leads, for instance, to attempted click-and-drags to result in grabbing/dragging/clicking the wrong part of the screen.

When this is happening, I've also observed decreased scrolling functionality of the touchpad. For instance, one can two-finger swipe to scroll a long distance with a sort of inertia normally. However, when the touchpad is in this state, there is no inertia, and resolution seems decreased.

I should also note that this only affects the touchpad and its associated buttons. My machine is a Lenovo T420, so it has three buttons above the touchpad for use with the trackpoint, and they _do not_ show the same delayed dragging behavior.

Logging out and logging back in seems to eliminate the problems until the next fresh boot, perhaps because X is restarted as part of the process.

I have also installed fluxbox, and used it as my first X session, and saw the same behavior, so this does not appear to be a gnome-related problem.

I realize this isn't much concrete information to go on, but unfortunately it is all I have at the moment.

In my search for information about this problem, I read about the gnome drag and drop threshold setting, and thought it was related, but it appears not to be. This happens on initial boot regardless of what said slider is set to, and the behavior shouldn't be inconsistent between the touchpad and non-touchpad buttons, presumably. Also the scrolling shouldn't be related.

Version-Release number of selected component (if applicable):

As mentioned, I'm running Fedora 17 on a Lenovo T420, with an Intel i5 sandy bridge CPU and HD3000 graphics.

How reproducible:

This happens consistently.

Steps to Reproduce:
1. (Re)boot
2. Log in for the fist time
3. Observe strange touchpad behavior
4. Log out, log in
5. Observe normal touchpad behavior

Expected results:
Touchpad should behave normally every time.

Comment 1 Dan Doel 2012-10-22 03:31:26 UTC

Here's an update that may or may not be helpful.

I'd been having trouble with gnome's online accounts upon first logging in for a while. I finally tracked down a report of someone having the same problem and fixing it. It turned out that Google's login servers were rejecting timestamps from the future, and the person had their system time settings messed up.

I checked mine, and they were off as well (wrong timezone, and bad system time). I fixed these, and online accounts works as expected, but the touchpad issues seem resolved as well. So it's possible that network time resetting the time in a two or so hour jump upon first logging in was triggering some oddity in the touchpad software. Such a jump would only occur once each boot, so that explains why bouncing X after it happens would rectify the problem until the next reboot.

This probably doesn't help narrow down the underlying cause, but perhaps it's something.

Comment 2 Peter Hutterer 2013-01-31 22:55:15 UTC

we've had an issue upstream with timestamps going wrong but that should not be an issue anymore with what's in F17. http://bugs.freedesktop.org/show_bug.cgi?id=48777
there was another issue with syndaemon, but that's unrelated to what you see here.

that would certainly also explain why you never saw it in the second X session.

I'm closing this as WORKSFORME for now, if you can reproduce this in an up-to-date f17 let me know and I'll check if the bug is still there.