Bug 1074910 - Touchpad disappears on resume on Dell XPS 13
Touchpad disappears on resume on Dell XPS 13
Status: CLOSED DUPLICATE of bug 1048314
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2014-03-11 04:50 EDT by Luke Benstead
Modified: 2014-03-16 09:24 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-16 09:24:00 EDT
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 Luke Benstead 2014-03-11 04:50:02 EDT
Description of problem:

When resuming from suspend, the touchpad panel disappears from GNOME settings and synclient cannot find the device. The touchpad continues to function as a mouse (although, I'm also experiencing it functioning as a mouse, without scrolling, before suspend, but this bug is to cover the disappearance of the device completely).

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


How reproducible:


Steps to Reproduce:
1. Boot laptop into F20
2. Visit GNOME Touchpad settings, note that the settings are there (but don't work)
3. Suspend laptop by closing the lid
4. Reopen the lid, go back to the touchpad settings, the touchpad panel doesn't exist. synclient insists there is no device

Actual results:

Touchpad disappears

Expected results:

It doesn't.

Additional info:

This is the same laptop and installation as the one I reported #1062363 but with a recent update the problem has changed. 

In that bug the touchpad would be stuck in scrollmode, that's no longer the case but now the touchpad is invisible after resume. 

However after recent updates both before and after suspend I have no edge scrolling, or two finger scrolling, cursor acceleration is slow and tap-to-click is always on. And yet synclient still reports the following before suspend:

[lukeb@localhost ~]$ synclient -l | grep -i scroll
    VertScrollDelta         = 107
    HorizScrollDelta        = 107
    VertEdgeScroll          = 0
    HorizEdgeScroll         = 0
    VertTwoFingerScroll     = 1
    HorizTwoFingerScroll    = 1
    CircularScrolling       = 0
    CircScrollDelta         = 0.1
    CircScrollTrigger       = 0
[lukeb@localhost ~]$ synclient -l | grep -i tap
    MaxTapTime              = 180
    MaxTapMove              = 235
    MaxDoubleTapTime        = 180
    SingleTapTimeout        = 180
    TapButton1              = 1
    TapButton2              = 3
    TapButton3              = 2
    TapAndDragGesture       = 1

It's as if the touchpad is ignoring the synaptics settings. Perhaps it isn't even using the driver?
Comment 1 Sergio Monteiro Basto 2014-03-12 00:00:16 EDT
Hi, with what kernel this doesn't happen , you mention in ask.fedora "until a couple of weeks ago everything was working fine", so can you find the last kernel that touchpad works after resume ? .

Comment 2 Mark Davidson 2014-03-12 04:36:11 EDT
I am also having the same problem with kernel 3.13.6-200.fc20

I installed Fedora 20 (also on a Dell XPS 13) and the touchpad scrolling and suspend worked with kernel 3.11.10-301.fc20.

After update the touchpad seems to ignore the touchpad settings (no 2 finger scrolling, seems to use mouse pointer accel rather than touchpad accel, after suspend synclient finds no touchpad)

I switched back to kernel 3.11.10-301 and it all started working again.
Comment 3 Luke Benstead 2014-03-12 19:02:15 EDT
I can confirm that rolling back to a 3.11 kernel works fine. 3.12 and 3.13 have the issue.
Comment 4 Mark Davidson 2014-03-13 20:55:26 EDT
Just to tie it down a bit more.
kernel 3.11.10-301 works
kernel 3.12.5-302 touchpad has above problems

Could it be something to do with the alps-Support-for-Dell-XT2-model.patch that was introduced in that version?
Comment 5 Mark Davidson 2014-03-15 20:24:21 EDT
Bug 1048314 has a workaround that seems to work - blacklisting the i2c-hid module.

See https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2
Comment 6 Benjamin Tissoires 2014-03-16 09:24:00 EDT
This is definitively a duplicate of bug 1048314.

The same temporary workaround will work.

*** This bug has been marked as a duplicate of bug 1048314 ***

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