[Dell Latitude E7440] ALPS touchpad keeps having state reset

[Allan Crooks]

The mouse cursor keeps on jumping around, and these messages appear in the log when it happens:
Dec 7 21:57:26 wyvern kernel: [ 648.133841] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 7 21:57:26 wyvern kernel: [ 648.134868] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 7 21:57:26 wyvern kernel: [ 648.137921] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
Dec 7 21:57:26 wyvern kernel: [ 648.138852] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 7 21:57:26 wyvern kernel: [ 648.148833] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.

The touchpad is recognised as a "AlpsPS/2 ALPS DualPoint TouchPad". This is occurring with Ubuntu 13.10, though I have also seen this behaviour in the version of Linux Mint based on Ubuntu 13.04.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-14-generic 3.11.0-14.21
ProcVersionSignature: Ubuntu 3.11.0-14.21-generic 3.11.7
Uname: Linux 3.11.0-14-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: allanc 1852 F.... pulseaudio
 /dev/snd/controlC0: allanc 1852 F.... pulseaudio
Date: Sat Dec 7 22:19:22 2013
HibernationDevice: RESUME=UUID=a2a36712-35de-4e20-9d1a-df3520f401ec
InstallationDate: Installed on 2013-12-07 (0 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MachineType: Dell Inc. Latitude E7440
MarkForUpload: True
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-14-generic.efi.signed root=UUID=d03a42e6-0dea-4969-a682-eb4d255abc70 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-14-generic N/A
 linux-backports-modules-3.11.0-14-generic N/A
 linux-firmware 1.116
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/14/2013
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A03
dmi.board.name: 07F3F4
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA03:bd08/14/2013:svnDellInc.:pnLatitudeE7440:pvr01:rvnDellInc.:rn07F3F4:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.name: Latitude E7440
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.13 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc3-trusty/

[Allan Crooks (amcone)]

Tested with the newer kernel - running "uname -a" gives me:
Linux wyvern 3.13.0-031300rc3-generic #201312061335 SMP Fri Dec 6 18:37:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

And in the logs:
Dec 10 01:01:59 wyvern kernel: [ 814.172751] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 10 01:01:59 wyvern kernel: [ 814.173731] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 10 01:01:59 wyvern kernel: [ 814.174728] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 10 01:01:59 wyvern kernel: [ 814.177790] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
Dec 10 01:14:28 wyvern kernel: [ 1562.691448] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
Dec 10 01:14:28 wyvern kernel: [ 1562.702058] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.

I didn't get much of the "jumping around" behaviour - in fact, I didn't realise that anything was wrong in that sense until I looked in the logs. Also, a later message talked about losing sync "at byte 6" (rather than "at byte 1", which is the usual message).

It's difficult to recreate the bug on demand, so I normally just have to use the system normally for a while until something happens.

[Jeffrey Knockel (jeff250)]

This sync issue with the E7440 touchpad can cause spurious clicks too.

One thing that I found helps is to add psmouse.resetafter=1 to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub (and then run update-grub and reboot).

This will cause the driver to reset when it loses sync, causing the touchpad to stop working for a few moments, but typically avoiding spurious movement and clicking. This will also cause your dmesg logs to look like this instead:

[ 2571.411451] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 2571.411456] psmouse serio1: issuing reconnect request
[ 6112.042246] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 6112.042260] psmouse serio1: issuing reconnect request
. . .

[Allan Crooks (amcone)]

Updated the BIOS as you suggested. From the terminal:

allanc@wyvern:~$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
A06
12/05/2013
allanc@wyvern:~$ uname -a
Linux wyvern 3.13.0-031300rc3-generic #201312061335 SMP Fri Dec 6 18:37:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

And looking at the logs after a while:
Dec 18 12:24:23 wyvern kernel: [ 7576.635161] psmouse serio1: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
Dec 18 12:24:23 wyvern kernel: [ 7576.635165] psmouse serio1: issuing reconnect request
Dec 18 12:32:14 wyvern kernel: [ 8048.029215] psmouse serio1: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
Dec 18 12:32:14 wyvern kernel: [ 8048.029218] psmouse serio1: issuing reconnect request
Dec 18 12:42:03 wyvern kernel: [ 8636.722053] psmouse serio1: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
Dec 18 12:42:03 wyvern kernel: [ 8636.722056] psmouse serio1: issuing reconnect request

I'm using the latest kernel (as suggested in comment 3) and the resetafter parameter (as suggested in comment 5). I find it difficult to recreate on demand. I managed to see those errors within half an hour of resuming the laptop from suspend. I didn't see any such messages in the log while I was testing prior to putting it on standby, and I haven't seen any messages a while after resuming. I'll test with it more.

[penalvch (penalvch)]

Allan Crooks, what would be most helpful is to not introduce suspend into the mix, as this is typically treated as a separate issue, necessitating a new bug report. Targeting a default setup, if you remove the kernel parameter psmouse.resetafter=1, and test both the mainline kernel v3.13-rc3 and the latest from Saucy (3.11.0-14.21), is this issue reproducible after this BIOS update (not after suspending)?

[Allan Crooks (amcone)]

I've disabled suspend on the laptop and continued to use the laptop so that even the screensaver doesn't kick in. I've also removed resetafter kernel parameter.

I booted the laptop with both kernels, ran "tail -f /var/log/kern.log" in a terminal and left it running until I saw error messages (and when I did, I ran "uname -a" to ensure I was running with the right kernel):

Running with Saucy's kernel:
Dec 18 23:46:52 wyvern kernel: [ 12.393384] wlan0: associated
Dec 18 23:46:52 wyvern kernel: [ 12.393405] IPv6: ADDRCONF(NETDEV_CHANGE)r wlan0: link becomes ready
Dec 18 23:51:35 wyvern kernel: [ 295.053094] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 18 23:51:35 wyvern kernel: [ 295.054161] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 18 23:51:35 wyvern kernel: [ 295.055173] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 18 23:51:35 wyvern kernel: [ 295.058165] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
^C
allanc@wyvern:~$ uname -a
Linux wyvern 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

And running with the mainline kernel:
Dec 18 22:45:38 wyvern kernel: [ 568.646133] wlan0: associated
Dec 18 23:37:13 wyvern kernel: [ 3662.160891] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 18 23:37:13 wyvern kernel: [ 3662.161842] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 18 23:37:13 wyvern kernel: [ 3662.162845] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 18 23:37:13 wyvern kernel: [ 3662.165944] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
^C
allanc@wyvern:~$ uname -a
Linux wyvern 3.13.0-031300rc3-generic #201312061335 SMP Fri Dec 6 18:37:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[Allan Crooks (amcone)]

It's a fairly new machine, so the only other Linux OS it has had on it is Linux Mint 15, which is based on 13.04. The problem seems to be more frequent there.

[Allan Crooks (amcone)]

Tested it in the same way on Precise as described in comment 9, same results.. Again - tailing kern.log:
Dec 20 23:50:17 wyvern kernel: [ 108.890147] EXT4-fs (sda5): recovery complete
Dec 20 23:50:17 wyvern kernel: [ 108.892446] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
Dec 20 23:50:28 wyvern kernel: [ 119.538013] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
Dec 20 23:50:29 wyvern kernel: [ 120.258157] EXT4-fs (sda8): mounted filesystem with ordered data mode. Opts: (null)
Dec 21 00:00:29 wyvern kernel: [ 720.188040] psmouse serio1: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
Dec 21 00:00:29 wyvern kernel: [ 720.189023] psmouse serio1: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
Dec 21 00:00:29 wyvern kernel: [ 720.190027] psmouse serio1: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
Dec 21 00:00:29 wyvern kernel: [ 720.193062] psmouse serio1: GlidePoint at isa0060/serio1/input0 - driver resynced.
^C
allanc@wyvern:~$ uname -a
Linux wyvern 3.8.0-34-generic #49~precise1-Ubuntu SMP Wed Nov 13 18:05:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[Allan Crooks (amcone)]

I tried using the kernel version that came with the released version of 12.04 (on an original install base of 12.04.3), but that seemed to cause stability problems.

So instead, I installed the original version of 12.04, and that seemed to work without reporting any problems.

I then installed 12.04.2 without applying any updates, and that also seemed to work. So using the 3.5.x releases (I forget which version 12.04.2 uses by default), I started bisecting to try and find out which version seemed to introduce the problem.

I was able to find various releases where the bug didn't seem to exhibit itself after continued use:
 - 3.5.0-23
 - 3.5.0-27
 - 3.5.0-31

And various versions where it did:
 - 3.5.0-32
 - 3.5.0-34
 - 3.5.0-44

Tailing kern.log using the 3.5.0-32 kernel:

Dec 21 23:47:00 wyvern kernel: [ 8.931123] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input10
Dec 21 23:47:00 wyvern kernel: [ 8.931174] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card1/input11
Dec 21 23:47:00 wyvern kernel: [ 8.931211] input: HDA Intel PCH Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card1/input12
Dec 21 23:47:17 wyvern kernel: [ 25.264221] audit_printk_skb: 39 callbacks suppressed
Dec 21 23:47:17 wyvern kernel: [ 25.264224] type=1400 audit(1387669637.133:24): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/telepathy/mission-control-5" name="/usr/share/gvfs/remote-volume-monitors/" pid=2084 comm="mission-control" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Dec 21 23:49:21 wyvern kernel: [ 149.924471] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 21 23:49:21 wyvern kernel: [ 149.927574] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
Dec 21 23:49:21 wyvern kernel: [ 149.938434] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 21 23:49:21 wyvern kernel: [ 149.939441] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 21 23:49:21 wyvern kernel: [ 149.950001] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
Dec 21 23:49:53 wyvern kernel: [ 181.549147] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 21 23:49:53 wyvern kernel: [ 181.552185] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
Dec 21 23:49:53 wyvern kernel: [ 181.553205] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 21 23:49:53 wyvern kernel: [ 181.560211] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
Dec 21 23:49:53 wyvern kernel: [ 181.594732] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 21 23:49:53 wyvern kernel: [ 181.604921] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
Dec 21 23:51:01 wyvern kernel: [ 249.472364] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
Dec 21 23:51:01 wyvern kernel: [ 249.473373] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at...

[Jeffrey Knockel (jeff250)]

Allan, do the older kernels that don't seem to exhibit the bug recognize the touchpad as a touchpad? For instance, with the older kernels that don't seem to exhibit the bug, does the 'xinput' command list a generic mouse instead of what's normally listed as your touchpad?

[Allan Crooks (amcone)]

From 3.5.0-30 and earlier:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ PS/2 Generic Mouse id=12 [slave pointer (2)]

From 3.5.0-31 onwards:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ DualPoint Stick id=12 [slave pointer (2)]
⎜ ↳ AlpsPS/2 ALPS GlidePoint id=13 [slave pointer (2)]

When I booted into 3.5.0-44 to check how xinput identifies the touchpad, the problem seemed a lot more severe and immediate. So I think later kernels may have more of a problem with their implementation. That might possibly help in terms of determining what makes the problem worse.

I'll carry on using 3.5.0-30 for a while to see if I get any of the error messages appearing.

[penalvch (penalvch)]

Allan Crooks, thank you for performing the requested tests. The next step would be to fully commit bisect from 3.5.0-30 to 3.5.0-31, in order to find the offending commit. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#Commit_bisecting_Ubuntu_kernel_versions ?

[Allan Crooks (amcone)]

Just based on the last test that I did, it would seem that the drivers in use in kernel 3.5.0-31 are different to the generic mouse ones in kernel 3.5.0-30 (looking at the output from xinput) - rather than that a bug was introduced into the same set of drivers.

If the generic mouse drivers work and the Alps-specific drivers cause problems - I'm not sure how it would help to bisect the commits; you would either have to revert to the generic drivers as a solution or try to debug the Alps driver without having a previous working version of those drivers as a starting point for investigation.

[penalvch (penalvch)]

Allen Crooks, bisecting would provide the commit that caused this regression in functionality (introduction of buggy alps driver for you hardware).

[Jeffrey Knockel (jeff250)]

There's no actual regression though because, although the generic mouse driver doesn't have the sync issue, using it is even worse since it doesn't expose any touchpad-specific functionality.

[penalvch (penalvch)]

Jeffrey Knockel, thank you for your comments. As Allen Crooks is the original reporter, I would like to let him decide which he would prefer.

Thank you for your understanding.

[Allan Crooks (amcone)]

> As Allen Crooks is the original reporter, I would like
> to let him decide which he would prefer.

What I would prefer? What are my choices? I'd prefer to be able to use the touchpad-specific driver without any sync issue.

[Carl (n6rl)]

I'm having the same problems after a fresh install of Ubuntu 13.10 on a E7440. I get similar system log messages. Kernel: 3.11.0-14-generic

So there's currently no workaround for this, or is there?

[Allan Crooks (amcone)]

Would it be fair to say that this issue should be raised directly with the gmane.linux.kernel.input group to make progress?

@Carl W - You might possibly find the tip in comment 5 useful to stop the jumpiness of the pointer. Alternatively, you could use a much older kernel which will use the generic mouse drivers rather than specific touchpad ones (you will lose functionality if you do that, however).

[Marc (1marc1)]

I have been following this thread over the past couple of weeks and tried several things, including what's outlined in comment #5.

I found that running:

modprobe -r psmouse
modprobe psmouse proto=bare

solves the issue for me. However the caveat is that you don't have access to advanced touchpad features like scrolling.

The other effect of the above is that both track point and touchpad are active. I only use the track point. Since I constantly brush against the touchpad, I am still looking for a way to disable this. With the settings above, I can no longer disable the touchpad via "System Settings..." > "Mouse and Touchpad". So, if anyone knows how to do that....

Oh, to make the above changes permanent, create a file called "/etc/modprobe.d/47440-mouse.conf" with the content:

options psmouse proto=bare

I hope this helps someone.

Marc.

[shclim (shclim)]

Is this still an issue? I'm happy to file a new bug report if you could tell me what you mean by an "Ubuntu repository kernel".

Would it be helpful if I sent a report from a USB live instance of a 14.04 daily image?

[penalvch (penalvch)]

Scott Hosking, USB live is fine.

[Allan Crooks (amcone)]

I've posted in gmane.linux.kernel.input group (or is it just "linux.kernel.input"?) about a week ago without a reply.

My feeling is that this is a kernel bug, rather than specifically an Ubuntu one. But I don't know how to get the attention of the correct people to help fix it.

[gerpder (gerpder)]

Having issues here too, I'll second Allan in saying anything I can do to expedite a resolution for this please let me know as this is becoming a common device on Dell's business range laptops.

Running a Dell Latitude 3300 which displays the erratic pointer behavior

xinput --list --short
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ AlpsPS/2 ALPS GlidePoint id=12 [slave pointer (2)]
⎜ ↳ PS/2 Mouse id=13 [slave pointer (2)]
⎜ ↳ USB Optical Mouse id=15 [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)]
↳ Laptop_Integrated_Webcam_HD id=10 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=11 [slave keyboard (3)]
↳ Dell WMI hotkeys id=14 [slave keyboard (3)]

I can confirm that Marc's temp work around in #28 helps make the scrolling that bit smoother but it is not perfect and it results in miss clicks when typing.

[penalvch (penalvch)]

Allan Crooks, I wouldn't engage upstream quite yet, as this still hasn't been bisected as requested in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1258837/comments/18 , the latest mainline kernel hasn't been tested, and upstream prefers to see bug reports in a specific format that you may not have followed.

[nickez (nicke-claesson)]

I have the same problem on Debian 7 wheezy with (experimental kernel) 3.13.1-686-pae. This is not just an ubuntu issue.

[nickez (nicke-claesson)]

Same issue with 3.14-rc5.

[Ben Gamari (bgamari)]

I have also noticed repeated key presses running A10. I had chalked it up to an Xorg bug until I read this thread more carefully.

[Lorenzo (lorenzo-grespan)]

I have a Dell Latitude E7240 with the same problem of erratic mouse "jumps" and clicks, reported in the logs as:

psmouse serio1: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: GlidePoint at isa0060/serio1/input0 - driver resynced.

I tried booting with i8042.reset, which did not help.

However, the odd thing is that I plugged in a USB mouse and, after having removed it, the 'mouse jumps' behaviour stopped. I've also lost two-finger scrolling.

The plugged-in mouse was:

input: Microsoft Microsoft® 2.4GHz Transceiver v5.0 as /devices/pci0000:00/0000:00:14.0/usb1/1-2/
1-2:1.0/0003:045E:074F.0003/input/input21
hid-generic 0003:045E:074F.0003: input,hidraw2: USB HID v1.11 Mouse [Microsoft Microsoft® 2.4GHz
Transceiver v5.0] on usb-0000:00:14.0-2/input0

synclient returns:

    VertTwoFingerScroll = 1

Notice that the mouse wheel scrolling was also very erratic, but it was an old device and it might have been broken. Anyhow, this makes me think the "lost sync" problem might be related to some sort of "multi-touch" situation where one finger on the trackpad is wrongly interpreted as two and odd behaviour follows.

[sillyxone (sillyxone)]

Might be related to Lorenzo's thought: the random jumping and clicking only happen when the touchpad is treated as touchpad. I haven't had any problem when loading the touchpad driver as a simple mouse (no scrolling, tapping, multitouch, ... for the touchpad):

sudo modprobe -r psmouse
sudo modprobe psmouse proto=imps

I also found that whenever the touchpad started behaving badly (lots of "lost sync" messages), reloading the driver seems to reset it back to be good for a long while:

sudo modprobe -r psmouse
sudo modprobe psmouse

About keyboard input, it might be hardware (pretty common for Dell). I have an E6440 that I can easily reproduce the key repititions by hitting the keys in a certain way (e.g. tapping a key straight down lightly while relaxing my finger). It looks a lot like the "bounce" effect in the old desktop keyboards, perhaps Dell didn't put in good-enough bounce-filtering. I can reproduce the same problem in Windows and FreeDOS. My E7440 also had that problem initially (although not as easy to produce as the E6440), but not after Dell replaced the keyboard (together with the touchpad).

One solution for the keyboard repetition is to set the Bounce rate: Universal Access > Typing > Bounce Keys > Acceptance delay. You will have to experiment to find the right rate that work for you without missing intentional repetition (especially when smashing the keys when playing games). What works for my E6440 is to drag the delay all the way to shortest, then move the slider to the right (long) twice using the "right arrow" key.

[Leho Kraav (lkraav)]

I'm not actually on Ubuntu. Perhaps some of the other guys can provide the reports.

Just reporting now that the bug is still there on vanilla 3.16.1 kernel.

[Pali (pali)]

Why is this bug still in state incomplete?? What is there missing?

[Pali (pali)]

Anyway, to prevent random cursor movement and random mouse clicks you can force psmouse driver to reset ALPS device immediately after first invalid packet. It can be done with:

$ echo 1 > /sys/module/psmouse/drivers/serio:psmouse/serio1/resetafter

[Øyvind Stegard (oyvindstegard)]

Still a problem with latest BIOS A11 released by Dell a day ago. Just to keep the bug alive, because it very much is.

[Colin Taylor (cjntaylor)]

The problem with "resetafter" is that it causes the CPU to thrash given how often the driver gets out of sync. I tried doing that on my system, and it made it completely unusable (could barely type enough characters to update modprobe and regenerate initram. So far I've been living with loading the driver as proto=exps. I don't really use / want to use the touchpad itself, so the loss of functions doesn't matter as much to me. I do care, however, that in this mode, the kernel sees both devices as a single basic mouse, so I can't disable the touchpad to prevent accidental hits.

Sad to hear that A11 hasn't changed anything; I've been holding off upgrading the BIOS as I worry about bricking the system. Does it fix anything? The keyboard repeat? Does anyone know if that is related to this or not?

[Pali (pali)]

On Friday 17 October 2014 19:58:54 Christopher M. Penalver wrote:
> Unfortunately, this bug report is not scoped to you, or your
> problem.

What?? Sorry I do not want to spam this bug tracker, but there
are plenty people who have this and *same* problems on their
Latitude Exx40 laptops. Or I missed something?

> So your hardware and problem may be tracked, could
> you please file a new report

Did I understand correctly that you want that I should open new
duplicate bug about existing problem which is already tracked in
bug tracker? Why should I do that?

And my last question, how do you want to fix this problem? do you
have any idea what cause generating invalid packets?

[Øyvind Stegard (oyvindstegard)]

Christopher, I have the issue in this bug – there is no doubt. Can you please explain what value there will be in another duplicate bug report ? I shall refrain from comments that are off-topic for *this* bug, like the keyboard-repeats, which may or may not be related.

[Colin Taylor (cjntaylor)]

Sorry, didn't intend to conflate multiple issues. Duplicate bug report here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1382702

I kind of agree this seems kind of silly. Also, as this is a kernel driver bug, isn't this highly dependent on the version of the kernel you're running? I'm running the mainline kernel to get support for other features I want, so a fix on this version isn't going to help me all that much.

Submitting a bug just so it can be marked a duplicate seems silly.

[COLIN Stéphane (bigbob-fun)]

Øyvind, where did you find BIOS A11 for E7440 ?

I'm not able to find it (want to update my E7440).

[COLIN Stéphane (bigbob-fun)]

Ok, sorry for my post #78

I found it on the US site (I am searching on the French one at 1st).

I have flashed the A11 even if it doesn't fix this specific problem ...

[Rob (benssonrob)]

If anyone else is looking for the thread on the input ML regarding this issue: http://www.spinics.net/lists/linux-input/msg33751.html

So for now we have a workaround but having to wait ~ 1s for the touchpad to reconnect is an annoyance. For me it looks like this problem only manifest itself on linux and yet it seems to be a BIOS/firmware/something else bug?

[Pali (pali)]

Rob, see my comments #70. But Christopher already told us to not use this bug tracker, so I will not provide here more info anymore. Watch LKML for new patches.

[penalvch (penalvch)]

Pali, if you would care to read https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1258837/comments/73 I've never said to not use Launchpad, a development platform and bug tracker, as a bug tracker. Again what I said was file a new report if your problem addressed in Ubuntu.

As well, please see https://wiki.ubuntu.com/Kernel/Policies/DuplicateBugs .

[Rob (benssonrob)]

Pali, can you build a kernel for Ubuntu that integrate your workaround/patch so we can test it?

[Rob (benssonrob)]

Hi guys,

Pali told me that the patches to work around this issue are in 3.18 rc5.

[James Cohen (james-cohen)]

I'm having the same problem with Ubuntu 14.04 and an E7440 laptop. I've raised https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1396816 using `ubuntu-bug linux` and added Christopher as a watcher

[Rob (benssonrob)]

@James,

I'm not sure what you are expecting to be done but the patches to work around this (resync should be less frequent now) are in 3.18rc5 and should eventually hit -stable. Since this is likely to be a EC/BIOS/firmware bug & if you want Dell to solve this issue, create a thread here: http://en.community.dell.com/support-forums/laptop/f

FYI,

I downgraded to A05 from A07 (Latitude E6440) and this issue happens less frequently now. There's another user that report the same thing.

[cometdog (ericctharley)]

I have the same issue with Ubuntu 14.04 and an E7440.

The problem does not exist at all on Windows 7, using any BIOS I have tried (A05, A08, A10). That would seem to indicate that it is a driver issue, or can be solved by the driver.

[Rob (benssonrob)]

Well that's just silly at this point Christopher... unsubscribing from this bug. You have many dupes of E7440 as it is.

[Rob (benssonrob)]

Hey guys,

Please share your experience with Dell here: http://en.community.dell.com/support-forums/laptop/f/3518/t/19612640

[Rob (benssonrob)]

Christopher,

Dell community forum is monitored by Dell employees that can pass the info to their engineering team so that they can investigate this further. So what I'm doing is more purposeful than nagging people about opening a new bug report with info that you already have. *IF* it is a BIOS/firmware/EC bug there is no point in opening yet another bug report for an issue that can't be resolved in Linux!

[Pali (pali)]

On Friday 02 January 2015 11:56:09 Christopher M. Penalver wrote:
> Rob:
> >"So what I'm doing is more purposeful than nagging people
> >about opening a new bug report with info that you already
> >have."
>
> Spamming everyone with comments about a forum post is not
> helping here. As well, nobody has the information previously
> requested from you, as you didn't file a new report.
>

Christopher, spamming everyone without your useless posts about
duplicating same bug is even less useless.

> >"*IF* it is a BIOS/firmware/EC bug there is no point in
> >opening yet another bug report for an issue that can't be
> >resolved in Linux!"
>
> Then you don't understand how linux kernel development works.

And you Christopher do not know how linux kernel development
works too! *NOBODY* in linux kernel development want from users
to open duplicate bug reports.

> On select occasions, linux kernel engineers (not Dell
> employees) have implemented patches that WORKAROUND buggy,
> and outdated BIOS and hardware firmware.
>

Citation needed (TM). Who and how implemented WORKAROUND for
outdated BIOS? And what is outdated BIOS??

Btw, *I* am that developer who implemented WORKAROUND for current
situation and sent patch to upstream kernel (which is now part of
3.18 release). But it has nothing with BIOS and there are no
outdated BIOS versions. If you still do not understand this
problem reported in this (and more other!) bugs happens on all
Latitude Exx40 machines with any BIOS version.

I'm fed up with you. You just spam bug reports, bitching on users
who reported serious and critical problems, you did not helped
with *anything* and also you did not implemented any fix for this
problem.

Sorry but *all* your comments in this (and others too) are
totally useless. It did not helped me or other people who wanted
to fix this problem.

What you have done is just fed up users and forced them to not
report bugs anymore because it is useless...

> However, by not filing a report, you are robbing developers to
> track the true impact this has, all the hardware permutations
> that may be affected, and the opportunity to review your
> hardware specifically (marking yourself affected, or making
> "Me too!" comments is useless here as it's not verifiable by
> anyone). As well, you are just adding comment noise that
> isn't contributing towards having the issue addressed. By not
> doing as previously requested, you are only delaying your own
> problem from being addressed.

Addressed to whom? In last year nobody else provided any fix for
this bug. So what are you trying to do? We already know that this
problem is *same* for all Exx40 laptops and affect all people.
And posts "me too" just say that this problem happens really on
all those laptops and with all BIOS versions.

--
Pali Rohár
<email address hidden>

[penalvch (penalvch)]

Pali, thanks for the quick follow up. First, I never claimed this was a BIOS issue. Second, if a developer advises they don't want potential duplicates filed, as you have, then I defer to this preference. However, this is contrary to the preference documented by the Ubuntu Kernel Team regarding potential duplicates.

Despite this, could you please comment to the current progress of this issue for folks still reporting problems here?

Thank you for your understanding.

[knut (mr-knut)]

Hi,

I have the mouse jumping problem. I usually use the TrackPoint.
Latitude E5440
BIOS: A10
Linux: 3.13.0-37-generic #64-Ubuntu

syslog:
[38234.797838] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[38234.800971] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
[38234.828719] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[38234.838318] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
[38234.839346] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[38234.840408] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[38234.841446] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[38234.850882] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
[38234.851904] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[38234.852961] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[38234.854006] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[38234.865111] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.

[Mads Chr. Olesen (shiyee)]

Upgrading the BIOS to version A14 solved the problem for me: I still see
psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
but no erratic movement.

[shclim (shclim)]

According to the page linked below, BIOS A14 fixes Linux keyboard issues... there is no mention of Trackpad problems, very strange

http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=0P7G1

[sillyxone (sillyxone)]

Just upgraded my E7440 to A14. The keyboard still has problem with bouncing (hit a key and it could result in 2-3 entries of the same key registered), I still need to have a delay for "Bounce Keys" in Universal Access.

I haven't had any random mouse jumping with the touchpad since adding the "psmouse.resetafter=1" as suggested by #5 (and possibly with recent kernel updates). With the A14 BIOS, I don't have random touchpad jumping without that boot param, even when holding down a key (Shift/Ctrl/Alt) while moving the mouse. However, I've noticed that dmesg has a lot more "lost sync at byte 1" messages comparing to having "psmouse.resetafter=1" param, so I just put it back in.

In short, I can't tell if the A14 update helps at all on the erratic touchpad problem. It doesn't offer any advantage for me, even for the bounce key problem they claimed to fix.

[Mario Limonciello (superm1)]

I just wanted to let everyone know that Pali's fixes made it upstream and were CC'ed @stable and have landed across Ubuntu already. Anyone that has been affected should be able to update their kernels to get the patches.

Vivid (15.04):
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-vivid.git;a=commit;h=4ab8f7f320f91f279c3f06a9795cfea5c972888a
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-vivid.git;a=commit;h=9d720b34c0a432639252f63012e18b0507f5b432
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-vivid.git;a=commit;h=a7ef82aee91f26da79b981b9f5bca43b8817d3e4

Utopic (14.10):
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-utopic.git;a=commit;h=8a6f196c326599729da642046308754e2d94e6ab
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-utopic.git;a=commit;h=b0059ad9026c7755adae9865b845d8f8f5f4fa1b
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-utopic.git;a=commit;h=def3c611bd04af7768969f204774fb21b28f8980

Trusty (14.04):
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commit;h=3985506a72fd094724cae04f32fe0c35f35e14fa
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commit;h=42b384281eb27647b31bb2835781e20ade24b347
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commit;h=a34e4f19af5b02d65fffc3ae0ead3d3cb30598c7

[Philippe Ombredanne (pombredanne)]

I wanted to say thank you to all and Pali, Hans, Dmitry and Kamal in particular for creating and pushing the patches through. The patch has landed in a recent trusty update with kernel 3.16.0-45-generic. The situation is markedly better now, and no freeze anymore and dmesg unless I return from suspend.

I am still experiencing some issues though with the Alps touchpad (Dell E6540, with latest BIOS A15, Trusty latest updates), though these issues do not show up in dmesg.

I am entering a new separate ticket.:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1480615

For reference, the touchpad works only on the single window. Going to a VT with ctrl-alt-f1 and back to ctrl-alt-f7 restores things. No dmesg nor syslog show up so this may be an X issue instead.