Bug 214597

Hello,

any chance that someone stumbling upon this can take a look?

Thanks!

Hello Andrea Ippolito,


I have been following you for some time, I have seen all the topics you have opened regarding this problem. I wanted to share with you an idea that came to my mind. I saw that there is a xps 9310 (new xps 13) in developer edition, that is to say, delivered with ubuntu. It could be that the touchpad's driver of this one is fully functional with linux. Do you think we can take this driver for our machines?


Thank you and good luck to us


link : https://www.notebookcheck.net/Dell-XPS-13-9310-and-XPS-13-9310-Developer-Edition-get-customary-Intel-Tiger-Lake-upgrades-and-Thunderbolt-4-connectivity.496096.0.html

(In reply to abduss from comment #2)
> Hello Andrea Ippolito,
> 
> 
> I have been following you for some time, I have seen all the topics you have
> opened regarding this problem. I wanted to share with you an idea that came
> to my mind. I saw that there is a xps 9310 (new xps 13) in developer
> edition, that is to say, delivered with ubuntu. It could be that the
> touchpad's driver of this one is fully functional with linux. Do you think
> we can take this driver for our machines?
> 
> 
> Thank you and good luck to us
> 
> 
> link :
> https://www.notebookcheck.net/Dell-XPS-13-9310-and-XPS-13-9310-Developer-
> Edition-get-customary-Intel-Tiger-Lake-upgrades-and-Thunderbolt-4-
> connectivity.496096.0.html

Hello abduss,

I guess I'm gonna become famous on the Internet because of how many threads I opened about this issue (be it on libinput issue tracker, Dell support forums, reddit, etc...) :D

Unfortunately I'm not tech-savvy when it comes to linux development, not to mention internals like kernel and driver. So all I'm really doing is trying to facilitate the gathering of useful information from the user community that could help move forward with the resolution of this problem.

I think that the info you shared might be useful to whoever will eventually take a look at this bugreport. That is, assuming the internals of that XPS 9310 are the same as those found inside the DELL laptops sold with Windows on which we are currently facing the issue.

Issue is still reproducible with:

5.15.7-1-default

On opensuse Tumbleweed.

Still a problem on several Linux distros. I tested on Ubuntu 20.04, 22.04-beta, Manjaro, Fedora,  Kernel 5.11.0-43-generic, 5.13.0-19-generic.   It makes many models of Dell XPS Tiger Lake laptops almost unusable.

Wanted to note that I'm having this issue as well (Fedora 35, 5.15.11-200.fc35.x86_64). 

Hoping this thread will get some attention because this issue is very bothersome and renders the laptop difficult to use when it occurs.

Raising Importance to High as this is disrupting a fundamental input device for mobile computing.

Thanks! I tried killing, or killing and restarting as many hid related kernel modules as I could, hoping to find a command I could run to fix the problem as it appeared.  No success.

I also wanted to raise this issue as something I'm experiencing on Ubuntu 20.04, on a Dell XPS 9510 - hope this helps give this bug some more attention!

I've got what seems to be an identical problem but on Dell Inspiron 5515 with AMD Ryzen 5 5500U so I don't think it is limited to Intel platform. It doesn't matter if libinput or synaptic is used. I've never experienced the issue with Windows.

andrea@inspiron:~> cat /proc/bus/input/devices | grep "Touchpad" 

N: Name="DELL0A86:00 04F3:3185 Touchpad"

But I've seen also:
DELL0A5D:00 04F3:311C

(In reply to Andrea Ippolito from comment #11)
> andrea@inspiron:~> cat /proc/bus/input/devices | grep "Touchpad" 
> 
> N: Name="DELL0A86:00 04F3:3185 Touchpad"
> 
> But I've seen also:
> DELL0A5D:00 04F3:311C

I have it different:
DELL0A78:00 27C6:0D42 Touchpad

but from an online searches I would say the problem concerns variety of Dell laptops, Inspiron and XPS series at least.

I would like to confirm everyone's findings here (intermittent slowdown), happening on Ubuntu 21.10 with kernel 5.13.0-22-generic.


cat /proc/bus/input/devices | grep "Touchpad
returns DELL0A5D:00 04F3:311C Touchpad"

I would like to confirm everyone's findings here (intermittent slowdown), happening on Ubuntu 21.10 with kernel 5.13.0-22-generic.


cat /proc/bus/input/devices | grep "Touchpad
returns DELL0A5D:00 04F3:311C Touchpad"

I have the same problem with my ASUS ZenBook 14 :(
ASUE140A:00 04F3:3134 (Elantech touchpad)

Please fix the problem :( it spoils the mood of working

I have the same problem with my ASUS ZenBook 14 :(
ASUE140A:00 04F3:3134 (Elantech touchpad)

Please fix the problem :( it spoils the mood of working

Echoing the thoughts in comment #2. Would be very interested in seeing the differences between the Ubuntu shipped with Dell XPS Developer (software or hardware) and other machines having this problem.


 cat /proc/bus/input/devices | grep "Touchpad"
 N: Name="DELL097D:00 04F3:311C Touchpad"

Is this problem being worked on?
Just recently got a new XPS 15 9510, when touchpad lag sets in, it is really hard to use :(

cat /proc/bus/input/devices | grep "Touchpad"
N: Name="DLL0945:00 04F3:311C Touchpad"

For those with the 9710 (and probably 9510), a new firmware update has been released:

https://www.dell.com/support/home/en-us/product-support/product/xps-17-9710-laptop/drivers

Can all those affected test with 1.7.2 and get back?  Anecdotally I feel like the sluggishness *may* have been reduced.

After additional testing with kernel 5.16.13 on Ubuntu 21.10, the problem still persists with firmware 1.7.2, with no improvement whatsoever.

enigma@Melchior:~$ cat /proc/bus/input/devices | grep "Touchpad"
N: Name="DELL0A5D:00 04F3:311C Touchpad"

(In reply to Robert Martin from comment #20)
> After additional testing with kernel 5.16.13 on Ubuntu 21.10, the problem
> still persists with firmware 1.7.2, with no improvement whatsoever.
> 
> enigma@Melchior:~$ cat /proc/bus/input/devices | grep "Touchpad"
> N: Name="DELL0A5D:00 04F3:311C Touchpad"

This is so discouraging. I am awaiting an XPS 9305 and really feel like it's gonna be a lottery.

Also a bit frustrating to see that after more than 4 months no action has been taken on this record. Apart from Lenovos I think that Dells are the most used laptops with Linux so I'd have thought that having so many people affected by this issue would have moved it higher up in the priority list.

(In reply to Robert Martin from comment #19)
> For those with the 9710 (and probably 9510), a new firmware update has been
> released:
> 
> https://www.dell.com/support/home/en-us/product-support/product/xps-17-9710-
> laptop/drivers
> 
> Can all those affected test with 1.7.2 and get back?  Anecdotally I feel
> like the sluggishness *may* have been reduced.

For the XPS 9510 there also is a new firmware update 1.8.0 (Released 08.03.22):
https://www.dell.com/support/home/de-de/drivers/driversdetails?driverid=v28n4&oscode=wt64a&productcode=xps-15-9510-laptop

My 9510 had 1.3.2 installed. Updating show the following information:

$ sudo fwupdmgr update     
Devices with no available firmware updates: 
 • DLL0945:00 04F3:311C
 • Fingerprint Sensor
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI dbx
Upgrade available for Package level of Dell dock from 01.00.17.01 to 01.00.21.01
Downloading…             [***************************************]
Decompressing…           [***************************************]
Authenticating…          [***************************************]
Authenticating…          [***************************************]
Updating Package level of Dell dock…*****************************]
Restarting device…       [***************************************]
Successfully installed firmware: Tool version updates to address security vulnerabilities.
Devices with the latest available firmware version:
 • RTS5413 in Dell dock
 • RTS5487 in Dell dock
 • VMM5331 in Dell dock
 • WD19S
 • PC SN730 NVMe WDC 1024GB
Upgrade available for System Firmware from 1.3.2 to 1.8.0
XPS 15 9510 must remain plugged into a power source for the duration of the update to avoid damage. Continue with update? [Y|n]: Y
Downloading…             [***************************************] Less than one minute remaining…
Decompressing…           [***************************************]
Authenticating…          [***************************************]
Authenticating…          [***************************************]
Updating System Firmware…[***************************************]
Scheduling…              [***************************************]
Successfully installed firmware
Upgrade available for Unifying Receiver from RQR24.07_B0030 to RQR24.11_B0036
Unifying Receiver and all connected devices may not be usable while updating. Continue with update? [Y|n]: Y
Downloading…             [***************************************] Less than one minute remaining…
Decompressing…           [***************************************]
Authenticating…          [***************************************]
Authenticating…          [***************************************]
Updating Unifying Receiver…**************************************]
Writing…                 [***************************************]
Successfully installed firmware
 • VMM5331 in Dell dock

First impression after the update is that it did not improve. Will properly test next week. Notice the following from above, DLL0945:00 04F3:311C is my touchpad :(.
Devices with no available firmware updates: 
 • DLL0945:00 04F3:311C

$ cat /proc/bus/input/devices | grep "Touchpad"
N: Name="DLL0945:00 04F3:311C Touchpad"

Updated to 1.7.2, touchpad problem persists. No change compared to previous firmware.
I agree that in the past month or so, the problem seems less frequent and lower magnitude. I had almost convinced myself it was fixed.  It's not.

OS: Ubuntu 20.04.4 LTS x86_64 
Host: XPS 15 9510 
Kernel: 5.13.0-35-generic 

$ cat /proc/bus/input/devices | grep "Touchpad"
N: Name="DLL0945:00 04F3:311C Touchpad"

Follow up after updating my 9510 firmware to 1.8.0.
No improvement at all :(

Hi everyone, I recently switched to a Dell XPS 13 9305 (not 9310) and for the first couple of days of use I haven't encountered the issue so far.

So unless it happens on this device again, I am not really affected by this issue anymore. If you feel like this issue needs more attention, please don't hesitate to bring it up in the linux I2C mailing list: linux-i2c@vger.kernel.org

I did that in the past but the time of knowledgeable folks on this subject is scarce and there's probably plenty of other stuff going on, but reiterating how many devices/users are affected might help re-focus priorities.

Have a nice day and fingers crossed

(In reply to Michael Wagner from comment #24)
> Follow up after updating my 9510 firmware to 1.8.0.
> No improvement at all :(

Same.

I am also running a 9510 with the latest 1.8.0 firmware, kernel 5.16.15. This laptop is essentially unusable without an external mouse. Pretty shocking because I know these are popular with Linux users.

Gentoo user here. I have an MSI GE66 Raider 11UE experiencing this issue. It has the touchpad device on the 'Intel(R) Serial IO (I2C|GPIO|UART) Host Controller'. Unfortunately I don't really know what it looked like under Windows' Device Manager.

One not-so-great workaround is to completely disable SYNAPTIC options in the kernel (or blacklist the modules) and let libinput deal with the device in a generic way as simple PS/2 mouse. Obviously you won't get any of the extra features like tap-to-click, etc. It's like using a touchpad from 15 years ago in this scenario.

External mouse works perfectly.

This is the last item to fix on this machine.

I think I'm affected also to this kind of bug, but fortunately it's just happens for a brief moments, usually seconds before returning to normal. While using it, it's literally stopping almost completely moving and returning to move correctly only after 2/3 seconds, but I had once when the device completely stopped working.

It's an AMD platform, Ryzen 5 4500U, Asus VivoBook TP420IA, firmware 3.05.

As far as I've read, the only constant in this thread is the vendor of the touchpad, all seems to be Elan Microelectronics, so maybe a firmware bug in the touchpad firmware itself?

cat /proc/bus/input/devices | grep "Touchpad"
N: Name="ASUE1201:00 04F3:3125 Touchpad"

Marco.

(In reply to Marco from comment #29)
> I think I'm affected also to this kind of bug, but fortunately it's just
> happens for a brief moments, usually seconds before returning to normal.
> While using it, it's literally stopping almost completely moving and
> returning to move correctly only after 2/3 seconds, but I had once when the
> device completely stopped working.
> 
> It's an AMD platform, Ryzen 5 4500U, Asus VivoBook TP420IA, firmware 3.05.
> 
> As far as I've read, the only constant in this thread is the vendor of the
> touchpad, all seems to be Elan Microelectronics, so maybe a firmware bug in
> the touchpad firmware itself?
> 
> cat /proc/bus/input/devices | grep "Touchpad"
> N: Name="ASUE1201:00 04F3:3125 Touchpad"
> 
> Marco.

Hello Marco,

there are unfortunately also plenty of reports by people using DELL hardware. I was one of those myself. I sold my Inspiron and got an XPS 13 9305 (not the new one), and luckily so far I haven't faced the issue. But most XPS and Inspirons from last year are affected, AFAIK.

(In reply to Andrea Ippolito from comment #30)
> (In reply to Marco from comment #29)
> ...
> 
> Hello Marco,
> 
> there are unfortunately also plenty of reports by people using DELL
> hardware. I was one of those myself. I sold my Inspiron and got an XPS 13
> 9305 (not the new one), and luckily so far I haven't faced the issue. But
> most XPS and Inspirons from last year are affected, AFAIK.

What I meant is that if you look at the first 4 digit of the Vendor ID, all but one are 04F3, which correspond to Elan Microeletronics. It's the chip on the back of the touchpad itself, which seems to be relatively the common thread here. But that's just a guess for me, so take it with a pinch of salt.

Would be interesting to check if all the people that report this issue has the same hardware from Elan on the back of the touchpad, maybe that will help narrow it down further.

Marco.

(In reply to Marco from comment #31)
> (In reply to Andrea Ippolito from comment #30)
> > (In reply to Marco from comment #29)
> > ...
> > 
> > Hello Marco,
> > 
> > there are unfortunately also plenty of reports by people using DELL
> > hardware. I was one of those myself. I sold my Inspiron and got an XPS 13
> > 9305 (not the new one), and luckily so far I haven't faced the issue. But
> > most XPS and Inspirons from last year are affected, AFAIK.
> 
> What I meant is that if you look at the first 4 digit of the Vendor ID, all
> but one are 04F3, which correspond to Elan Microeletronics. It's the chip on
> the back of the touchpad itself, which seems to be relatively the common
> thread here. But that's just a guess for me, so take it with a pinch of salt.
> 
> Would be interesting to check if all the people that report this issue has
> the same hardware from Elan on the back of the touchpad, maybe that will
> help narrow it down further.
> 
> Marco.

Oh I see what you mean. I was convinced that my previous Inspiron's touchpad was manufactured by DELL itself, but reading again my old logs its vendor ID was indeed 04F3. And indeed the vendor ID for my new XPS is 06CB(:76B1) which probably explains why it's unaffected.

(In reply to Andrea Ippolito from comment #32)
> (In reply to Marco from comment #31)
> > (In reply to Andrea Ippolito from comment #30)
> > > (In reply to Marco from comment #29)
> > > ...
> 
> Oh I see what you mean. I was convinced that my previous Inspiron's touchpad
> was manufactured by DELL itself, but reading again my old logs its vendor ID
> was indeed 04F3. And indeed the vendor ID for my new XPS is 06CB(:76B1)
> which probably explains why it's unaffected.

Yes, just checking for 06CB as a vendor ID confirms that this is a Synaptics trackpad, so it's not surprising that's not showing the same behaviour; it's probably using a different codepath in the kernel itself (it's just hypothesis from my part, if I don't remember badly now the different device drivers are at a X11/Wayland level, like xf86 or libinput, but I do not know how much code is in the kernel vs userland driver level, so don't quote me on that).

Regardless, I'll check which hardware I have as soon as I have time, in the hope that this will help.

Marco.

I have the same issue on Dell Inspiron 5410, running updated firmware on an up to date Manjaro.
cat /proc/bus/input/devices | grep "Touchpad"
N: Name="DELL0A7D:00 27C6:0D41 Touchpad"

I have been experiencing the issue with Wayland and libinput 1.20.0. I switched to X11 session with synaptics, and I had the same issue. 

Then I went back to wayland with libinput. However, I recompiled and installed libinput 1.18.0 and my system now works flawlessly (have been using it for 7 days without any glitches). Not sure in what new ways libinput 1.20 interacts with the kernel but that may be a hint to a solution. 

Hope this helps.

With libinput 1.18 does X work? Also, 1.19.3? What version of xf86-input-libinput do you have installed?

xf86-input-libinput 1.2.1 here.
Have not tried X with 1.18 or libinput 1.19.

(In reply to sst from comment #34)
> I have the same issue on Dell Inspiron 5410, running updated firmware on an
> up to date Manjaro.
> cat /proc/bus/input/devices | grep "Touchpad"
> N: Name="DELL0A7D:00 27C6:0D41 Touchpad"
> 
> I have been experiencing the issue with Wayland and libinput 1.20.0. I
> switched to X11 session with synaptics, and I had the same issue. 
> 
> Then I went back to wayland with libinput. However, I recompiled and
> installed libinput 1.18.0 and my system now works flawlessly (have been
> using it for 7 days without any glitches). Not sure in what new ways
> libinput 1.20 interacts with the kernel but that may be a hint to a
> solution. 
> 
> Hope this helps.

I tried this (ubuntu 22.04beta, wayland, compile libinput 1.18.0) .  While it seems to happen less often, it definitely still occurs.

Still no fix?  Anything to do go get movement on this?

Just to add to the data, I did have this issue as well as another issue with the trackpad that caused it to unintentionally "click" when the laptop wasn't on a flat surface (e.g. my lap).  Dell replaced the trackpad, and it seems to have *also* fixed the intermittent slowness.

My hardware is the same type as far as I can tell:

cat /proc/bus/input/devices | grep "Touchpad"
N: Name="DELL097D:00 04F3:311C Touchpad"

This points a little toward this being a hardware issue, but hard to tell because even though it hasn't shown up yet, it doesn't mean it won't.  (I normally use an external mouse).

Too many different devices is mentioned here to assume it is correct for all of them, but some folks here seemed to find a hardware solution:

https://www.dell.com/community/Inspiron/Running-List-of-Inspiron-7610-Touchpad-Issue-Posts/td-p/8053835/page/11

and it even has been marked on the forum as 'Dell accepted solution'.

Personally, I went for bit of copper tape instead of soldering. So far it's been 3 days without the issue repeating. Promising but I would give it a week or so before celebrating. 

(I have Inspiron 5515 with different touchpad but it looks as it could be a grounding issue on my device too)

(In reply to kerown from comment #40)
> Too many different devices is mentioned here to assume it is correct for all
> of them, but some folks here seemed to find a hardware solution:
> 
> https://www.dell.com/community/Inspiron/Running-List-of-Inspiron-7610-
> Touchpad-Issue-Posts/td-p/8053835/page/11
> 
> and it even has been marked on the forum as 'Dell accepted solution'.
> 
> Personally, I went for bit of copper tape instead of soldering. So far it's
> been 3 days without the issue repeating. Promising but I would give it a
> week or so before celebrating. 
> 
> (I have Inspiron 5515 with different touchpad but it looks as it could be a
> grounding issue on my device too)

Tried that, didn't work for me on a 2020 Inspiron 13 5301 with an Elantech touchpad :(

> Tried that, didn't work for me on a 2020 Inspiron 13 5301 with an Elantech
> touchpad :(

It's a pity indeed. 

Copper tape mod fix still works well for me and it's been for over a week now. I had one instance where I inserted USB stick that it briefly reoccurred (some sort of static charge?) but after I closed and opened the lid, it got fine again. 

When you have the issue happening, does closing and opening the lid helps? Even if it's for a while? It could indicate that we do have the same problem. 
(You could also check with
'watch -n0.1 --no-title cat /proc/interrupts'
when you have your issue happening, if there is a massive spike in interrupts somewhere. There used to be for me).

If you tried that hardware solution with a conducting tape, rather than soldering, you have to make sure that there is a contact made. Tape has a glue underneath (obviously) so I folded it at the end a little so top surface was in contact with that copper piece in the touchpad. I would still recommend trying. I've tried so many potential solutions, including a patch from here:
https://lore.kernel.org/all/c9b0b147-2907-ff41-4f13-464b3b891c50@wisdomtech.sk/
and nothing helped.

On my Dell XPS 9510 (BIOS 1.9.0, Elantech touchpad firmware "0b"), I was seeing around hourly touchpad lag and acceleration loss in Linux and Windows 11 also.

Updating the touchpad firmware to "0c" (listed for the XPS 9710) has addressed the issues I find:

https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=drc6p&oscode=wt64a&productcode=xps-17-9710-laptop

The archive password is 1234.

I may have solved my issue, for now, on the MSI GE66 Raider 11UE and this probably applies to other models. These steps make the devices come up as the correct I2C DesignWare devices. With libinput it works but with Synaptics you get tap-clicking (the option in Plasma is disabled with libinput).

These warnings appear on boot but they has no effect. The touchpad still works:

psmouse serio1: Failed to reset mouse on isa0060/serio1: -71
psmouse serio1: Failed to enable mouse on isa0060/serio1

1. Install xf86-input-synaptics and make sure it will get used for the touchpad, so obviously this doesn't apply to Wayland users. If you don't care about tap-clicking, skip this step.

2. In the kernel config, enable CONFIG_X86_INTEL_LPSS and make sure to enable all TIGERLAKE and TGL (ones that are specifically for Tiger-Lake only) options including CONFIG_PINCTRL_TIGERLAKE.

3. In the kernel config, disable all RMI4 options, like CONFIG_RMI4_CORE. For SYNAPTICS options, only keep MOUSE_PS2_SYNAPTICS enabled. Enable CONFIG_I2C_DESIGNWARE_CORE and CONFIG_I2C_DESIGNWARE_PLATFORM

4. In the kernel command line, remove psmouse.synaptics_intertouch=1

In your boot log you should see these lines:

kernel: input: PNP0C50:00 06CB:7E7E Mouse as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-PNP0C50:00/0018:06CB:7E7E.0001/input/input18
kernel: input: PNP0C50:00 06CB:7E7E Touchpad as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-PNP0C50:00/0018:06CB:7E7E.0001/input/input19
kernel: hid-multitouch 0018:06CB:7E7E.0001: input,hidraw0: I2C HID v1.00 Mouse [PNP0C50:00 06CB:7E7E] on i2c-PNP0C50:00

Once X comes up, you should have a functional touchpad. It acts just as good (if not better) as in Windows for me.

$ xinput

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
    ...
⎜   ↳ PNP0C50:00 06CB:7E7E Mouse                id=14   [slave  pointer  (2)]
⎜   ↳ PNP0C50:00 06CB:7E7E Touchpad             id=15   [slave  pointer  (2)]
⎜   ↳ PS/2 Generic Mouse                        id=17   [slave  pointer  (2)]
    ...

On Windows, the driver used is a generic I2C HID one after the highly specific 'Intel(R) Serial IO I2C Host Controller - 43E8'. We can do the same on Linux. See screenshots of Device Manager:

https://i.pstorage.space/i/gOegY51Ae/original_Screenshot_2022-05-15_194408.png
https://i.pstorage.space/i/PAevynW0n/original_Screenshot_2022-05-15_194520.png

Still not fixed.
  
But, I've learned, that when it happens, simply turning on (and syncing of course) my bluetooth mouse, fixes the touchpad problem.

That implies there's a possible fix somewhere other than touchpad firmware.

Installing the 0c firmware from Dell appears to have resolved the issue on my Dell XPS 9510. I've been running it for about 5 days now and haven't had a single issue with my touchpad *knock wood*.

Additional details and discussion about this fix can be found on the post dated for May 12, 2022 here: https://gitlab.freedesktop.org/libinput/libinput/-/issues/618#note_1488297

The post outlines a way to install the firmware if you only have Linux installed on your device. If you have Windows, I assume the process will be more straightforward, though the Linux approach isn't too complicated.

Direct link to the firmware: https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=4w96v

Hope this helps!

Thanks! Installed, I'm hopeful, I have an XPS 9510 also.

Nope, didn't fix it for me.  It may happen less often, not sure. But it certainly still happens.

0c isn't a complete fix for everyone (or anyone?).  What it seems to do for myself and others is that it has less periods of sustained intermittent latency, but that it's replaced with smaller periods of the complete loss of left-click functionality, for 5 to about 30 seconds at a time.

It's technically better than it used to be, but only because we're traded longer periods of latency, for a shorter period where the left click becomes functionally useless.

Still feels unacceptable for such an expensive laptop.


https://gitlab.freedesktop.org/libinput/libinput/-/issues/618#note_1489200

Interesting, I have not experienced loss of left click functions.

(In reply to B Rnd from comment #50)
> Interesting, I have not experienced loss of left click functions.

I am using a 9710, what are you using?

XPS 9510.
Also, turns out I have experienced left click issues, I had only noticed it in Firefox so I assumed it was a FF/wayland bug.

I recently got a Dell Precision 5770 with Ubuntu 20.04 LTS. I am seeing the same Trackpad issues.  Was a bit surprised given that the laptop comes with Ubuntu installed, and would have expected Dell to have addressed any issues if it were related to software.

Hence, I'm inclined to believe that this is more likely a hardware issues, as a number of people have also seen this whilst running Windows.  In any case, I'm going to raise a support case with Dell to find out what can be done.

(In reply to Ahmed Riza from comment #53)
> I recently got a Dell Precision 5770 with Ubuntu 20.04 LTS. I am seeing the
> same Trackpad issues.  Was a bit surprised given that the laptop comes with
> Ubuntu installed, and would have expected Dell to have addressed any issues
> if it were related to software.
> 
> Hence, I'm inclined to believe that this is more likely a hardware issues,
> as a number of people have also seen this whilst running Windows.  In any
> case, I'm going to raise a support case with Dell to find out what can be
> done.

Please keep us updated!

Whilst I await to hear from Dell, I observed that whenever this happens, i.e. the use of the Trackpad starts feeling really heavy, with random cursor movements etc, the issue fixes itself, if I close the lid of the laptop and re-open immediately afterwards.

Now, this suggests, that this is a software issue perhaps?

If somebody can test this on the latest Linux kernel v5.19.y versions to confirm that this problem appears on the vanilla kernels, it would be great.

The issue itself might be related to unexpected interrupt storm coming from the touchpad. It can be easily checked by running (as root) `cat /proc/interrupts` a few times in a raw (with 1-2 seconds delay in between each of the run) and see if there is any anomalities. If it's the case it might be the issue with touchpad firmware and suspend-resume behaviour in the software, which might be worked around.

I've installed Fedora on my Precision 5770. The current kernel is `5.19.6-200.fc36.x86_64`. Am seeing the same problem with the trackpad.  It's intermittent and I don't have to reboot. The trackpad goes erratic for a bit, then recovers and will work fine for a while and so on.

Running `dstat` shows the following.  We can see the high interrupts from the 3rd line onwards where I'm just resting a finger tip on the touchpad.

```
$ dstat -t 
You did not select any stats, using -cdngy by default.
----system---- ----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
     time     |usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
08-09 00:26:54|                   |           |           |           |           
08-09 00:26:55|  0   0  99   0   0|   0     0 | 240B   62B|   0     0 | 607  1233 
08-09 00:26:56|  1   0  99   0   0|   0    16k| 180B    0 |   0     0 | 632  1303 
08-09 00:26:57|  1   0  99   0   0|   0     0 | 248B   95B|   0     0 | 570  1144 
08-09 00:26:58|  1   0  99   0   0|   0     0 | 236B  282B|   0     0 |1534  2287 
08-09 00:26:59|  1   0  99   0   0|   0     0 | 120B    0 |   0     0 |1625  2309 
08-09 00:27:00|  1   0  99   0   0|   0    68k|  60B    0 |   0     0 |1828  2322 
08-09 00:27:01|  1   0  98   0   0|   0   448k| 120B    0 |   0     0 |1727  2503 
08-09 00:27:02|  1   1  98   0   0|   0  8195B| 429B   86B|   0     0 |1760  1871 
08-09 00:27:03|  1   4  95   0   0|   0  8189B|6411B 5363B|   0     0 |2554  1846 
```

Checking `/proc/interrupts` shows:

```
$ cat /proc/interrupts  | grep i2c
  40:          0          0          0          0          0          0          0          0          0          0          0    1913129          0          0          0          0          0       3879          0          0  IR-IO-APIC   40-fasteoi   i2c_designware.1, idma64.1
```

Not sure how to interpret the high number shown (1913129) which does increase significantly each time the touchpad is touched.

I've raised a support case with Dell, and they are going to replace the trackpad.  Whether this fixes the problem remains to be seen.

Another interesting thing I observe is that when the trackpad goes into this bad state, `libinput record` shows a continous stream of events as my palm slightly touches the trackpad whilst typing normally.

Hence, it looks like the trackpad lacks palm detection completely during these periods.  The only way to recover, without a reboot, is to close the lid, suspend and resume.

Can you check the conditions summarized in the bug #207189? It might be related, but I would like to be sure.

Well, the Precision 5770 does have an Elan trackpad as well as an nvidia graphics card.  But I'm not sure what's described there is really related to this case. 

Also, I checked my old Precision 5530 laptop which has a Synaptic trackpad. That doesn't have any problems with regard to random trackpad craziness.  

It behaves pretty much the same when I monitor it the `/proc/interrupts` and `dstat -t`.  That is, the number of interrupts seem to be of the same order as the Elan trackpad on the Precision 5770.

An update on the trackpad issues on the Precision 5770: Dell replaced the trackpad a couple of days ago, and so far I've not experienced the issues seen before.  The trackpad has been functioning smoothly and I hope it stays that way.

Hence, in this particular case at least, it appears to have been a hardware issue.

(In reply to Ahmed Riza from comment #61)
> An update on the trackpad issues on the Precision 5770: Dell replaced the
> trackpad a couple of days ago, and so far I've not experienced the issues
> seen before.  The trackpad has been functioning smoothly and I hope it stays
> that way.

Is it still Elan trackpad in your case?

(In reply to Andy Shevchenko from comment #62)

> Is it still Elan trackpad in your case?

Yes, it is still an Elan trackpad, but I noticed that it's a different model number. The previous model was `04F3:311C`.  The current one is `06CB:CE7E`.  Not sure how significant this is though.  

This is what I see in dmesg:
```
hid-multitouch 0018:06CB:CE7E.0002: input,hidraw1: I2C HID v1.00 Mouse [VEN_06CB:00 06CB:CE7E] on i2c-VEN_06CB:00
```

(In reply to Ahmed Riza from comment #63)
> (In reply to Andy Shevchenko from comment #62)
> 
> > Is it still Elan trackpad in your case?
> 
> Yes, it is still an Elan trackpad, but I noticed that it's a different model
> number. The previous model was `04F3:311C`.  The current one is `06CB:CE7E`.
> Not sure how significant this is though.  
> 
> This is what I see in dmesg:
> ```
> hid-multitouch 0018:06CB:CE7E.0002: input,hidraw1: I2C HID v1.00 Mouse
> [VEN_06CB:00 06CB:CE7E] on i2c-VEN_06CB:00
> ```

My bad. A Google search indidcates that `VEN_06CB` means that it is actually a Synaptics model, if I'm not mistaken.

I do get these `libinput` errors several times a day, although these don't seem to affect the working of the trackpad.

```
gnome-shell[2939]: libinput error: event8  - VEN_06CB:00 06CB:CE7E Touchpad: kernel bug: Touch jump detected and discarded.
```

It's very difficult to actually record `libinput` events to capture them, because these happen very randomly.

(In reply to Ahmed Riza from comment #64)
> (In reply to Ahmed Riza from comment #63)
> > (In reply to Andy Shevchenko from comment #62)

> > > Is it still Elan trackpad in your case?

> My bad. A Google search indidcates that `VEN_06CB` means that it is actually
> a Synaptics model, if I'm not mistaken.

So the original issue might be still present. We need somebody with Elan who can confirm either state.

I have a similar issue on a Lenovo X1 Carbon Gen 9 with an ELAN touchpad (ELAN0672:00 04F3:3187). Within the last week or two, the touchpad has begun intermittently exhibiting input lag (I'd estimate a few hundred millis) and slowed acceleration. It seems to be completely random when it occurs and stops happening, every 10 or 20 minutes for a minute or two. Nothing unusual in dmesg, journalctl, or /proc/interrupts. The laptop is running Debian testing.

None of the following has helped:

- Downgrade the kernel from 5.19 -> 5.16
- Downgrade libinput 1.16.4 -> 1.21.0
- Downgrade xserver-xorg-input-libinput 1.2.1 -> 0.30.0
- Use libinput driver instead of synaptics
- Updating firmware

Can confirm issue on Arch and Fedora since kernel 5
Asus Vivobook X512DA/F512DA-RS51
ELAN1300:00 04F3:3087

dmesg

   11.775319] input: ELAN1300:00 04F3:3087 Mouse as /devices/platform/AMDI0010:01/i2c-0/i2c-ELAN1300:00/0018:04F3:3087.0005/input/input16
[   11.775401] input: ELAN1300:00 04F3:3087 Touchpad as /devices/platform/AMDI0010:01/i2c-0/i2c-ELAN1300:00/0018:04F3:3087.0005/input/input17
[   11.775465] hid-generic 0018:04F3:3087.0005: input,hidraw2: I2C HID v1.00 Mouse [ELAN1300:00 04F3:3087] on i2c-ELAN1300:00
[   12.638184] i2c_hid_acpi i2c-ELAN1300:00: device returned incorrect report (2 vs 14 expected)
[   12.638816] input: ELAN1300:00 04F3:3087 Mouse as /devices/platform/AMDI0010:01/i2c-0/i2c-ELAN1300:00/0018:04F3:3087.0005/input/input21
[   12.638966] input: ELAN1300:00 04F3:3087 Touchpad as /devices/platform/AMDI0010:01/i2c-0/i2c-ELAN1300:00/0018:04F3:3087.0005/input/input22
[   12.639103] hid-multitouch 0018:04F3:3087.0005: input,hidraw2: I2C HID v1.00 Mouse [ELAN1300:00 04F3:3087] on i2c-ELAN1300:00

This problem has gone from frustrating and troublesome to rare and hard to notice on my Dell XPS 9510 (Ubuntu 22.04).  Something good has been happening.

Created attachment 303282 [details]
HID data from top-right -> bottom-left single-finger swipe while the issue is NOT occurring

Created attachment 303283 [details]
HID data from top-right -> bottom-left single-finger swipe while the issue IS occurring

I have the same issue - sporadically sluggish/high-inertia pointer behavior Andrea has helpfully documented here and elsewhere. My HW is Dell 9510, and I'm on Debian 11. 

I believe I've collected some useful data that indicates that the issue is at or below the /dev/hidraw0 layer (i.e. squarely outside libinput).

I noticed a second key symptom when the issue occurs. When I do a fast swipe (i.e. from top right to bottom left), the pointer hardly moves. (This is *not* related to "dead edges")

I found a useful tool called hid-recorder from hid-tools (https://gitlab.freedesktop.org/libevdev/hid-tools), and managed to record the raw events off /dev/hidraw0 while the issue was occurring. While it can be difficult to distinguish the data between "sluggish pointer response" and "fast pointer response" symptom, it's much easier to distinguish "pointer barely moved" vs "pointer should have flung across the screen" compared to the hid data. Note that the hid data reports touchpad contact coordinates, and you'll have to believe me on what I saw the pointer do on screen in response, and also what may action was across the touchpad :).



First "hid-recorder /dev/hidraw0" recording is attached: https://bugzilla.kernel.org/attachment.cgi?id=303282

This is recorded while the pointer is behaving normally in response to my touchpad use. 
Action: rapid single-finger swipe from top right to bottom left

In the excerpt below, note the fast but steady/smooth coordinate change from ~(3600,550) to ~(1000,2100). This data looks exactly as expected, and the pointer response on screen is also exactly as expected (moved diagonally to the left and down on screen)

# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3606 | Y:    557 | Scan Time:  43020 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.357763 12 04 03 16 0e 2d 02 0c a8 01 80 1f 66
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3508 | Y:    630 | Scan Time:  43090 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.364972 12 04 03 b4 0d 76 02 52 a8 01 80 20 86
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3349 | Y:    730 | Scan Time:  43160 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.371753 12 04 03 15 0d da 02 98 a8 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3199 | Y:    810 | Scan Time:  43230 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.378687 12 04 03 7f 0c 2a 03 de a8 01 80 20 66
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3032 | Y:    895 | Scan Time:  43300 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.385679 12 04 03 d8 0b 7f 03 24 a9 01 80 20 66
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   2843 | Y:    988 | Scan Time:  43370 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.392505 12 04 03 1b 0b dc 03 6a a9 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   2642 | Y:   1090 | Scan Time:  43440 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.399632 12 04 03 52 0a 42 04 b0 a9 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   2432 | Y:   1203 | Scan Time:  43510 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.406577 12 04 03 80 09 b3 04 f6 a9 01 80 20 87
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   2224 | Y:   1319 | Scan Time:  43580 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.413566 12 04 03 b0 08 27 05 3c aa 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   2023 | Y:   1434 | Scan Time:  43650 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.420518 12 04 03 e7 07 9a 05 82 aa 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1831 | Y:   1551 | Scan Time:  43720 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.427390 12 04 03 27 07 0f 06 c8 aa 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1654 | Y:   1661 | Scan Time:  43790 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.434466 12 04 03 76 06 7d 06 0e ab 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1495 | Y:   1767 | Scan Time:  43860 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.441456 12 04 03 d7 05 e7 06 54 ab 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1363 | Y:   1863 | Scan Time:  43930 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.448297 12 04 03 53 05 47 07 9a ab 01 80 20 76
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1256 | Y:   1949 | Scan Time:  44000 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.455339 12 04 03 e8 04 9d 07 e0 ab 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1172 | Y:   2025 | Scan Time:  44070 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.462373 12 04 03 94 04 e9 07 26 ac 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1109 | Y:   2088 | Scan Time:  44140 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.469359 12 04 03 55 04 28 08 6c ac 01 80 20 76
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1068 | Y:   2136 | Scan Time:  44210 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.476430 12 04 03 2c 04 58 08 b2 ac 01 80 20 66
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1046 | Y:   2166 | Scan Time:  44280 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.483335 12 04 03 16 04 76 08 f8 ac 01 80 20 67
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1037 | Y:   2178 | Scan Time:  44350 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.490288 12 04 03 0d 04 82 08 3e ad 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1037 | Y:   2178 | Scan Time:  44420 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.497140 12 04 03 0d 04 82 08 84 ad 01 80 20 77
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   1040 | Y:   2173 | Scan Time:  44490 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.504266 12 04 03 10 04 7d 08 ca ad 01 80 20 67




Second "hid-recorder /dev/hidraw0" recording is attached: https://bugzilla.kernel.org/attachment.cgi?id=303283

This is recorded while the sluggish pointer behavior is occurring in response to my touchpad use.
Action: the same as the previous, a rapid single-finger swipe from top right to bottom left.

In the excerpt below, notice the raw hid data reports a second touch, where one of the "multiple" touches remains at the approx starting location on the touchpad. This data looks completely bogus/nonsense given the swipe motion I did only involved 1 finger. The pointer response is just a slight shift, hardly moves on screen - obviously not what it should be doing based on my swipe, but is consistent with what /dev/hidraw0 reports.
I reproduced a similar output two more times before the issue went away (for now). I was very careful to ensure only one finger ever was in contact with the touchpad while swiping, despite what the hid data shows.

# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3586 | Y:    939 | Scan Time:  27572 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.058031 12 04 03 02 0e ab 03 b4 6b 01 c0 20 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3582 | Y:    944 | Scan Time:  27642 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.071264 12 04 03 fe 0d b0 03 fa 6b 01 c0 20 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3577 | Y:    950 | Scan Time:  27712 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.071862 12 04 03 f9 0d b6 03 40 6c 01 c0 20 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3573 | Y:    956 | Scan Time:  27782 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.085352 12 04 03 f5 0d bc 03 86 6c 01 c0 20 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3567 | Y:    960 | Scan Time:  27852 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.086010 12 04 03 ef 0d c0 03 cc 6c 01 c0 20 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3563 | Y:    965 | Scan Time:  27922 | Contact Count:    2 | Button: 0 | # | # 
E: 000000.099302 12 04 03 eb 0d c5 03 12 6d 02 c0 20 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  27922 | Contact Count:    0 | Button: 0 | # | # 
E: 000000.099889 12 04 13 b5 0a a0 06 12 6d 00 c0 26 ff
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3560 | Y:    969 | Scan Time:  27992 | Contact Count:    2 | Button: 0 | # | # 
E: 000000.100239 12 04 03 e8 0d c9 03 58 6d 02 c0 20 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  27992 | Contact Count:    0 | Button: 0 | # | # 
E: 000000.100663 12 04 13 b5 0a a0 06 58 6d 00 c0 26 ff
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3557 | Y:    973 | Scan Time:  28062 | Contact Count:    2 | Button: 0 | # | # 
E: 000000.113297 12 04 03 e5 0d cd 03 9e 6d 02 c0 20 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28062 | Contact Count:    0 | Button: 0 | # | # 
E: 000000.113974 12 04 13 b5 0a a0 06 9e 6d 00 c0 26 ff
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   0 | X:   3553 | Y:    977 | Scan Time:  28132 | Contact Count:    2 | Button: 0 | # | # 
E: 000000.114312 12 04 03 e1 0d d1 03 e4 6d 02 c0 20 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28132 | Contact Count:    0 | Button: 0 | # | # 
E: 000000.114768 12 04 13 b5 0a a0 06 e4 6d 00 c0 26 ff
# ReportID: 4 / Confidence: 1 | Tip Switch: 0 | # | Contact Id:   0 | X:   3553 | Y:    977 | Scan Time:  28202 | Contact Count:    2 | Button: 0 | # | # 
E: 000000.126988 12 04 01 e1 0d d1 03 2a 6e 02 c0 20 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28202 | Contact Count:    0 | Button: 0 | # | # 
E: 000000.127581 12 04 13 b5 0a a0 06 2a 6e 00 c0 25 ff
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28272 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.127959 12 04 13 b5 0a a0 06 70 6e 01 c0 25 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28342 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.141152 12 04 13 b5 0a a0 06 b6 6e 01 c0 25 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28412 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.141761 12 04 13 b5 0a a0 06 fc 6e 01 c0 25 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28482 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.155160 12 04 13 b5 0a a0 06 42 6f 01 c0 25 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28552 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.155701 12 04 13 b5 0a a0 06 88 6f 01 c0 25 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28622 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.169095 12 04 13 b5 0a a0 06 ce 6f 01 c0 25 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28692 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.169713 12 04 13 b5 0a a0 06 14 70 01 c0 25 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2741 | Y:   1696 | Scan Time:  28762 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.182912 12 04 13 b5 0a a0 06 5a 70 01 c0 25 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2742 | Y:   1692 | Scan Time:  28832 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.183562 12 04 13 b6 0a 9c 06 a0 70 01 c0 25 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2742 | Y:   1689 | Scan Time:  28902 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.196777 12 04 13 b6 0a 99 06 e6 70 01 c0 25 44
# ReportID: 4 / Confidence: 1 | Tip Switch: 1 | # | Contact Id:   1 | X:   2742 | Y:   1685 | Scan Time:  28972 | Contact Count:    1 | Button: 0 | # | # 
E: 000000.197355 12 04 13 b6 0a 95 06 2c 71 01 c0 25 44





So, this should rule out libinput and some higher-level parts of the kernel. (If the issue surfaces in /dev/hidraw0, obviously it'll also surface in /dev/input/eventNN, e.g. if recorded with "libinput record" or "evtest".) I can't comment on whether it's a hardware issue (I've seen some comments in various threads pointing to a grounding issue as a root cause), but I have my suspicions...

Folks, please make sure the bug reports are not getting mixed together. For each hardware combination create a separate bugs and focus only on a single one in each of the bugs.

For example,
 - Intel SoC + Elan touchpad
 - AMD + Synaptics
 - etc.

Announcement: For the Intel SoC based platforms, can you test on Linux kernel v6.2-rc8? It has one patch which affects how touchpads are working after suspend-resume cycle.

XPS 11th gen + elan touchpad (04F3:311C) here and can confirm running 6.2 that the issue still happens. Although I will say that the severe lag is somewhat reduced. Input latency and slowness is just as bad though. Happens sporadically.

I confirm the same issue here. Laptop is Samsung 550XDA. The mouse pointer gets crazy after a while, at random times. It seems when I move the finger on the touchpad in small circular distances then try to move it rapidly to some part of it the problem happens (but it can be only my assumption).

$ cat /proc/bus/input/devices |grep -b3 "04F3"

1355-I: Bus=0018 Vendor=04f3 Product=3192 Version=0100
1405:N: Name="ELAN0B00:00 04F3:3192 Touchpad"
1446-P: Phys=i2c-ELAN0B00:00
1470:S: Sysfs=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-1/i2c-ELAN0B00:00/0018:04F3:3192.0001/input/input9
1584-U: Uniq=
1593-H: Handlers=mouse1 event5 

To workaround the laggy pointer which makes it unusable, the following script helped:

$ xinput disable 11 && xinput disable 10 && sleep 10 && xinput enable 11

As my xinput output looks like:

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ ELAN0B00:00 04F3:3192 Touchpad          	id=11	[slave  pointer  (2)]
⎜   ↳ ELAN0B00:00 04F3:3192 Mouse             	id=10	[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)]
    ↳ VGA Camera: VGA Camera                  	id=9	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=12	[slave  keyboard (3)]
    ↳ Q6 (AVRCP)                              	id=13	[slave  keyboard (3)]

That workaround helps. Sadly, it can return within seconds. Using kernel 5.19.0, Xps 9510

Probably just a coincidence but this issue goes away whenever I press the keyboard lock toggle key on my keyboard quickly like 6 times.

(In reply to mjbrm1 from comment #80)
> Probably just a coincidence but this issue goes away whenever I press the
> keyboard lock toggle key on my keyboard quickly like 6 times.

It might be related to the EC firmware that handles the Lock key, that firmware most likely does reprogram touchscreen and it starts working.

Found a great sale on a new Dell 9530 (13th gen i7).
Hoping, just hoping, something had changed with the touchpad and/or firmware.

Nope, laggy/crappy/intermentent touchpad problem still here.  
CRAP. I'm returning it.

Touchpad VEN_04F3:00 04F3:32AA
Ubuntu 23.10
XPS 15 9530
Kernel 6.5.0-14

(In reply to B Rnd from comment #82)
> Found a great sale on a new Dell 9530 (13th gen i7).
> Hoping, just hoping, something had changed with the touchpad and/or firmware.
> 
> Nope, laggy/crappy/intermentent touchpad problem still here.  
> CRAP. I'm returning it.
> 
> Touchpad VEN_04F3:00 04F3:32AA
> Ubuntu 23.10
> XPS 15 9530
> Kernel 6.5.0-14

Same issue here. Just bought an XPS 9530 and very disappointed because of this bug.

Touchpad VEN_04F3:00 04F3:32AA
Arch Linux x86_64
Dell XPS 9530
Kernel: 6.6.49-1-lts