XPS 13 9360 trackpad locks into scroll mode

Bug #1651635 reported by Jesse on 2016-12-21
92
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Dell Sputnik
Undecided
Unassigned
Linux
Unknown
Unknown
linux (Ubuntu)
Undecided
Unassigned

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)]
⎣ 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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

@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) wrote :

@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) wrote :

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

alex zhang (alex.zhang) wrote :

@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) wrote :

Alex,

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

alex zhang (alex.zhang) wrote :

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) wrote :

@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) wrote :

@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) wrote :

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) wrote :

@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) wrote :

@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) wrote :

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) wrote :

@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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Grant (grantsewell) wrote :

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) wrote :

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) wrote :

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

Paul Menzel (paulmenzel) wrote :

@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) wrote :

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

Grant (grantsewell) wrote :

@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) wrote :

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

Amnon Yekutieli (amyekut) wrote :

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) wrote :

@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) wrote :

@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) wrote :

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

Amnon Yekutieli (amyekut) wrote :

@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) wrote :

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

Amnon Yekutieli (amyekut) wrote :

@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?

Grant (grantsewell) on 2017-06-18
Changed in dell-sputnik:
status: New → Invalid
Grant (grantsewell) on 2017-06-19
Changed in dell-sputnik:
status: Invalid → New
Esokrates (esokrarkose) on 2017-09-19
Changed in dell-sputnik:
status: New → Confirmed
69 comments hidden view all 149 comments
Download full text (12.2 KiB)

@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...

Attaching my terminal session. Seems to work now.

Kai-Heng Feng (kaihengfeng) wrote :

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

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.

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) wrote :

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

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.

Download full text (16.9 KiB)

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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?

Download full text (4.1 KiB)

> 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...

Read more...

Kai-Heng Feng (kaihengfeng) wrote :

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

Please file one there, thanks!

Paul Menzel (paulmenzel) wrote :

@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) wrote :

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

Kai-Heng Feng (kaihengfeng) wrote :
Download full text (4.8 KiB)

> 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 ...

Read more...

Paul Menzel (paulmenzel) wrote :

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) wrote :

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?

Download full text (44.2 KiB)

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) wrote :

> 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.

Mario Limonciello (superm1) wrote :

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).

James D. (jamesd603) wrote :

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.

5 comments hidden view all 149 comments
James D. (jamesd603) wrote :

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

@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.

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

James D. (jamesd603) wrote :

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

James D. (jamesd603) wrote :

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

James D. (jamesd603) wrote :

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) wrote :

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) wrote :

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

Changed in linux (Ubuntu):
status: New → Confirmed
Esokrates (esokrarkose) wrote :

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

Changed in dell-sputnik:
status: Confirmed → Invalid
Changed in linux (Ubuntu):
status: Confirmed → Invalid
fermulator (fermulator) wrote :

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) wrote :

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

Displaying first 40 and last 40 comments. View all 149 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.