(Alps?) DualPoint Stick disabled but visible after suspend Dell Latitude 7480

Bug #1694866 reported by Joe Harrington
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux-hwe (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Problem:

After resume from either suspend or hibernate, the DualPoint Stick (rubber knob between g, h, and b keys, and three-button row above trackpad) stops working (all components of it). The trackpad, two buttons below it, and touchscreen all continue to work. The behavior is 100% consistent.

Hardware:

Dell Latitude 7480 with DualPoint Stick, QHD touchscreen, Thunderbolt 3. This particular palmrest option is sold as "Dual Pointing, 82-key with Smartcard, Contactless Smartcard, Fingerprint Reader, Thunderbolt 3".

OS:

# lsb_release -rd
Description: Ubuntu 16.04.2 LTS
Release: 16.04

# uname -a
Linux glup 4.8.0-52-generic #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

# apt-cache policy linux-firmware
linux-firmware:
  Installed: 1.165
  Candidate: 1.165
  Version table:
 *** 1.165 100
        100 /var/lib/dpkg/status
     1.157.10 500
        500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages
     1.157.8 500
        500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu xenial-security/main i386 Packages
     1.157 500
        500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages

16.04 LTS with all updates. linux-firmware version 1.165 (same behavior with version included with 16.04 LTS and with version 1.161.1.). System is a fresh install with no other packages or user files. Problem does not appear in 17.04, but that version has kernel panics on this system (consistent with mkfs.ext4, plus random other times). Problem does appear in 16.10.

More:

xinput lists the device as "DualPoint Stick" with no manufacturer named. It is device 13. "xinput test 13" shows events before suspend for the stick and all 3 buttons. No events appear after resume, but the device is still listed in "xinput list":

# xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ELAN Touchscreen id=11 [slave pointer (2)]
⎜ ↳ DLL07A0:01 044E:120B id=12 [slave pointer (2)]
⎜ ↳ DualPoint Stick id=13 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Video Bus id=7 [slave keyboard (3)]
    ↳ Power Button id=8 [slave keyboard (3)]
    ↳ Sleep Button id=9 [slave keyboard (3)]
    ↳ Integrated_Webcam_HD id=10 [slave keyboard (3)]
    ↳ Intel HID events id=14 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=15 [slave keyboard (3)]
    ↳ Dell WMI hotkeys id=16 [slave keyboard (3)]

The device looks the same as what appears on many Dell models, and web pages describing other problems with the device (acceleration settings, etc.) often show "AlpsPS/2 DualPoint Stick" in xinput. I am not sure of the significance of this difference. The device identified as "DLL07A0:01 044E:120B" is the separate trackpad and its two buttons.

I have tried going to a virtual terminal and returning, and going to a virtual terminal and doing:

modprobe -r psmouse ; modprobe psmouse

Neither had any effect.

Thanks,

--jh--

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.8.0-52-generic 4.8.0-52.55~16.04.1
ProcVersionSignature: Ubuntu 4.8.0-52.55~16.04.1-generic 4.8.17
Uname: Linux 4.8.0-52-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.6
Architecture: amd64
Date: Wed May 31 20:29:31 2017
InstallationDate: Installed on 2017-05-21 (10 days ago)
InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2)
ProcEnviron:
 LANGUAGE=en_US
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: linux-hwe
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Joe Harrington (joeharr) wrote :
description: updated
Revision history for this message
Joe Harrington (joeharr) wrote :
Revision history for this message
Joe Harrington (joeharr) wrote :
Revision history for this message
Joe Harrington (joeharr) wrote :
Revision history for this message
Joe Harrington (joeharr) wrote :
Revision history for this message
Joe Harrington (joeharr) wrote :
Revision history for this message
Joe Harrington (joeharr) wrote :
Revision history for this message
Joe Harrington (joeharr) wrote :
Revision history for this message
Joe Harrington (joeharr) wrote :
Revision history for this message
Joe Harrington (joeharr) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux-hwe (Ubuntu):
status: New → Confirmed
Revision history for this message
Kathryn Morgan (katamo) wrote :

Would testing the 4.10 kernel based hardware enablement stack help this issue?

For example, install by:

sudo apt install linux-generic-hwe-16.04-edge

Revision history for this message
Joe Harrington (joeharr) wrote :

The good news is that this does enable the thing to work after resume from suspend.

The bad news is that this kernel panics upon mkfs.ext4. I just tested it again, installing as you suggested rather than using the 17.04 install I had tried before. The 16.04 and 16.10 kernels didn't crash. Both are 4.8 kernels; the new one is 4.10.

It's somewhat of a soft crash. The cursor disappears and the keyboard does nothing, but the X window system is still alive and if I tail -f syslog before running mkfs.ext4, I can see the call trace appear (but I can't capture it, and it doesn't get written to disk). A few more messages may appear later. After a few minutes, it goes black but does not reboot. The fan turns on immediately after the crash, at high revs.

Should I file a separate bug about the panic? I'm not sure it's technically a panic, as it doesn't say that word, as some other OSes have in the past. But, it's some kind of exceptional kernel event that brings the system down.

I'm very happy to run tests to work either problem.

--jh--

Revision history for this message
Joe Harrington (joeharr) wrote :
Revision history for this message
Kathryn Morgan (katamo) wrote :
To post a comment you must log in.