[Dell Latitude E6540] ALPS touchpad and buttons work only in a single window.

[Philippe Ombredanne]

This is a kernel that has these recent ALPS related patches:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1258837

So after a reboot the touchpad and button work fine, at start.

After a while the buttons, a single tap click, a double tap-click and the dual finger scrolling stop working on the correct front-most window and work instead on a background window.

If I Alt-tab to bring the window that receives the touchpad events to front, it receives it ok, so this one window gets mouse events. Using either the touchpad or the glidepoint is then limited to this window at this point.

Going to a terminal with ctrl-alt-f1 just a few seconds and then back to ctrl-alt-f7 restores things to normal for a while. Until its starts again. No dmesg nor syslog show up.

ApportVersion: 2.14.1-0ubuntu3.11
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: pombreda 1995 F.... pulseaudio
 /dev/snd/controlC0: pombreda 1995 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=UUID=801124f8-51bc-4bec-accf-ba187acdece1
InstallationDate: Installed on 2015-05-16 (77 days ago)
InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1)
MachineType: Dell Inc. Latitude E6540
NonfreeKernelModules: fglrx
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-45-generic root=UUID=df7edfbc-4df5-4603-a42b-c39f769bbb44 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.16.0-45.60~14.04.1-generic 3.16.7-ckt14
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-45-generic N/A
 linux-backports-modules-3.16.0-45-generic N/A
 linux-firmware 1.127.14
Tags: trusty
Uname: Linux 3.16.0-45-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin netdev plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 05/19/2015
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A15
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA15:bd05/19/2015:svnDellInc.:pnLatitudeE6540:pvr01:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr:
dmi.product.name: Latitude E6540
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

[penalvch (penalvch)]

Philippe Ombredanne, thank you for reporting this and helping make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 1480615

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

apport information

[Philippe Ombredanne (pombredanne)]

Christopher: I added the apport attachments.
It this enough? I am available for more details and tests. Tell me how I can help with the process, this bug is rather painful.

[penalvch (penalvch)]

Philippe Ombredanne, could you please test the latest upstream kernel available from the very top line at the top of the page (the release names are irrelevant for testing, and please do not test the daily folder) following https://wiki.ubuntu.com/Kernel/MainlineBuilds ? It will allow additional upstream developers to examine the issue.

If the test did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, Y, and Z are numbers corresponding to the kernel version.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Once testing of the latest upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

[Philippe Ombredanne (pombredanne)]

Something a tad weird happened. While preparing to test upstream kernels, I started by removing any proprietary AMD driver with:

    sudo apt-get remove --purge fglrx*

(this Dell E6540 laptop comes with a dual video card: built-in Intel and "discrete" AMD Radeon)

After that I did not experience the issue for several hours, so I thought that it could have been triggered by the AMD driver.

However, I did make one test: clean reboot, suspend by closing the lib, then resume by opening the lid.
After that I started experiencing the same issue again.

At least I am able to refine a bit how to reproduce:
- close the lid to suspend, open to resume
- whichever window was at the front at time of the suspend now "owns" the stick/touchapd events, even if it was not "owning" them before suspend
- Ctrl+Alt+F1 then Ctrl+Alt+F7 restores normal behaviour

Let me try to test these newer kernels now.

[Philippe Ombredanne (pombredanne)]

Just a quick status update:
- I have not yet tested upstream kernels yet, but this is high on my todo
- I shall say that since the latest upgrade of the kernel to 3.16.0-46 things have degraded quite a bit.
 -- I see fewer "DualPoint TouchPad at [...] - driver resynced." syslog messages (may be only 4 or 5 per day) as in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1258837
 -- but I see the buggy behaviour described here happen like 10 times per hour, which is hell.... that motivates me to get these upstream kernel tested asap

[Philippe Ombredanne (pombredanne)]

Testing now with http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19.8-vivid/
I cannot test things here: there is a new problem: it is like if the right button was being clicked at all times. Which makes the computer barely usable, not sure what to make of this. Moving on to try a newer kernel

[Philippe Ombredanne (pombredanne)]

Actually the bug is confirmed with kernel-bug-exists-upstream-3.19.8-031908

[Philippe Ombredanne (pombredanne)]

I am making this post from the very latest v4.2-rc7-unstable. The wild auto right click experienced with 3.19.8 is gone. But the bug we are tracking showed up too. Adding a tag

[Philippe Ombredanne (pombredanne)]

Christopher: all set ... Awaiting other instructions on how I can help get out of this mini hell :)

[Philippe Ombredanne (pombredanne)]

Something new: When the problem happens, I can also press Fn+F5 (which is the key combo to disable the touchpad on this laptop) twice to disable/enable the touchpad to make the problem go away, same effect as with Ctrl-Alt-F1/Ctrl-Alt-F7 or same effect as a modprobe -r psmouse and adding the psmouse driver again.

This is however a faster key combo ;)

[Philippe Ombredanne (pombredanne)]

Something new again:
pombreda@COMPUTER:~$ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ DualPoint Stick id=14 [slave pointer (2)]
⎜ ↳ AlpsPS/2 ALPS GlidePoint id=13 [slave pointer (2)]

As you can see, xinput reports this as a glidepoint now, instead of a ALPS DualPoint TouchPad previsouly seen in the kernel?
input: DualPoint Stick as /devices/platform/i8042/serio1/input/input20
input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input19

And a question: Could this be an xserver-xorg-input-synaptics bug instead or also?

[Philippe Ombredanne (pombredanne)]

NB: doing a modprobe -r psmouse && modprobe psmouse fixed the driver detection alright back to a DualPoint TouchPad. The bug still exists though.

[Philippe Ombredanne (pombredanne)]

So here is where I am now with the latest kernel update from a few days ago and everything up-to-date apt-get wise:

$ uname -a
Linux COMPUTER 3.16.0-48-generic #64~14.04.1-Ubuntu SMP Thu Aug 20 23:03:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

As mentioned above, when I reboot, xinput report an incorrect device and there are various issues with using the touchpad. I am doing a :

modprobe -r psmouse && modprobe psmouse

After that xinput reports AlpsPS/2 ALPS DualPoint TouchPad correctly and from that point on, things are working mostly fine. Now and then if the touchpad stops working correctly, things are resolved by pressing Fn+F5 twice (effectively disabling then enabling the touchpad).

If I ever go in suspend mode, I need to always press Fn+F5 twice to get a functional touchpad.

Please advise on the next setps I should take.

[Jonas Sundman (jonas-sundman)]

Vivid has the same problem. The device is however detected correctly at boot time.

# uname -a
Linux COMPUTER 3.19.0-31-generic #36-Ubuntu SMP Wed Oct 7 15:04:02 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[penalvch (penalvch)]

Jonas Sundman, it would help immensely if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

[penalvch (penalvch)]

Philippe Ombredanne, to clarify:
1) Does this only happen after resuming from suspend?
2) Does this frequency of this issue change by uninstalling the fglrx drivers?
3) Any change with the latest mainline kernel (4.3-rc7)?

[Jonas Sundman (jonas-sundman)]

Christopher M. Penalver, there is now a new report https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1510134.

I have added you as a subscriber.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Philippe Ombredanne (pombredanne)]

After the last few kernel updates, this bug no longer shows up now. The only case when I need to deactivate then reactivate the touchpad to get it back in shape is after I resume from a suspend and this is very supportable and minor.

[Philippe Ombredanne (pombredanne)]

Christopher M. Penalver (penalvch) wrote on 2015-10-25:
Philippe Ombredanne, to clarify:
1) Does this only happen after resuming from suspend?

==> since the last few kernel updates (say for about 1.5 month) only on suspend/resume

2) Does this frequency of this issue change by uninstalling the fglrx drivers?

==> I do not uses these. They were a source of endless problems.

3) Any change with the latest mainline kernel (4.3-rc7)?

==> stable for now with current and mainline vanilla.

[penalvch (penalvch)]

Philippe Ombredanne, this report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1480615/comments/39 regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.