XPS 13 9360 trackpad locks into scroll mode

[Jesse]

Hello,

I'm running Linux on a Dell XPS 13 (9360) laptop.

I find that upwards of 10 times per day, my trackpad gets stuck in "scrolling" mode. Moving the trackpad won't move the X windows pointer, but will send scrolling events to the foreground window.

When the trackpad is locked in this mode, the touchscreen will still let me move the mouse cursor, as will an external mouse.

On Ubuntu 16.04 freshly restored from the Dell recovery image, I find that it's often difficult to get the trackpad to recover.

I do find that the issue happens less frequently on Dell's build of Ubuntu 16.04 than on other linux distributions and versions, but it still happens enough to significantly impact my ability to do productive work.

The issue does not occur when running Windows 10 on the same device.

I suspect that the issue may be related to palm detection or misdetecting the user's palm as a gesture to enable scrolling mode, but have no proof for this.

It seems that I'm often able to reproduce the issue by brushing the trackpad with my right palm.

On Ubuntu 16.10, with the latest shipped 4.8 kernel (Linux szx 4.8.0-30-generic #32-Ubuntu SMP Fri Dec 2 03:43:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux), with the extra xinput configuration below, I am able to get the trackpad to recover, simply by clicking the trackpad:

/usr/share/X11/xorg.conf.d/99-libinput.conf:

Section "InputClass"
    Identifier "libinput touchpad catchall"
    Driver "libinput"
    MatchIsTouchpad "on"
    MatchDevicePath "/dev/input/event*"
    Option "Tapping" "True"
    Option "DisableWhileTyping" "True"
    Option "NaturalScrolling" "False"
    Option "AccelProfile" "adaptive"
    Option "AccelSpeed" "0.05"
    Option "MiddleEmulation" "True"
    Option "ScrollMethod" "twofinger"
    # Option "ClickMethod" "clickfinger"
    Option "ClickMethod" "buttonareas"
EndSection

In my experience, the problem manifests using both the Xorg synaptics driver and the Xorg libinput driver.

root@szx:/etc/modprobe.d# xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech M570 id=10 [slave pointer (2)]
⎜ ↳ DLL075B:01 06CB:76AF Touchpad id=13 [slave pointer (2)]
⎜ ↳ ELAN Touchscreen id=11 [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=12 [slave keyboard (3)]
    ↳ Intel Virtual Button driver id=14 [slave keyboard (3)]
    ↳ Intel HID events id=15 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=16 [slave keyboard (3)]
    ↳ Dell WMI hotkeys id=17 [slave keyboard (3)]
root@szx:/etc/modprobe.d#

[Stefan (t2000t2000)]

Hello,

this bug also affects me and I am on Arch Linux using libinput on Xorg with my Touchpad. However my Touchpad does not really recover by clicking if I use your configuration. Still it doesnt accept tap to click after recover and 2 or 3 finger gestures dont work either. Randomly touching and clicking eventually fixes it until it locks up in scroll mode again. This makes the touchpad practically unusable on this laptop.

If you need any configuration or debug information please let me know. Although I am not sure how exactly to reproduce the bug but it occurs almost everytime I use the touchpad for longer than 5 minutes so I will be able to reproduce...

[alex zhang (alex.zhang)]

Hello
  Thanks for the detail bug description and it is so helpful for digging the root cause through a correct direction.
  I also tried to reproduce this issue on XPS 13 (9360) laptop, the result is a little bit different, it can't move the X pointer after palm access to touch pad, and after that, 2 or 3 finger gestures don't work either. But it seems the system can recovery after a while or if switch the working window sometimes. Any way, the problem is confirmed exist and I personally think it is a driver related issue, since touch screen works fine, and the bottom half of pointer moving process touchpad triggered is the same as touch screen did. So the problem is happened in the top half of the pointer move process through X, it is the touchpad driver's responsibility to report pointer moving event though libinput to Xserver, and after that Xserver can generate the following commands to X graphic driver to show the move action to user.
  Sorry for the inconvenience you encounter in the work during using the 9360 xp13. We will update the touch pad driver ASAP.

[Jesse (jesse-fsck)]

Hi Alex,

I've actually seen it happen with both the libinput and synaptics driver. I also see it some of the time in Windows.

Do you have an estimate on when you might have a new touchpad driver to try?

[alex zhang (alex.zhang)]

Hi Jesse,
 Sorry for the arbitrary conclusion I made, that's just my personal idea, we are now working on it actually. I have to find the expert to analysis the details, can only answer your question as they reply to us. Hope you can understand :-) ,I will give you the update as I got the reply.

[Stefan (t2000t2000)]

Hi everyone,

I did the bios update from 1.0.7 to 1.2.3 yesterday and it _FEELS_ like the problem occurs less often. I don't know if thats just my feeling or the reality. What BIOS version are you using Jesse?

[Jesse (jesse-fsck)]

@Stefan - I'm on 1.2.3. I've seen the issue on 1.0.7 and 1.2.3. I've seen it on Fedora, Debian, Ubuntu and Windows 10, though definitely the least on Windows 10.

[alex zhang (alex.zhang)]

@Stefan, I am also using bios 1.2.3 to reproduce this issue.
@Jesse, as your experience on so many Linux OS release version, I guess it is a common issue of Xserver-Xorg. But I am not sure, I am going to try a01 manifest newer than a00 which is preload image, see if I can also encounter the problem. Will let you know later.

[Jesse (jesse-fsck)]

@alex - I see it in Xwayland on Fedora, too. And sometimes on Windows. So probably not an Xorg bug

[alex zhang (alex.zhang)]

@Stefan @Jesse Got you! Thanks :-)
 I tried to do online update operation, the problem is gone, could you please try it and see if you can still reproduce the issue? Here is the online update step.
   1 apt-get update
   2 apt-get dist-upgrade
   3 reboot.
 The kernel version is update from 4.4.0-23 to 4.4.0-41

[Jesse (jesse-fsck)]

Alex,

That was the very first thing I tried and did not resolve the issue for me.

[alex zhang (alex.zhang)]

Hi Jesse,
  You mean after the online update, kernel version is changed to 4.4.0-41, the problem still exist？ Actually I did that and tested the touch pad, it was OK. There is one question by me, did you change anything the about the source? I mean the apt source file. Another question is have you ever change any system configuration of any module?

[Stefan (t2000t2000)]

@alex: As stated above I am running Arch Linux, not Ubuntu. So from what you are saying I get that you have written a kernel patch for the touchpad driver, is that correct? Can you provide the patch files somewhere? Because I need to patch the kernel by myself until your patch hits upstream, I guess...

[alex zhang (alex.zhang)]

@Stefan: Actually it is my mistake to claim the point that this is a driver related issue, I hadn't talked it over with the touchpad vender when I said that point. It's just my idea. Sorry for the arbitrary conclusion. Right now, I haven't got the touchpad vender's response. I am not sure weather XPS 9360 support Arch Linux or not. As far as I know, officially we support only Ubuntu. Anyway, I will try ways to get in touch with the hardware vender to see what they say and I am also curious about this issue, wanting to know what's going on here.
@Jesse: If I may, could you please do DELL Recovery on the specific machine which your got this issue then do online update? See if the issue can be fixed.:-)

[Jesse (jesse-fsck)]

Alex,

I have tried that.

It makes the problem happen less often, but the problem does not go away.

Xie xie!

[alex zhang (alex.zhang)]

@Jesse You are welcome（不客气 bu ke qi） :-). Could you tell me the fail rate? You can do some research about xinput, there are some feature lists and some of them are related to the palm access and touchpad settings, if you have already known that,please just ignore it. Xinput is what I learned from the very issue, just share, hope the configure is useful. It should be a X component. By default, unlike 1 finger point gesture ,the palm access is not supported and can't move the pointer,I think.

@Stefan @Jesse Since we are not sure whether the root cause is the touchpad driver. I will keep touching them and let you fellows know the news.

[Jesse (jesse-fsck)]

@Alex - The failure rate is different every day. Sometimes I can work for an hour with no problem. Sometimes, it happens so often I have to use an external mouse. (Tonight, I am using an external mouse because I need to get work done and the 9360 keeps getting stuck in "scroll" mode)

I don't think it's the palm settings. It seems more like the trackpad detecting that I have two fingers on it and then never detecting that I raised one or both of them.

I hope you can get some good news from the touchpad vendor before CNY. If we can't solve this, I have to RMA this laptop. It's not usable like this :/

[alex zhang (alex.zhang)]

Hi Jesse,
 Got you! We have one more question about your action of dell recovery, as you mentioned before, you tried other image on the same machine, this action could be flush dell recovery partition, if that, everything is different, including online update and dell recovery. Could you please clarify those facts?

[Jesse (jesse-fsck)]

@alex - When I reinstalled Dell's Ubuntu, I used the recovery image from a USB stick to recreate the recovery partition and the Ubuntu install.

ProSupport seems to think that maybe this is a hardware failure

[Stefan (t2000t2000)]

It's been a while, so what is the status on this bug? I still have it and it is VERY annoying. The laptop is basically UNUSABLE without an external mouse!

I noticed that it can be reproduced quite often if you try to drag a window with the touchpad, i.e. use the left button to click on the window's top border and then move it with another finger.

[Stefan (t2000t2000)]

Hello?

Seems like no one cares about this problem... I still have it and also tried to use the X11 Synaptics driver instead of libinput. But still the touchpad gets stuck into scroll mode from time to time.

So what is the status on this bug?

[Grant (grantsewell)]

For what it's worth, this issue is also present on Debian 9, Fedora 25, Arch, and Windows 10.

One interesting thing I noticed - when it's stuck in the "scroll mode", the cursor appears to move semi-normally, but as I move my finger from the left to right, the cursor freezes when I reach the center of the trackpad and only scrolls. While I can't reproduce what causes the initial erratic behavior, I am able to reproduce this action.

[Paul Menzel (paulmenzel)]

Hi. First of all, we are also experiencing this issue with a Dell XPS 13 9360 *with* a touchscreen. I met another user *with no* touchscreen, who does *not* have this problem.

Everybody in here, do you all have the touchscreen variant?

Secondly, I talked to the Dell support, and they suggested to blacklist the module `psmouse` [1]. We are currently testing this, but it’d be great, if you also tried that.

Under Ubuntu 16.04 in a terminal, you execute the commands below.

```
$ echo blacklist psmouse | sudo tee /etc/modprobe.d/xps13-9360.conf
$ sudo update-initramfs -u
```

During *very* light testing, the issue couldn’t be reproduced.

[1] https://www.dell.com/support/article/de/de/debsdt1/SLN304721/erratic-cursor-movement-on-the-xps-9360-with-ubuntu-1604-installed?lang=EN

[Stefan (t2000t2000)]

I DO have the touchscreen variant as well.

But blacklisting the psmouse modul does NOT help. I did that a couple of month ago and I am still suffering from the problem, it is really annoying!!!

[John B (john-john-b)]

I have the non-touch version of the 9360 and regularly hit this issue with Ubuntu 16.10.

One thing that I found is that if it gets stuck in scrolling mode, if I place a finger on the top left corner of the trackpad (with my left hand), I can then move the mouse and scroll like normal with my right hand. As soon as I remove my left finger, the trackpad goes nuts again.

[Paul Menzel (paulmenzel)]

Has somebody found a way already, on how to produce it reliably. The Dell support (internal ticket(?) number 945231287) asked to install Microsoft Windows 10, and to reproduce it there. Any ideas, how to reproduce it under Microsoft Windows 10? We were unable to reproduce it, in the last 30 minutes.

[Paul Menzel (paulmenzel)]

My colleague was unable to reproduce the issue with Windows 10 over the weekend.

[Grant (grantsewell)]

I too have a 9360 with the touchscreen.

The most consistent way I have reproduced the behavior is by putting the laptop into sleep, typically by shutting the lid. Upon resuming, this almost always results in erratic cursor behavior, whether jumping or scroll lock.

Currently observed on Arch Linux 4.10.3-1. I have psmouse blacklisted in modprobe.d.

[Yuriy Vidineev (adeptg)]

I have the same hardware (Dell 9360) and same (or similar) issue. Can please someone try to fix it when it occurs by:

rmmod i2c_designware_platform
rmmod i2c_designware_core
modprobe i2c_designware_core
modprobe i2c_designware_platform

Just to check if it's the same issue as mine

[Paul Menzel (paulmenzel)]

@adeptg, do you have a device with or without touchscreen?

[Paul Menzel (paulmenzel)]

@jesse-fsck, as the original reporter, do you still experience this issue?

Another status report, installing Ubuntu 16.04 LTS from the official Ubuntu sources, as the Dell image [1] is broken, with Linux 4.8.0-41-generic (4.8.0-41.44~16.04.1) and Unity, there hasn’t been one touchpad problem since yesterday evening. I moved windows around, scrolled in the Firefox Web browser, and also suspended and resumed the system.

[1] https://www.dell.com/support/home/us/en/19/Drivers/OSISO/linux

[Yuriy Vidineev (adeptg)]

@paulmenzel, with touchscreen. And I'm using pre-installed Ubuntu from Dell

[Grant (grantsewell)]

@adeptg - I just tried this. My cursor had locked into scroll and was jumping erratically. Unfortunately, it did not resolve the problem.

[Yuriy Vidineev (adeptg)]

@grantsewell - thanks for checking. Looks like I have different issue

[Amnon Yekutieli (amyekut)]

I am experiencing a somewhat different buggy touchpad behavior: it works most of the time, but quite often I lose response to finger motion.

This is only for moving the pointer and 2 finger scrolling - I disabled all other functions.

My system is a a Dell XPS 13 9360 running KUBUNTU 16.10.

The touchpad driver I have now is
  xserver-xorg-input-libinput

It seems to be less troublesome than the synaptics driver.

Here is the "xinput" information:

Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ DLL075B:01 06CB:76AF Touchpad

Any tips would be very welcome!!!

[Yuriy Vidineev (adeptg)]

@amyekut, have you tried

rmmod i2c_designware_platform
rmmod i2c_designware_core
modprobe i2c_designware_core
modprobe i2c_designware_platform

when it happened?

[Amnon Yekutieli (amyekut)]

@adeptg: I am not familiar with these operations. Are they supposed to unload and then reload some kernel modules? Will there be any feedback on the terminal?

[Yuriy Vidineev (adeptg)]

@amyekut, yes it's just modules reload. There shouldn't be any feedback if there is no errors

[Amnon Yekutieli (amyekut)]

@adeptg: I ran the two first commmands:
 rmmod i2c_designware_platform
 rmmod i2c_designware_core
just to see the effect, without a touchpad failure.

The result: the touchpad stopped activity altogether.

Then I ran the last two commands:
 modprobe i2c_designware_core
 modprobe i2c_designware_platform

This caused the touchpad to resume. But the activity was jumpy and not reliable:
- one finger movement caused scrolling instead of pointer motion.
- then the pointer got stuck (it is stuck now as I write and I had to connect a mouse).

To summarize: the sequence of commands made the touchpad go from ok to broken.

[Yuriy Vidineev (adeptg)]

@amyekut maybe it can also do a reverse: from broken to ok :)
As it works in my case

[Amnon Yekutieli (amyekut)]

@adeptg: I'll try it a few times when there's the malfunction.

Of course this is a totally ersatz trick. No idea how to get a genuine fix?

[Amnon Yekutieli (amyekut)]

@adeptg: I just tried your recipe.

The touchpad got stuck while I was running FOXIT (a big program). So I ran your sequence in a terminal.

It DID NOT FIX MY TOUCHPAD.

[Kai-Heng Feng (kaihengfeng)]

Does unbind the hid-multitouch driver helps? Please test it before touchpad locks:

# cd /sys/module/hid_multitouch/drivers/hid\:hid-multitouch
# ls
0003:04F3:20D0.0001 0018:06CB:76AF.0002 bind module new_id uevent unbind

0018:06CB:76AF.0002 is the touchpad, the other one is touchscreen, which is what we want to unbind.

# echo 0003:04F3:20D0.0001 > unbind

The touchscreen should stop working now. Does the touchpad behave correctly now?

[Amnon Yekutieli (amyekut)]

@kaihengfeng :
I'm not sure whom you're directing the suggestion to. My computer does not have a touchscreen.

[Kai-Heng Feng (kaihengfeng)]

Comment #22 suggests so.

[Paul Menzel (paulmenzel)]

@amyekut, thank you for participating in this discussion, but clearly it has been established, that your issue is different from the original report. It’d be awesome, if you created a new bug report for your issue.

[Paul Menzel (paulmenzel)]

@kaihengfeng, thank you for looking into this issue. Do you have such a device and are able to reproduce it?

As written in comment #30, we were unable to reproduce this issue with Ubuntu 16.04 LTS and Linux 4.8.0-41-generic. Unfortunately, nobody else in this thread seems to have tested that.

[Kai-Heng Feng (kaihengfeng)]

No, I can't reproduce the issue on both 4.4.0-67 and 4.8.0-44, that's why I want to know if the touchpad/touchscreen combination is the culprit.

Last time I checked, both Xenial and Yakkety kernel contains necessary fix for the touchpad, so I am really curious what happens here.

[Paul Menzel (paulmenzel)]

That’s interesting. Could you please point us to the necessary fix?

[Kai-Heng Feng (kaihengfeng)]

Xenial:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/drivers/hid/hid-multitouch.c?id=d3c19637b8dd681334421356e726a7a6adbd4076

Yakkety:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-yakkety.git/commit/drivers/hid/hid-multitouch.c?id=6dd2e27a103d716921cc4a1a96a9adc0a8e3ab57

[Paul Menzel (paulmenzel)]

Thank you for digging up the URLs. (Unfortunately, they cannot be securely browsed with HTTPS.)

Looking at the time-stamps and change-log, these changes were “active”, when @Jesse reported the issue in December 2016, and I experienced the issue with Dell’s Ubuntu in the end of November 2016.

So there seems to have been a regression in between, which is now fixed, or – also possible – that installing Microsoft Windows 10 in between fixed the issue somehow.

[Grant (grantsewell)]

@kaihengfeng I just tried to unbind the touchscreen while my touchpad was locked into scroll. The touchscreen did stop working, but the touchpad remained in the scroll mode.

[Paul Menzel (paulmenzel)]

@grantsewell, I assume that was with Arch Linux and Linux 4.10.x?

[Grant (grantsewell)]

@paulmenzel Yes, Arch Linux, Kernel 4.10.5-1

[Kai-Heng Feng (kaihengfeng)]

@Grant

You should unbind it before anything bad happens.
If touchpad keeps working after touchscreen unbind, we can know it only happens on this combination.

[Grant (grantsewell)]

@kaihengfeng Done. I'll report back with findings.

[Grant (grantsewell)]

@kaihengfeng After the touchscreen unbind, I was able to work for about an hour, but still experienced the scroll lock issue. Mostly Internet browsing (Chromium), I seemed to be able to cause the issue after rapidly moving the cursor on the touchpad.

Current OS: Arch Linux 4.10.6-1

[Kai-Heng Feng (kaihengfeng)]

Thanks, then then the problem is probably not linked to touchscreen.

[Dustin (dlacewell)]

Hello,

I'm running 4.8.0-41-generic #44~16.04.1-Ubuntu and I experience this issue all the time. I just did the unbind and it instantly resolved the issue.

This is just ancedotal, but here's what I have to contribute:

Part of me thinks its some kind of overheating issue. When the laptop is moderately warm, a slight bending to the chassis around the touchpad will cause the touchpad to move and send various events. Secondly, when my touch-pad gets locked up, by physically smashing the touchpad aggressively with my fingers, especially in the top right corner, I can momentarily resolve the issue. But then it comes back after a few movements of the mouse. Lastly, one time when smashing the touchpad to try to get it to get out of scroll-mode, I saw the blue-dots of the touch-screen text-selection UI blink momentarily around the mouse. How is that possible?

[Dustin (dlacewell)]

Oh crud, literally after typing this, the issue came back!

[John B (john-john-b)]

Just to reiterate from my previous post, I have a 9360 with the non-touch FHD screen, and I am experiencing this exact issue as well. I'm running Ubuntu 16.10.

[Stefan (t2000t2000)]

Regarding a procedure to reproduce this issue:

For me it very often happens if I try to use drag and drop with the touchpad. For example you can use any file manager, mark a file, i.e. click the left touchpad physical button, left it clicked with one finger and then use a finger of the other hand to drag the file somewhere else. Repeat this a couple of times and it almost always ends up being stuck in scroll mode.

Another scenario where it happens for me is when I try mark multiple files in dolphin for example. Physically click the left touchpad button next to some files and then draw a rectangle with a finger from the other hand around some files. Do this a few times and the touchpad gets stuck in scroll mode.

[Kai-Heng Feng (kaihengfeng)]

@Dustin, does your machine have NVMe?

Also, please try the attached package - the current thermald in the Ubuntu repository does not support Kabylake. Newer thermald supports it, but I don't how well it behaves, please give it a shot.

[Paul Menzel (paulmenzel)]

I am still unable to reproduce the issue with the software and versions shipped by Ubuntu 16.10. Neither in Unity nor GNOME (Shell).

Now I built and install Linux 4.11-rc5. And with that, I was able to reproduce the issue in Unity and GNOME.

@john-john-b, what Linux kernel version and desktop environment are you using?

[Grant (grantsewell)]

Confirmed activity is able to be reproduced when touchscreen is disabled in Dell BIOS.

Additionally, this behavior is easy to reproduce when using Inkscape or GIMP, possibly due to heavy scrolling activity and/or resource utilization. I do not have thermald installed.

Current Kernel: 4.10.8-1-ARCH

[Kai-Heng Feng (kaihengfeng)]

@Grant,

Can you try it? (Don't forget to enable and start it).
Thermald in Arch repo is 1.6, which supports kabylake now.

[Grant (grantsewell)]

Installing thermald did not work - I was able to use Inkscape for a few minutes and the behavior resumed. That being said, there may be some advanced configuration required, as I'm not that familiar with thermald - here's an output from systemctl status:

● thermald.service - Thermal Daemon Service
   Loaded: loaded (/usr/lib/systemd/system/thermald.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2017-04-07 19:08:02 EDT; 1min 31s ago
 Main PID: 311 (thermald)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/thermald.service
           └─311 /usr/bin/thermald --no-daemon --dbus-enable

Apr 07 19:08:02 xpGs thermald[311]: 22 CPUID levels; family:model:stepping 0x6:8e:9 (6:142:9)
Apr 07 19:08:02 xpGs thermald[311]: Polling mode is enabled: 4
Apr 07 19:08:02 xpGs thermald[311]: Using generated /var/run/thermald/thermal-conf.xml.auto
Apr 07 19:08:02 xpGs thermald[311]: csys_fs::read exception /sys/class/thermal/thermal_zone6/trip_point_0_hyst
Apr 07 19:08:02 xpGs thermald[311]: csys_fs::read exception /sys/class/thermal/thermal_zone6/trip_point_1_hyst
Apr 07 19:08:02 xpGs thermald[311]: csys_fs::read exception /sys/class/thermal/thermal_zone6/trip_point_2_hyst
Apr 07 19:08:02 xpGs thermald[311]: csys_fs::read exception /sys/class/thermal/thermal_zone6/trip_point_3_hyst
Apr 07 19:08:02 xpGs thermald[311]: csys_fs::read exception /sys/class/thermal/thermal_zone6/trip_point_4_hyst
Apr 07 19:08:02 xpGs thermald[311]: XML zone: invalid sensor type TMEM
Apr 07 19:08:02 xpGs thermald[311]: Zone update failed: unable to bind

[Kai-Heng Feng (kaihengfeng)]

Well, let's do something more extreme - keep the CPU temperature under 50 degree:

# dbus-send --system --dest=org.freedesktop.thermald /org/freedesktop/thermald org.freedesktop.thermald.SetUserMaxTemperature string:cpu uint32:50000

If this still happens - the issue is unlikely to related to temperature.

[Stefan (t2000t2000)]

@kaihengfeng: I think this test is now obsolete. Yesterday evening my laptop was in idle state for like 1.5 hours doing nothing and felt almost cold, i.e. WAY below 50 degrees. When I wanted to do some drag&drop operations the touchpad locked itself into scroll mode again :( So the laptop was definately cold, no "overheating" or "overwarming" involved.

[Kai-Heng Feng (kaihengfeng)]

I guess we can exclude it's related to physical?

Please boot with additional kernel parameter 'i2c-hid.debug=1 i2c-hid.dyndbg=+p hid-multitouch.dyndbg=+p', attach `dmesg` when the issue reappears.

[Grant (grantsewell)]

I agree on the heat - while I wasn't able to generate the issue with the CPU temp config provided, a restart always resolves the issue, and I'm sure the CPU is still fairly hot if that was the case.

I'm currently booting with the new kernel parameters. After the issue starts, there are no new dmesg events related to hid or i2c.

[Kai-Heng Feng (kaihengfeng)]

Well, I should say "when the issue reappears, use move single finger on touchpad and attach `domes`."

[Grant (grantsewell)]

Issue has occurred again. Still, nothing in dmesg. I did run libinput-debug-events. Normally, the below output is displayed, followed by detailed coordinate movement of the cursor. Despite the cursor moving, NO details were registered in the debug window. Touchpad coordinates and keyboard strokes were displayed appropriately.

In the middle of my testing, the touchpad started working again and the details immediately showed up in the debug window.

Debug Data:

event4 DEVICE_ADDED Video Bus seat0 default group2 cap:k
-event1 DEVICE_ADDED Power Button seat0 default group3 cap:k
-event2 DEVICE_ADDED Sleep Button seat0 default group4 cap:k
-event16 DEVICE_ADDED ELAN Touchscreen seat0 default group5 cap:t size 305x170mm calib
-event17 DEVICE_ADDED Integrated_Webcam_HD seat0 default group6 cap:k
-event15 DEVICE_ADDED DLL075B:01 06CB:76AF Touchpad seat0 default group7 cap:pg size 101x57mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on
-event7 DEVICE_ADDED Intel Virtual Button driver seat0 default group8 cap:k
-event6 DEVICE_ADDED Intel HID events seat0 default group9 cap:k
-event5 DEVICE_ADDED AT Translated Set 2 keyboard seat0 default group10 cap:k
-event9 DEVICE_ADDED Dell WMI hotkeys seat0 default group11 cap:k

[Kai-Heng Feng (kaihengfeng)]

@Grant,

Did your touchpad stop working completely?

Otherwise, it should still send i2c commands, otherwise there's no 'scroll' in 'scroll mode'.

[Grant (grantsewell)]

@Kai-Heng,

The touchpad still worked (locked in scroll mode), but no commands were logged in libinput-debug-events. The touchscreen still logged events.

[Kai-Heng Feng (kaihengfeng)]

Well, I mean dmesg...

[Grant (grantsewell)]

dmesg attached

[Kai-Heng Feng (kaihengfeng)]

I think the touchpad stops working correctly after 20 00 03 07, but it's not the root cause here.

I managed to reproduce the issue - especially when the battery is charging.

Can you pull the battery out and test again? I highly suspect the battery swells, hence bends the touchpad.

[Paul Menzel (pm-debian)]

@kaihengfeng, great news that you were able to reproduce it. Could you please give more details. What Linux kernel version, what OS, what desktop environment? How much(?) was the battery charged?

[Paul Menzel (pm-debian)]

@kaihengfeng, also, how can the battery be removed? Doesn’t that void the warranty?

[Grant (grantsewell)]

I'm also hesitant about removing the battery. Additionally, I have this happen frequently during the day when I'm running on battery. And a restart fixes the issue - if the battery swelling is the root cause, I would think the issue would persist after a reboot.

Naturally, I would love to be proven wrong so we can find a fix for this issue!

(Also, since this just happened to me again after resuming from sleep mode, I thought I'd attach another dmesg output.)

Arch Linux 4.10.9-1 x64

[Kai-Heng Feng (kaihengfeng)]

Mime is more like comments #58 - I can see the touchpad is a little above the palmrest area, especially when charging.

That'll be nice if we can get a Synaptics guy to investigate this issue. Otherwise I'll need more time to translate the actual i2c <-> hid command.

[Grant (grantsewell)]

Mine is also similar to #58.

Hot or cold, the front right and front left of my touchpad rests above the palmrest, just slightly. Not the front center though. I've seen this also reported in other forums.

[Grant (grantsewell)]

I'm leaning back to the assessment from Kai-Heng. I booted my system today, plugged in and charging, and started a kernel compile for 4.11. I came back to the system after no other activity, while the CPU and system fans were churning. My touchpad was locked into scroll mode already.

This seems to be leaning back towards a hardware defect, potentially related to the battery expanding against the touchpad.

[Paul Menzel (paulmenzel)]

@grantsewell, did you contact the Dell support? A support employee told me, that there are known problems with the battery, and that you should check with the Dell support to check if your system is affected.

In my case, they told me, that my system is not affected though.

[Grant (grantsewell)]

@paul - have you opened a case with Dell? I saw this post today while continuing to research the issue.

http://en.community.dell.com/techcenter/os-applications/f/4613/t/20008150

[Paul Menzel (paulmenzel)]

@grantsewell, yes I did. They couldn’t reproduce it, and asked me to install Microsoft Windows 10, and I wasn’t able to reproduce it there. So they said, it’s not a problem. You should open a separate case please.

[Grant (grantsewell)]

Dell is replacing my palm rest to see if this resolves the issue.

[Grant (grantsewell)]

@thread The replacement touchpad and bezel/palm rest appears to have resolved the issue. It may be a matter of resetting the touchpad itself, as there is no difference in model or version of the old and new touchpads. The new touchpad sits more uniformly and below the palm rest, vs the old pad which sat noticeably above the bezel.

I will report back if the behavior resumes, but I have been using the system for 12+ hours with no issues.

[Grant (grantsewell)]

@thread I believe this issue stems from an assembly problem. I have been using my laptop for over a week with a new palm rest and touchpad with no issues. I recommend closing this bug as a hardware/assembly problem. It most likely can be fixed by a careful user by removing and resetting the touchpad into the palm rest.

[Grant (grantsewell)]

Assembly related issue, Non-Software: See Comment #89

[Paul Menzel (paulmenzel)]

Please reopen the issue. There are several users, which still need to report back. Especially, @jessie and @kaihengfeng.

[Grant (grantsewell)]

Issue started reappearing today.

[Max Rumpf (maxr1998)]

I just got my Dell XPS 9360 a few days ago, without touchscreen, and I repeatedly get the issue, while charging and while not charging, on 16.04 before I upgraded as well as on 17.04, with Linux 4.10.0-28-generic.

I'm using the Synaptics driver and have the the i2c_hid kernel module blacklisted, to get rid oft the duplicate `⎜ ↳ DLL075B:01 06CB:76AF Touchpad` in xinput.
I only have the `⎜ ↳ SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]` PS touchpad in my xinput now.

Here's also the ouput of my `synclient`:
```
max@xps13:~$ synclient
Parameter settings:
    LeftEdge = 1583
    RightEdge = 5359
    TopEdge = 1371
    BottomEdge = 4481
    FingerLow = 25
    FingerHigh = 30
    MaxTapTime = 180
    MaxTapMove = 250
    MaxDoubleTapTime = 180
    SingleTapTimeout = 180
    ClickTime = 100
    EmulateMidButtonTime = 0
    EmulateTwoFingerMinZ = 282
    EmulateTwoFingerMinW = 7
    VertScrollDelta = -113
    HorizScrollDelta = -113
    VertEdgeScroll = 0
    HorizEdgeScroll = 0
    CornerCoasting = 0
    VertTwoFingerScroll = 1
    HorizTwoFingerScroll = 1
    MinSpeed = 1
    MaxSpeed = 1.75
    AccelFactor = 0.0351679
    TouchpadOff = 0
    LockedDrags = 0
    LockedDragTimeout = 5000
    RTCornerButton = 2
    RBCornerButton = 3
    LTCornerButton = 0
    LBCornerButton = 0
    TapButton1 = 1
    TapButton2 = 3
    TapButton3 = 2
    ClickFinger1 = 1
    ClickFinger2 = 0
    ClickFinger3 = 0
    CircularScrolling = 0
    CircScrollDelta = 0.1
    CircScrollTrigger = 0
    CircularPad = 0
    PalmDetect = 1
    PalmMinWidth = 10
    PalmMinZ = 200
    CoastingSpeed = 20
    CoastingFriction = 50
    PressureMotionMinZ = 30
    PressureMotionMaxZ = 160
    PressureMotionMinFactor = 1
    PressureMotionMaxFactor = 1
    ResolutionDetect = 1
    GrabEventDevice = 0
    TapAndDragGesture = 1
    AreaLeftEdge = 0
    AreaRightEdge = 0
    AreaTopEdge = 0
    AreaBottomEdge = 0
    HorizHysteresis = 28
    VertHysteresis = 28
    ClickPad = 1
    RightButtonAreaLeft = 0
    RightButtonAreaRight = 3251
    RightButtonAreaTop = 4083
    RightButtonAreaBottom = 0
    MiddleButtonAreaLeft = 3251
    MiddleButtonAreaRight = 3690
    MiddleButtonAreaTop = 4083
    MiddleButtonAreaBottom = 0
```

[Kai-Heng Feng (kaihengfeng)]

Can you guys try latest mainline kernel 4.13-rc3?

I'd like to know if this commit solves the issue:

commit 4f4001bc76fd1a138a501fbd3d68cce72cbf96ce
Author: Benjamin Tissoires <email address hidden>
Date: Thu Jun 15 15:32:04 2017 +0200

    HID: multitouch: fix rare Win 8 cases when the touch up event gets missing

[Oh the Huge Manatee (vertesi-n)]

@kaihengfeng I installed kernel 4.13-rc4-generic last night and have used it all day without any scroll lock problems! Normally by now I would have been punching the trackpad in frustration. Thank you @kaihengfeng and thank you Benjamin Tissoires, I suspect you've saved my sanity.

[Oh the Huge Manatee (vertesi-n)]

I take it back... still had occasional scroll locks, but *much* improved. It might even just be my libinput settings at fault. I'll play with it a little and report back.

[Kai-Heng Feng (kaihengfeng)]

Kernels (Xenial, Zesty, Artful) with backported commits:

http://people.canonical.com/~khfeng/lp1651635/

[Evan Dingman (aderon)]

Was experiencing this issue on 4.4.0-41-generic. The touchpad would randomly lock up and act erratically. As John B mentioned, if I placed a finger on the top left corner of the trackpad while holding down at another point on the pad, I could get it to work, but it would fail as soon as I lifted up the top left finger.

Upgraded to 4.12.8-041208-generic and I've been on for about 3-4 hours without issue. Usually I would experience the trackpad lockup within minutes. I also attempted recreating the issue using methods that had worked prior to upgrading. But, those methods no longer cause the touchpad to lock up. For me, it appears to have resolved it.

[Kai-Heng Feng (kaihengfeng)]

I will be appreciated if you can test kernel I built - so I can put the patches to Xenial and Zesty.

[Oh the Huge Manatee (vertesi-n)]

After a couple of weeks of testing with the RC... I still get the lockups, but less frequently now. and they are more clearly related to when I'm click-and-dragging. It's always resolved by just lifting my finger from the touchpad and waiting for a second or so. I can also resolve by a single solid, very clear click on the right and left click areas of the touchpad. Technically I have those areas disabled, but that's irrelevant. :|

I've been on 4.13 stable for the last couple of days, and I really notice the improvement in the touchpad.

[Esokrates (esokrarkose)]

XPS 13 9360 without touchscreen:
I have tested 4.13 kernel and also 4.9 with the commit from #94 backported, but in both cases the issue reappears, so this is not resolved :-(.

[Paul Menzel (paulmenzel)]

Kai-Heng, what’s the current status here? People still report, it’s not working. At the official Dell Sputnik forum, sjoss posted on 23 Oct 2017 14:41 [1]. Though that Linux kernel image seems outdated.

> I also have the same problem, running kernel 4.10.0-19-generic #21-Ubuntu SMP
>
> This tiny problem is super annoying since it's the only problem that makes me regret my MacBook Air sometimes.
>
> Please fix and make us happy.

[1] http://en.community.dell.com/techcenter/os-applications/f/4613/t/19681145

[Kai-Heng Feng (kaihengfeng)]

Try kernels in comment #97 so I can backport the patch to Ubuntu's kernel with confidence.

[Paul Menzel (paulmenzel)]

I can unfortunately not log into the Dell forum, so it’d be great if some Dell person could forward that testing request.

[Esokrates (esokrarkose)]

Kai: As I mentioned in #101, the mentioned commit (4f4001bc76fd1a138a501fbd3d68cce72cbf96ce) does not resolve the issue, I still get very annoying scroll locks. The 4.13 upstream did still have the issue.

[Kai-Heng Feng (kaihengfeng)]

Esokrates,
Does reload "i2c-hid" and "hid-multitouch" help your situation?

[Esokrates (esokrarkose)]

I will try that when it happens again (sometimes very regularly making it almost impossible to work, sometimes i does not happen for a weeks).

To give a more precise description of the behavior:

* When the touchpad enters scroll-lock, moving the pointer works by using two fingers, but that does not work very reliably, the cursor starts to jump.
* Most of the time a (right) click will get me out of the scroll lock, but after moving the cursor a tiny bit it locks again. Clicking and moving a few times removes the issue permanently.
* The issue is NOT related to hardware temperature. Sometimes when waking the laptop from suspend in the morning the issue appears.
* Rebooting did resolve the issue in all cases I got.

[Oh the Huge Manatee (vertesi-n)]

From a few weeks later: 4.13 (specifically commit 4f4001bc76fd1a138a501fbd3d68cce72cbf96ce ) really improved the situation. It occurs much less frequently (3-4x per full day of use), and it's clearer what's happening when it does occur. Sorry this is hard to describe: it happened many times a day before. I guess the lost mouseup events from that commit gave us a similar, but different set of symptoms. I can tell you that before, the mouse would get stuck in a mode, or would stop moving, or would start clicking all over the place. On 4.13 it's really just that it gets stuck in scroll mode.

Clear right-clicks, or a couple of seconds wait, seems to release it. I think it also releases when I do some actual scrolling, though I keep forgetting to try that when it actually happens. Mostly I just get so frustrated...

I suspect that it only happens when I scroll - ie it loses the "touch up" event from multiple fingers. So doing anything that gives a new multi-finger touch up acts like a re-send. I don't have the problem that Esokrates describes, "after moving the cursor a tiny bit it locks again"... though that could be because I right click a few times to make sure it's cleared.

[Kai-Heng Feng (kaihengfeng)]

Oh the Huge Manatee,

It occurs much less frequently means it still happen sometime, right?
Does reload "i2c-hid" and "hid-multitouch" reset the touchpad back to normal?

[Oh the Huge Manatee (vertesi-n)]

@kaihengfeng I was just having an "attack" of these events as I started writing this post! I guess it DOES come in clusters for me, after all. :| I tried `sudo rmmod i2c-hid hid-multitouch && sudo modprobe i2c-hid hid-multitouch`. Almost immediately afterwards I still had the problem.

Today I left `sudo evtest /dev/input/event16 |grep EV_KEY` running, to try and catch the trackpad in the act. It acted up, but when I switched to the desktop with that terminal on it (with the keyboard), it had already resolved itself. It quickly acted up again, however. At present it seems like it just wants to prove me wrong, that it CAN happen in clusters. :|

Here's the output. I'll annotate as we go along. You can see some normal mouse activity here, with the timestamps incrementing by a second or more between event clusters.

Event: time 1509044426.298980, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509044426.298980, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509044426.434514, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509044426.434514, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509044427.045093, type 1 (EV_KEY), code 272 (BTN_LEFT), value 1
Event: time 1509044427.137465, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0
Event: time 1509044427.164803, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509044427.164803, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509044427.350292, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509044427.350292, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509044427.704242, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509044427.704242, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0

Right here, it begins. I don't know if the first event is real or not, but now we're getting BTN_TOUCH and BTN_TOOL_FINGER flickering on and off about every 10000 microseconds.

Event: time 1509044429.679735, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509044429.679735, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509044429.706049, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509044429.706049, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509044429.720705, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509044429.720705, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509044429.833727, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509044429.833727, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509044429.841380, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509044429.841380, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509044429.855022, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509044429.855022, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509044429.862632, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509044429.862632, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509044429.968564, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 150904...

[Oh the Huge Manatee (vertesi-n)]

Attaching my terminal session. Seems to work now.

[Kai-Heng Feng (kaihengfeng)]

You mean after the cluster events, it eventually went normal somehow?

[Oh the Huge Manatee (vertesi-n)]

Yes, it usually does. I'll have a cluster of "episodes", where it gets stuck several times within 30 minutes or so... then it just stops happening.

Is it not that way for you?

Is it possible... spitballing here, but... I know this trackpad doesn't give pressure information to the kernel. Is it possible that it tries to actively adjust sensitivity, and if you're using a really light touch, at some point it gets so sensitive that it false-fires? Then maybe the cluster ends because I get super frustrated and start clicking REALLY hard, which would decrease sensitivity.

[Oh the Huge Manatee (vertesi-n)]

Side note on that theory... is it possible this is affected by your position using the laptop/ I find it rarely happens sitting on it's stand at the office, but laying back on the couch at home, with the laptop on my stomach, it drove me crazy. Or maybe that's just correlation.

[Esokrates (esokrarkose)]

Regarding that side note: The position of the laptop is completely irrelevant. Happens to me while the laptop is fixed on a desk.

[Oh the Huge Manatee (vertesi-n)]

Yeah, and just after I wrote that I started having a cluster at my office too. Whatever it is, it's closely related to the irony subprocessor.

[Oh the Huge Manatee (vertesi-n)]

I plugged in an external trackpad this afternoon, and worked with the built-in until it started an episode.

evtest on the built in trackpad input is as before. But now I can switch to my other trackpad and wait to see if it will "unclick" on it's own. So far (about 5 minutes), no. Interesting to note that the "flickering" only happens when I am moving my finger on the trackpad. That doesn't fit the hypothesis about power leakage. It's misinterpreted input.

here's the log. It starts just before the episode begins. You can see me trying to get out of it with firm left clicks, but no dice.

Event: time 1509110093.492320, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509110093.492320, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509110093.939374, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509110093.939374, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509110094.444481, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509110094.444481, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509110094.834651, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509110094.834651, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509110095.162037, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509110095.162037, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509110098.259034, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509110098.259034, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509110099.140794, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509110099.140794, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509110101.839693, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509110101.839693, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509110102.771010, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509110102.771010, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509110103.139904, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509110103.139904, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509110103.389092, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509110103.389092, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509110104.149745, type 1 (EV_KEY), code 272 (BTN_LEFT), value 1
Event: time 1509110104.213488, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0
Event: time 1509110105.080315, type 1 (EV_KEY), code 272 (BTN_LEFT), value 1
Event: time 1509110105.200963, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0
Event: time 1509110105.256869, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1509110105.256869, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1509110105.378396, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1509110105.378396, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1509110105.762201, type 1 (EV_KEY), code 272 (BTN_LEFT), value 1
Event: time 1509110105.854411, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0
Event: time 1509110105.917633, typ...

[Esokrates (esokrarkose)]

This bug is haunting me just now, does not stop happening.

Reloading the modules does not help, I prepared the following for testing:

#!/bin/bash
modprobe -r i2c-hid
modprobe i2c-hid

modprobe -r hid-multitouch
modprobe hid-multitouch

Running this when the scroll lock happens, the lock does NOT get released.
The lock just happened a couple of times to me, left clicking reliably releases me from scroll lock.

[Esokrates (esokrarkose)]

Kai, please tell us what else we could do, I just started working again and the pointer was stuck again after wake up from suspend over night. Which type of debug info would help you?

[Esokrates (esokrarkose)]

Maybe it's coincidence, but I also tried to escape the locks with right clicks but it did not work as reliably as with left clicks. Right clicking most of the time does not change anything, and if, I can move the pointer a few cm and then it locks again. Left clicking helps me to get out of it for a longer period of time most of the time.

[Kai-Heng Feng (kaihengfeng)]

Comment #118 makes the firmware/hardware quite suspicious.

There are comments states Win 10 is also affected.

We already asked Dell/Synaptics to dig deeper on this issue.

[Oh the Huge Manatee (vertesi-n)]

Pardon my lack of faith in Dell, but I'm not expecting much response.

I'm happy to work on this problem myself in the meanwhile. Can you point me to any resources to log inputs below the events layer?

[Kai-Heng Feng (kaihengfeng)]

> On 31 Oct 2017, at 4:41 PM, Oh the Huge Manatee <email address hidden> wrote:
>
> Pardon my lack of faith in Dell, but I'm not expecting much response.
>
> I'm happy to work on this problem myself in the meanwhile. Can you point
> me to any resources to log inputs below the events layer?

You can use "i2c-hid.debug=1” or "i2c-hid.dyndbg=+p” to let i2c-hid prints lots of i2c data.

>
> --
> You received this bug notification because you are subscribed to Dell
> Sputnik.
> https://bugs.launchpad.net/bugs/1651635
>
> Title:
> XPS 13 9360 trackpad locks into scroll mode
>
> Status in Dell Sputnik:
> Confirmed
>
> Bug description:
> Hello,
>
> I'm running Linux on a Dell XPS 13 (9360) laptop.
>
> I find that upwards of 10 times per day, my trackpad gets stuck in
> "scrolling" mode. Moving the trackpad won't move the X windows
> pointer, but will send scrolling events to the foreground window.
>
> When the trackpad is locked in this mode, the touchscreen will still
> let me move the mouse cursor, as will an external mouse.
>
> On Ubuntu 16.04 freshly restored from the Dell recovery image, I find
> that it's often difficult to get the trackpad to recover.
>
> I do find that the issue happens less frequently on Dell's build of
> Ubuntu 16.04 than on other linux distributions and versions, but it
> still happens enough to significantly impact my ability to do
> productive work.
>
> The issue does not occur when running Windows 10 on the same device.
>
> I suspect that the issue may be related to palm detection or
> misdetecting the user's palm as a gesture to enable scrolling mode,
> but have no proof for this.
>
> It seems that I'm often able to reproduce the issue by brushing the
> trackpad with my right palm.
>
> On Ubuntu 16.10, with the latest shipped 4.8 kernel (Linux szx
> 4.8.0-30-generic #32-Ubuntu SMP Fri Dec 2 03:43:27 UTC 2016 x86_64
> x86_64 x86_64 GNU/Linux), with the extra xinput configuration below, I
> am able to get the trackpad to recover, simply by clicking the
> trackpad:
>
> /usr/share/X11/xorg.conf.d/99-libinput.conf:
>
> Section "InputClass"
> Identifier "libinput touchpad catchall"
> Driver "libinput"
> MatchIsTouchpad "on"
> MatchDevicePath "/dev/input/event*"
> Option "Tapping" "True"
> Option "DisableWhileTyping" "True"
> Option "NaturalScrolling" "False"
> Option "AccelProfile" "adaptive"
> Option "AccelSpeed" "0.05"
> Option "MiddleEmulation" "True"
> Option "ScrollMethod" "twofinger"
> # Option "ClickMethod" "clickfinger"
> Option "ClickMethod" "buttonareas"
> EndSection
>
>
> In my experience, the problem manifests using both the Xorg synaptics driver and the Xorg libinput driver.
>
> root@szx:/etc/modprobe.d# xinput list
> ⎡ Virtual core pointer id=2 [master pointer (3)]
> ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
> ⎜ ↳ Logitech M570 id=10 [slave pointer (2)]
> ⎜ ↳ DLL075B:01 06CB:76AF Touchpad id=13 [slave pointer (2)]
> ⎜ ↳ ELAN Touchscreen id=11 [slave pointer (2)]
> ⎣ V...

[Kai-Heng Feng (kaihengfeng)]

Have anyone already filed an upstream bug at https://bugzilla.kernel.org ?

Please file one there, thanks!

[Paul Menzel (paulmenzel)]

@kaihengfeng, I am quite surprised and even angry about your comment.

1. How do you know it’s a Linux kernel issue? Even if it were, the shipped Linux kernel with Ubuntu 16.04 is far too old, and Linux upstream doesn’t care about old Linux kernel.
2. We bought the system from Dell with Ubuntu. As far as I know, they contract Canonical to do the port. That’s the company you work for.
3. So why do you ask the reporters, which wasted too much time already experiencing this bug, to report it, and to test your suggestions to open a bug report upstream. If this is the next step, I kindly ask *you* or some of your colleagues at Canonical to do that.

[Paul Menzel (paulmenzel)]

So, does the touchpad use a firmware, and, if yes, how can the firmware version be queried?

[Kai-Heng Feng (kaihengfeng)]

> On 2 Nov 2017, at 5:40 PM, Paul Menzel <email address hidden> wrote:
>
> @kaihengfeng, I am quite surprised and even angry about your comment.
My apology.

>
> 1. How do you know it’s a Linux kernel issue?
I don’t. But it’s better to get input from upstream maintainer.

> Even if it were, the shipped Linux kernel with Ubuntu 16.04 is far too old, and Linux upstream doesn’t care about old Linux kernel.
It also happens on upstream Linux kernel.

> 2. We bought the system from Dell with Ubuntu. As far as I know, they contract Canonical to do the port. That’s the company you work for.
That’s correct.

> 3. So why do you ask the reporters, which wasted too much time already experiencing this bug, to report it, and to test your suggestions to open a bug report upstream. If this is the next step, I kindly ask *you* or some of your colleagues at Canonical to do that.
Well, I help public issues when I have spare time, this one included. I personally also invested some time trying to reproduce the bug.
Anyway, I’ll file an upstream bug then.

>
> --
> You received this bug notification because you are subscribed to Dell
> Sputnik.
> https://bugs.launchpad.net/bugs/1651635
>
> Title:
> XPS 13 9360 trackpad locks into scroll mode
>
> Status in Dell Sputnik:
> Confirmed
>
> Bug description:
> Hello,
>
> I'm running Linux on a Dell XPS 13 (9360) laptop.
>
> I find that upwards of 10 times per day, my trackpad gets stuck in
> "scrolling" mode. Moving the trackpad won't move the X windows
> pointer, but will send scrolling events to the foreground window.
>
> When the trackpad is locked in this mode, the touchscreen will still
> let me move the mouse cursor, as will an external mouse.
>
> On Ubuntu 16.04 freshly restored from the Dell recovery image, I find
> that it's often difficult to get the trackpad to recover.
>
> I do find that the issue happens less frequently on Dell's build of
> Ubuntu 16.04 than on other linux distributions and versions, but it
> still happens enough to significantly impact my ability to do
> productive work.
>
> The issue does not occur when running Windows 10 on the same device.
>
> I suspect that the issue may be related to palm detection or
> misdetecting the user's palm as a gesture to enable scrolling mode,
> but have no proof for this.
>
> It seems that I'm often able to reproduce the issue by brushing the
> trackpad with my right palm.
>
> On Ubuntu 16.10, with the latest shipped 4.8 kernel (Linux szx
> 4.8.0-30-generic #32-Ubuntu SMP Fri Dec 2 03:43:27 UTC 2016 x86_64
> x86_64 x86_64 GNU/Linux), with the extra xinput configuration below, I
> am able to get the trackpad to recover, simply by clicking the
> trackpad:
>
> /usr/share/X11/xorg.conf.d/99-libinput.conf:
>
> Section "InputClass"
> Identifier "libinput touchpad catchall"
> Driver "libinput"
> MatchIsTouchpad "on"
> MatchDevicePath "/dev/input/event*"
> Option "Tapping" "True"
> Option "DisableWhileTyping" "True"
> Option "NaturalScrolling" "False"
> Option "AccelProfile" "adaptive"
> Option "AccelSpeed" "0.05"
> Option "MiddleEmulation" "True"
> Option ...

[kai.heng.feng (kai.heng.feng-linux-kernel-bugs)]

Users reported [1] trackpad locked into scroll mode, I personally cannot reproduce the issue though.

The issue happens because the trackpad think there's a finger still touched on the touchpad, hence move a single finger on the touchpad will be treated as two fingers scroll.

Also, users reported this commit doesn't fully solve the issue for them:

commit 4f4001bc76fd1a138a501fbd3d68cce72cbf96ce
Author: Benjamin Tissoires <email address hidden>
Date: Thu Jun 15 15:32:04 2017 +0200

    HID: multitouch: fix rare Win 8 cases when the touch up event gets missing

Reload driver (both hid-multitouch and i2c-hid) does not solve the issue. There's still a phantom finger on the touchpad.

[1] https://bugs.launchpad.net/bugs/1651635

[Paul Menzel (paulmenzel)]

On 11/02/17 11:07, Kai-Heng Feng wrote:
>> On 2 Nov 2017, at 5:40 PM, Paul Menzel <email address hidden> wrote:
>>
>> @kaihengfeng, I am quite surprised and even angry about your comment.
> My apology.

No problem. Maybe I also have to apologize for my response directed at you.

>> 1. How do you know it’s a Linux kernel issue?
> I don’t. But it’s better to get input from upstream maintainer.

Thank you for creating that issue. I subscribed myself to it.

>> Even if it were, the shipped Linux kernel with Ubuntu 16.04 is far too old, and Linux upstream doesn’t care about old Linux kernel.
> It also happens on upstream Linux kernel.

Fair enough. Unfortunately, some of the early reporters didn’t report back.

>> 2. We bought the system from Dell with Ubuntu. As far as I know, they contract Canonical to do the port. That’s the company you work for.
> That’s correct.
>
>> 3. So why do you ask the reporters, which wasted too much time already experiencing this bug, to report it, and to test your suggestions to open a bug report upstream. If this is the next step, I kindly ask *you* or some of your colleagues at Canonical to do that.
> Well, I help public issues when I have spare time, this one included. I personally also invested some time trying to reproduce the bug.

Thank you for clearing that up, and thank you for doing this in your
spare time. But, that’s not how it should be. When I bought this laptop,
I thought a certain amount of that price goes to “Dell’s GNU/Linux team”
and Canonical, so that people are paid to look into issues. I’d love to
hear more about the relationship between Dell and Canonical, and what
the support includes.

With Dell it’s hard enough to deal with their support, which always
responds that they cannot really help, when GNU/Linux (Ubuntu) is used.

> Anyway, I’ll file an upstream bug then.

Thank you gain.

[Esokrates (esokrarkose)]

The thing that makes this bug so annoying for me is that sometimes I do not experience it for weeks and suddenly it appears and does not stop but in the end stops again as unexpected as it started. This bug is clearly non deterministic.

I even managed to find a way to reproduce it, but only under cirumstances when the touchpad is "in the mood" to be affected by this bug. I wasted a lot of time filming this, when I have time I will upload it on youtube.

Still, Kai is there a firmware for the touchpad?

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Clicking releases from scroll lock, but most of the times only temporary, meaning a few seconds later it locks again.

In the end its stops happening suddenly to return at a later point.

This issue is NOT reproducible, it sometimes stays away from me for weeks and then it hits me and makes using the touchpad almost impossible. Sometimes it happends everyday.

Please do not use the machine for a few hours and then say everything is fine because you did not see it. The issue is definitely there for all kernels <= 4.13, I have two machines, on both I experience this issue and there are other users who see the same issue, see [1].

[1] https://bugs.launchpad.net/bugs/1651635

[Oh the Huge Manatee (vertesi-n)]

Thank you for the pointer to debug mode in i2c_hid. Here's a log of it happening. I am not touching the touchpad at all. At the end I do a single, hard left click to end the episode.

I don't know how to interpret the input (yet), but I will look it up. Hope this is helpful.

Also FWIW I agree with @kai - this belongs in an upstream issue, really. It happens on my generic kernel. When we get an issue opened there, I'm happy to cross post as necessary.

Nov 2 12:27:18 simba kernel: [196169.000701] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3d 92 01 00
Nov 2 12:27:18 simba kernel: [196169.007873] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 84 92 01 00
Nov 2 12:27:18 simba kernel: [196169.014979] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cb 92 01 00
Nov 2 12:27:18 simba kernel: [196169.022019] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 93 01 00
Nov 2 12:27:18 simba kernel: [196169.029205] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 59 93 01 00
Nov 2 12:27:18 simba kernel: [196169.036144] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0 93 01 00
Nov 2 12:27:18 simba kernel: [196169.043416] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e7 93 01 00
Nov 2 12:27:18 simba kernel: [196169.050452] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2e 94 01 00
Nov 2 12:27:18 simba kernel: [196169.057508] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 94 01 00
Nov 2 12:27:18 simba kernel: [196169.064610] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bd 94 01 00
Nov 2 12:27:18 simba kernel: [196169.071651] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 95 01 00
Nov 2 12:27:18 simba kernel: [196169.078748] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4b 95 01 00
Nov 2 12:27:18 simba kernel: [196169.086108] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 93 95 01 00
Nov 2 12:27:18 simba kernel: [196169.093125] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 da 95 01 00
Nov 2 12:27:18 simba kernel: [196169.100075] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 21 96 01 00
Nov 2 12:27:18 simba kernel: [196169.107278] i2c_hid i2c-DLL075B:01: input: 20 00 03 02 99 04 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0...

[Mario Limonciello (superm1)]

> So, does the touchpad use a firmware, and, if yes, how can the firmware version be queried?
All touchpads have firmware, this one is no different. You can read the HID descriptor as described in the HID over I2C protocol specification. As described in the specification the firmware version is encoded in byte offset 24.

For this particular issue, this information is not useful however because the firmware for the XPS 9360 touchpad is unchanged since it's been on the market.

[benjamin.tissoires (benjamin.tissoires-linux-kernel-bugs)]

Thanks for raising this issue. I currently have a Dell XPS 9360 as a loaner so the timing is perfect. I haven't used it enough to trigger the issue on a vanilla kernel however.

Given that the scroll lock happens even if the hid-multitouch and i2c-hid modules are removed and re-added, I would *think* the issue is in user space, not in kernel space. The reason is that the last data in comment #110 show that the kernel is behaving properly by rejecting the ghost touches on my system if I replay the data.

Once the bug is triggered, could you ask the user who triggered it to rmmod i2c-hid and modprobe it back with debug=1, and attach the output of dmesg here? This should show the exact starting sequence of the bug, and we will be able to rule out if it is a kernel or a user space issue.

[Mario Limonciello (superm1)]

FYI for those who are not subscribed to the issue filed to the kernel bugzilla:
Benjamin T. suspects this may be a userspace issue, not a kernel issue.

When someone reproduces this again please do the following:
1) # sudo rmmod i2c-hid
2) # sudo modprobe i2c-hid debug=1
3) Capture dmesg output at this time with the issue reproduces

Please upload that dmesg data to the kernel bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=197683).

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Created attachment 260527
Scroll lock that vanishes very fast

My touchpad is in the state again that I can trigger the bug deliberately, but not a really nasty lock, only for a few seconds.

I started to load the module with debug mode, started scrolling with two fingers, released one finger and it kept scrolling. I even removed the finger touched again to move the cursor but it still was in scroll mode. The issue resolved itself again without any click.

Hope you can find something in there, at the moment the locks only last very shortly for me.

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Created attachment 260545
kern.log from events in the video

The touchpad started misbehaving again, but not as badly as it could be.
I started to film the problem, see

https://www.youtube.com/watch?v=HpAWC8imIcc

In the video I first show off the scroll lock happening, then I run a script that reloads the i2c-hid module with debug info and shows a timestamp every second, for you to get a better understanding of what happened at which point in time in the attached kern.log file.

You can also see the mouse cursor jumping at 0:50.

[benjamin.tissoires (benjamin.tissoires-linux-kernel-bugs)]

Thanks for both logs and the video. This makes things easier to see and understand.

The first log did show a ghost touch on the upper right corner of the touchpad, but I wasn't sure if you accidentally touched this part of the touchpad or not. With the video, I can see that you are only using one finger on the touchpad, and that the touch that regularly appears on the top right corner is a ghost one.

As far as I can tell, there is no (simple) way from the drier to ignore those. The firmware marks those touches are valid, and it would require far too much processing to eliminate them directly from the driver.

On the 9360 I have been loaned, I do not see such ghosts. Gnome software says that my bios is 0.1.3.5 and that there is an update to 0.2.3.1. Which Bios are you? There might have been an upgrade of the touchpad that broke it. If you do not have gnome-software with fwupd, you can just run "sudo dmidecode -s bios-version" to get the version.

[benjamin.tissoires (benjamin.tissoires-linux-kernel-bugs)]

Created attachment 260547
recording from the video, in the hid-replay format

Just so I do not lose it later, here is the converted data I extracted from the second dmesg. You can replay the data and parse it into a human readable format with https://github.com/bentiss/hid-replay

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

I am using bios 2.2.1. I have seen this issue in different bios versions.

Comment #131 in launchpad says:

"For this particular issue, this information is not useful however because the firmware for the XPS 9360 touchpad is unchanged since it's been on the market."

So I guess the bios version is not relevant!?

I am sure you are having the issue too, it just takes time to see it. When you use the 9360 as your daily driver you will see the issue for sure. It could take a few weeks to first happen, but it does happen unfortunately :-(.

I am speaking out of experience. There can be a long time where the touchpad behaves perfectly and suddenly it goes crazy.

Thanks very much for looking into this. Anything more we could do!?

[campbell (campbell-linux-kernel-bugs)]

@Benjamin thank you for your help on this issue! Your patches to hid have made you a bit of a hero to people with this issue, so I'm just excited to post on a thread with you. :)

I am using bios version 1.3.5 with the same problem (I'm the one who provided the event dumps in the launchpad thread).

I'm currently of the mindset that this is a hardware issue. The last week or so, I've been "curing" my attacks with firm pressure on the space between the trackpad and the space bar. Firm enough to risk a physical click on the touchpad. This seems to solve the episodes for a longer time than my previous method (hard physical click on the right side of the touchpad).

That said, it's only been a week. I've thought I've had a solution before.

Looking at a disassembly of the laptop ( https://www.parts-people.com/blog/wp-content/uploads/2016/12/xps9350touchpadconnector.jpg ) though, I don't see what I could be pressing on. The touchpad connetor is in the middle of the touchpad. Maybe one of the pads that holds it in place is a little too far over and generating a click? I always thought touchpads worked with capacitance though, and it would be a pretty dumb material choice for padding if it changes apparent capacitance where it touches the trackpad. Also, that wouldn't explain the "flickering" effect.

I second Esokrarkose's comment - try using the laptop as a daily driver. I'm sure you'll run into the issue eventually. It very rarely occurs when I start using the machine, usually it pops up over time.

[benjamin.tissoires (benjamin.tissoires-linux-kernel-bugs)]

Right. So if Windows is immune to this problem, there must be some sort of palm rejection mechanism in user space that prevents it to see the issue. I'll check with Peter Hutterer if this is something doable.

[benjamin.tissoires (benjamin.tissoires-linux-kernel-bugs)]

Answer from Peter: https://bugs.freedesktop.org/show_bug.cgi?id=103208
Once this bug is fixed in libinput, you should be fine. But note that this is a firmware issue still :)

[kai.heng.feng (kai.heng.feng-linux-kernel-bugs)]

Some users reported that Windows is also affected [1] in comment #3, #21.

[1] https://bugs.launchpad.net/bugs/1651635

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Regarding Windows being affected: I did some research, but nowhere outside of the launchpad page I could find someone confirming it is an issue there too and I guess there are much more XPS 13 Windows users out there than linux users, but since it is an firmware issue I guess the two comments may be right, still I am a bit surprised it was not mentioned somewhere outside the linux userers world, maybe it's less likely to appear there?

Mario Limonciello from Dell is subscribed here, maybe he could comment whether it is likely that a firmware update is issued?

Benjamin Tissoires: Shall I keep recording the issue to find out if it's always the upper right corner where the ghost touches are coming from?

[peter.hutterer (peter.hutterer-linux-kernel-bugs)]

can you get me an evemu-record output for the ghost touch please? Is it always in the same spot, or roughly the same spot?

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

When it happens again and I have the time I will upload the evemu-record along with the other debug info.

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Created attachment 260565
kern log of the stuck pointer in the video

Touchpad got stuck, the pointer locked completely, I remember dragging one finger from outside the upper right corner to the touchpad when the pointer got stuck. Then I started recording the video:

https://youtu.be/GXw0MVjbn2w

As last time, the script I run reloaded the kernel module with debug info, as can be seen, the pointer was still stuck. The lock was released in 0:51, when I pressed the right button, as can be heard in the video.

The evemu-record will be attached in the next comment.

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Created attachment 260567
evemu-record output of video, as requested

evemu-record output of https://youtu.be/GXw0MVjbn2w

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Created attachment 260569
kern log of right corner triggering

As you told me the upper right corner might trigger this I played around and found I could trigger misbehavior by playing around a bit (but this only works sometimes, not always). I recorded that experience once again:

https://youtu.be/gEYBBP_6Yr0

Right now as I am typing the touchpad is also misbehaving, but I do not have unlimited time to record all the time. I can't tell if it's always related to the upper right corner.

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Created attachment 260571
evemu-record of upper right corner triggering

evemu-record of https://www.youtube.com/watch?v=gEYBBP_6Yr0

If you need snapshots of the evemu-record.log my script took every second to diff what happened at every second in the video let me know. Also available for the prior evemu-record.

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Created attachment 260573
lower corner kern.log

One last time, triggering scroll lock with right lower corner and then with the right upper corner.

Watch closely: In the beginning I trigger a scroll lock with the lower corner.

https://youtu.be/_O6BJQYYY7c

Sometimes though the scroll locking happens although I do not remember getting near a corner, at least I think so, I am not sure.

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Created attachment 260575
lower corner evemu recording

Corresponding evemu recording for https://youtu.be/_O6BJQYYY7c.

[superm1 (superm1-linux-kernel-bugs)]

A few clarification points and thoughts:

1) On the Windows side there is no extra Synaptics driver doing any palm rejection. Windows uses the inbox HID driver. Anything handled in this area would be entirely with the built-in Windows software stack.

2) There haven't been any touchpad firmware updates for the XPS 9360 since launch.

3) Upgrading system firmware (BIOS) I don't believe should have any bearing on this particular issue. I know BIOS update flashes a lot of components, but touchpad is not one of them.

>Mario Limonciello from Dell is subscribed here, maybe he could comment
>>whether it is likely that a firmware update is issued?

As of right now there aren't any touchpad firmware updates in the works.

Although there could be some potential improvements to palm rejection handling in libinput as mentioned above, I'm highly suspicious of a few pieces of defective hardware for those afflicted by this annoying issue. And yes I know that one person on Launchpad mentioned they had TP replaced but issue came back, but it could still be a defective replacement too.

@esokrarkose, since you seem to be able to readily reproduce on your piece of hardware I think it would be ideal if you could set up a dual boot or a Windows to go USB stick (If you have access) that you can experiment with Windows 10's inbox driver. If you can still reproduce problems there I'm going to go on a limb and say it really is defective hardware and not something that should be bandaged by libinput to look for the ghost touches.

Evidence of it happening in both places should make a pretty strong case for repair.

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

"a few pieces of defective hardware for those afflicted by this annoying issue"

That comment is making me quite angry. I am not wasting a lot of time so that it gets rejected by saying: this only affects a few pieces of hardware implying it is not relevant. I spent money for two pieces of this hardware manufactured at different dates (more than a month inbetween) and both have the issue.

Paul Menzel also subscribed to this issue has colleagues with the same problem. One person got a replacement and the issue was still there. A very very unlikely coincidence, isn't it? It's likely that MOST of the touchpads are broken then, if you do not believe that all are affected.

When I have more time I will have a look at Windows, but I have already wasted too much time with that, I do not expect such problems for that price tag.

[superm1 (superm1-linux-kernel-bugs)]

I'm sorry, but I don't have statistics to show number of calls related to touchpad relative to units sold. I don't work in the Dell support organization. I'm trying to add to this issue context that will help get down to a root cause.

My suspicion in it being defective hardware is colored by the fact that I've used both an XPS 9350 and XPS 9360 daily (Which each contain Synaptics I2C TP) for a while now and never experienced this issue myself and know dozens of others who have as well.

As you mentioned: it's also suspicious that a handful of people have the problem, they seem to all be on Linux, and they have congregated on a Launchpad bug. This is the internet, people with similar views, similar problems flock to the same place.

Even if it's defective hardware i'm not saying it can't be helped by libinput adjustments. I'm saying the surface area of afflicted people (appears) small so a hardware problem is a potential root cause and repair may be the quickest solution.

[peter.hutterer (peter.hutterer-linux-kernel-bugs)]

looking at the logs in attachment 260547:
* the ghost touch starts at 1216/0 (xmax/ymin) and is constant
* at 875.329542 it is at 1192/14
* It later *moves* to 1185/18 over several events and stays there. This pattern repeats multiple times

The highest distance from the edge is 1185 and 20, so roughly 3 and 2 mm, respectively. Note: this is from a manual analysis, not a scripted one so I may have missed a value. I'm assuming the others are the same, because in the end they can only be worse, if they're better than the above that's great ;)

For userspace this means:
* there isn't a single coordinate that we can blacklist
* we need some heuristics beyond 'maximum edge of the touchpad' because 3/2mm is a significant distance in. that heuristic runs the danger of interfering with real touches
* we can't just look at a touch and ignore it when it doesn't move - some of them move. Although it looks like they move late enough that we can pick them out before that happens.

Either way, the above would definitely require a model-specific quirk because we don't want to affect other devices. I wouldn't be surprised if windows papers over this accidentally, in the same way as the bug linked in comment 10 would probably paper over this. The windows bit is a guess though.

I'm going with Mario here and suspect this is defective hardware. If every XPS user would have this issue it'd be a different matter but fixing this has a nonzero cost for userspace.

[campbell (campbell-linux-kernel-bugs)]

Voicing my experience here - as someone who thinks it's a hardware issue... I dual boot this machine and play games on the Windows side. I've never had it appear in Windows 10. Also, the couple of comments in Launchpad are the only reports I can find _anywhere on the Internet_ of it happening in Win.

There are many reports from users who have had the touchpad replaced, or reseated. They think it's OK for a week or two, then it returns. I've even read threads from people who have gone through 3 or more replacements this way. :(

I'm inclined to think it's something that the windows driver accidentally papers over. Is the touchpad size detection in Win the same? Is there potentially a small dead zone around the outside, or are we potentially detecting a larger surface than exists?

[peter.hutterer (peter.hutterer-linux-kernel-bugs)]

> Is there potentially a small dead zone around the outside, or are we
> potentially detecting a larger surface than exists?

Thats quite easy to verify, just run the touchpad-edge-detector tool

[campbell (campbell-linux-kernel-bugs)]

I used the measurement from Dell's specs on their website for my service tag number.

```
sudo touchpad-edge-detector 105x60 /dev/input/event16

Touchpad DLL075B:01 06CB:76AF Touchpad on /dev/input/event16
Move one finger around the touchpad to detect the actual edges
Kernel says: x [0..1216], y [0..680]
Touchpad sends: x [3..1216], y [0..680] -|-| \^C

Touchpad size as listed by the kernel: 101x56mm
User-specified touchpad size: 105x60mm
Calculated ranges: 1213/680

Suggested udev rule:
# <Laptop model description goes here>
evdev:name:DLL075B:01 06CB:76AF Touchpad:dmi:bvnDellInc.:bvr1.3.5:bd05/08/2017:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn06CC14:rvrA00:cvnDellInc.:ct9:cvr:*
 EVDEV_ABS_00=3:1216:12
 EVDEV_ABS_01=0:680:11
 EVDEV_ABS_35=3:1216:12
 EVDEV_ABS_36=0:680:11
```

Looks like the kernel expected a smaller device. Not sure what to make of that, but I'll give it a try and report back! This week has been pretty calm for me as far as this problem goes, so I'd be interested to see the output/effect of touchpad-edge-detector settings from someone else...

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

It takes a while until it matches what Kernel and Touchpad say, but here it is:

sudo touchpad-edge-detector 105x60 /dev/input/event10
Touchpad DLL075B:01 06CB:76AF Touchpad on /dev/input/event10
Move one finger around the touchpad to detect the actual edges
Kernel says: x [0..1216], y [0..680]
Touchpad sends: x [0..1216], y [0..680] \^C\\|

Touchpad size as listed by the kernel: 101x56mm
User-specified touchpad size: 105x60mm
Calculated ranges: 1216/680

Suggested udev rule:
# <Laptop model description goes here>
evdev:name:DLL075B:01 06CB:76AF Touchpad:dmi:bvnDellInc.:bvr2.2.1:bd08/18/2017:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn05JK94:rvrA00:cvnDellInc.:ct9:cvr:*
 EVDEV_ABS_00=0:1216:12
 EVDEV_ABS_01=0:680:11
 EVDEV_ABS_35=0:1216:12
 EVDEV_ABS_36=0:680:11

[pmenzel+bugzilla.kernel.org (pmenzel+bugzilla.kernel.org-linux-kernel-bugs)]

(In reply to Esokrarkose from comment #22)
> "a few pieces of defective hardware for those afflicted by this annoying
> issue"
>
> That comment is making me quite angry. I am not wasting a lot of time so
> that it gets rejected by saying: this only affects a few pieces of hardware
> implying it is not relevant. I spent money for two pieces of this hardware
> manufactured at different dates (more than a month inbetween) and both have
> the issue.
>
> Paul Menzel also subscribed to this issue has colleagues with the same
> problem.

Just a clarification, that we couldn’t reproduce the issue in Microsoft Windows 10 (we reluctantly installed and took some time). After that, we were not able to reproduce it with an Ubuntu installation anymore.

> When I have more time I will have a look at Windows, but I have already
> wasted too much time with that, I do not expect such problems for that price
> tag.

I totally agree, that Dell’s QA failed big time. But please try to reproduce the issue with Microsoft Windows, and to try to get a replacement for both devices.

[superm1 (superm1-linux-kernel-bugs)]

FWIW, touchpad-edge-detector recommends the exact same values on the XPS 9350 as the values recommended by comment #28 and comment #27.
evdev:name:DLL0704:01 06CB:76AE

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

"Just a clarification, that we couldn’t reproduce the issue in Microsoft Windows 10 (we reluctantly installed and took some time). After that, we were not able to reproduce it with an Ubuntu installation anymore."

Right, ok then you still have the issue, it will return eventually, because it wasn't fixed magically.

Yesterday and by the start of today the issue was bugging me extremly, now its all of the sudden gone, I can't trigger it, no matter how hard I try, even the right upper and lower edges behave correctly. There was no reboot inbetween just a couple of suspends.

It's extremely frustrating to convince you guys, but at the end of the day that touchpad is simply unreliable, there is definitely an issue and it will return at a random point.

I mean I'm okay with changing the touchpad, I would even request the guys from Dell to do so, but I am 100% certain, that the problem will return.

I am frustrated, because if I would carry my computer to you guys and try to show the problem it wouldn't work instantly almost certainly. If you would spend a day with me, I could show you when it happens just like in the video. I am sure the same would happen to me when Mario would give me his XPS 13 model. Maybe it's related to usage pattern!?

[peter.hutterer (peter.hutterer-linux-kernel-bugs)]

(In reply to Campbell Vertesi from comment #27)
> Looks like the kernel expected a smaller device.

Rounding error, not to worry about. Kernel provides the resolution in
units/mm as integer, but your touchpad has 11.58 u/mm. Rounding up the
resolution to 12 results in a perceived smaller size (101 vs 105mm). This
doesn't usually matter unless it's out by some significant amount.

[superm1 (superm1-linux-kernel-bugs)]

??Hello,
I will be out of office 11/10 returning 11/13. Expect delayed email responses.

[campbell (campbell-linux-kernel-bugs)]

Thanks @Peter for the explanation.

@Esokrarkose the next time this happens to you.. could you please try putting pressure on some other parts of the case, and see if that resolves it for you? I've found that firm pressure in the space between the trackpad and the space bar resolves it for me. Can you replicate?

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Damn, pressing on the case between the right corner and "Alt Gr" triggered the issue. When moving the finger on the case with pressure (not touching the touchpad) the mouse pointer sometimes moves very slightly :-(.

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Windows 10 also affected. It behaves a little bit better, but I could reproduce the jumping and the lock.

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

Can others who have the same issue verify that their models have a weak spot on the case between upper right corner and "Alt Gr" key and pressing there makes the trackpad go mad?

Campbell, when was your system manufactured, can you also trigger the issue pressing on the spot I suggest?

Mario, could you somehow help me convince support that it's been verified that a swap is justified in my case? All the stuff they want me to try is obviously just a waste of time.

[harald.oberhofer (harald.oberhofer-linux-kernel-bugs)]

(In reply to Esokrarkose from comment #37)

Hi I have an XPS 13 9360 with the touchpad issue but do not have such a weak spot. Pressing the case between upper right corner and the right Alt key doesn't do a thing.

[campbell (campbell-linux-kernel-bugs)]

Well, it sucks to discover it's a hardware issue for sure. :(

I bought my system in June 2017. Service tag # C3L06H2 so you can look up the specs :)

I don't have a particular weak spot between the trackpad and the right alt key. I can press anywhere above the trackpad and it ends an episode, but I can't seem to trigger an episode that way. I'm continuing to experiment with different spots on the below-keyboard part of the case to see if I can figure out a pattern.

Given that it seems very forgiving about precisely where I press, right now my theory is a charge buildup from improper grounding somewhere.

Further discussion of this really doesn't belong on the kernel bugzilla, but I don't know where else to do it. Is it OK if we continue debugging the issue in this thread?

[superm1 (superm1-linux-kernel-bugs)]

I'm curious to hear, anyone affected who has used the output from touchpad-edge-detector, did you have any positive results?

I believe that's the only potential software change on the table right now as an outcome of this bug. We should probably close it after deciding that.

@esokrakose, Campbell (and any others that this is looking like a HW issue):
Regarding where to take this discussion of a potential HW issue:
You can bring it to the Dell project sputnik forums to openly discuss as a group: http://en.community.dell.com/techcenter/os-applications/f/4613

If you're having a hard time with the phone support group, I'm sorry about that. I talked to one of our web support guys and pre-wired them on the situation going on. You can join the Dell forums and send him a friend request with your service tag through his profile:
http://en.community.dell.com/members/dell_2d00_justin-c

[James D. (jamesd603)]

I JUST started getting this bug with a firmware update pushed to me by Ubuntu 17.10. Never had this problem until now. So annoying. I'm on the Dell 9360 too.

[James D. (jamesd603)]

I downgraded the BIOS and it seems to have helped but still get glitches. Drives me mad.

[Oh the Huge Manatee (vertesi-n)]

@James - Likely it had nothing to do with the firmware update. Have a look at the linked Ubuntu thread... many of us have been through exactly what you're going through now. Make a change, seems to help, 2 days later it's back. Please try some of the suggested solutions we've listed here: firm pressure on various parts of the lower case seems to resolve it for days at a time, for some people.

As far as we can tell, there is no software or firmware fix possible for this issue.

[Oh the Huge Manatee (vertesi-n)]

whoops, I meant the linked kernel.org thread. :)

[James D. (jamesd603)]

I'm sending it back to dell then...

[James D. (jamesd603)]

I'm not convinced it's hardware related, booted with 16.04.3 , going to use it until tonight.

[James D. (jamesd603)]

Solid hour so far , zero problems. Usually the problem would have already happened on 17.10. I believe there is a bug, that's not to say some people don't have a hardware issue, it doesn't seem to apply in my case. I'm rolling my install on this notebook back to 16.04 lts and I will report back if it happens again, if nobody hears from me in days or weeks, it means moving back to 16 resolved my problem.

[James D. (jamesd603)]

Haha, ok ok. Recreated it in 16.04 by applying pressure to the trackpad with my palm. It seems better now on both versions but I do suspect a hw issue. Dell is coming out to replace it under warranty. Hoping it's not a design flaw that impacts all touchpads ,, or maybe they have a newer revision of trackpad because of this issue. that'd be nice.

[Launchpad Janitor (janitor)]

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

[Esokrates (esokrarkose)]

Got my touchpad replaced in November, I have never seen this issue again, Dell support on twitter is amazing btw.

[Esokrarkose (esokrarkose-linux-kernel-bugs)]

This can be closed, it is indeed a hardware issue. Got my touchpad replaced in November and I have never experienced this again ever since. Also the Dell support guys on twitter are amazing!

[fermulator (fermulator)]

fwiw, I too experience this issue on Dell LATITUDE E4310

$ cat /etc/issue
Linux Mint 18.3 Sylvia \n \l

$ uname -a
Linux fermmy-notebook 4.13.0-38-generic #43~16.04.1-Ubuntu SMP Wed Mar 14 17:48:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

--
since this has been closed as "invalid", is this to mean that everyone has concluded it is a hardware issue? - is there any workaround in software? (my notebook is definitely past warranty period...)

[fermulator (fermulator)]

(PS: as per typical recommendations, I have submitted a unique bug report for my specific system https://bugs.launchpad.net/dell-sputnik/+bug/1763968)

[André (andre-miras)]

It's been over a year that I have this Dell XPS 13 9360. And this touchpad `DLL075B:01 06CB:76AF` with the same issue. I had this issue with both touchscreen enabled and disabled in the BIOS.
I'm currently on 18.04 and kernel 5.0.0-25-generic.
For my case this issue happens most often soon after unplugging the laptop from power supply. Usually closing the laptop lid and reopening helps to peace the issue slightly when coming back to suspend. Another thing that helps is nuking the touchpad specially right click. I wish modprobing would help too.
Also both scroll lock and mouse jumping around issues happens.

[Paul Menzel (paulmenzel)]

@andre-miras, we do not experience the problem with Ubuntu 18.10(?) and 19.04 anymore. Please try to update, or test these releases. No idea, what the cause and solution was in the end.

[Andreas Scherbaum (ads-launchpad)]

I'm affected by this bug. My laptop is a relatively new Lenovo X1.
OS is Ubuntu 19.10, kernel is 5.3.0-29-generic (both with all upgrades), all available firmware upgrades are installed (using fwupdmgr).

Occasionally my touchpad stops working after resume from sleep. I have to boot the laptop, and 100% of the times when I boot the laptop without power adapter plugged in, the problem reappears and the touchpad is not usable after reboot. The following error messages appears in the logfile:

Feb 1 10:05:52 diamond kernel: [ 23.628092] i2c_designware i2c_designware.1: controller timed out
Feb 1 10:05:53 diamond kernel: [ 24.651920] i2c_designware i2c_designware.1: controller timed out
Feb 1 10:05:54 diamond kernel: [ 25.675991] i2c_designware i2c_designware.1: controller timed out

One message per second - which by itself is too much, because it generates I/O activity all the time.

If I plugin the power cord and reboot, the touchpad is working again.

[Paul Menzel (paulmenzel)]

@ads-launchpad, that looks like a separate issue. Please make a new report (especially as this is in the project(?)/category(?) *dell-sputnik* in Launchpad, and also upstream.

[Andreas Scherbaum (ads-launchpad)]

@paulmenzel This very much looks like the same or at least a similar issue.

Same error messages from i2c, same symptoms with the touchpad. The only difference is that it's not a Dell - but this does not mean that the same software can't be affected.

[Mario Limonciello (superm1)]

I have to agree with Paul. This is a separate issue.

Issues like this often have a firmware component (such as the BIOS ACPI primitives or touchpad firmware). Even if the messages are the same I wouldn't categorize the error messages from another identically with the problems from this specific system.