Bug 1074910 - Touchpad disappears on resume on Dell XPS 13
Summary: Touchpad disappears on resume on Dell XPS 13
Keywords:
Status: CLOSED DUPLICATE of bug 1048314
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: Unspecified
OS: Unspecified
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-03-11 08:50 UTC by Luke Benstead
Modified: 2014-03-16 13:24 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-16 13:24:00 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Luke Benstead 2014-03-11 08:50:02 UTC
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):

3.13.6-200.fc20.x86_64

How reproducible:

Always.

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 Basto 2014-03-12 04:00:16 UTC
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 ? .

Thanks.

Comment 2 Mark Davidson 2014-03-12 08:36:11 UTC
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 23:02:15 UTC
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-14 00:55:26 UTC
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-16 00:24:21 UTC
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 13:24:00 UTC
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.