Bug 842096 - Odd touchpad behavior after initial boot
Odd touchpad behavior after initial boot
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Depends On:
  Show dependency treegraph
Reported: 2012-07-21 22:33 EDT by Dan Doel
Modified: 2013-01-31 17:55 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-01-31 17:55:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dan Doel 2012-07-21 22:33:11 EDT
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-21 23:31:26 EDT
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 17:55:15 EST
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.

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