Bug 1188439

If I load the i2c_hid module with debug=1, I see tons of debug output from the i2c_hid module in the system journal even with X shows the pointer as frozen.

compile this little test program here and run it when the touchpad is frozen:
http://people.freedesktop.org/~whot/grabtest.c
that should tell you if there's a frozen grab or if it's stuck elsewhere.

did you spot any pattern yet by any chance? e.g. tends to freeze after a click, a tap, or something? If so you may be able to reproduce it reliably, at which point you can hopefully get an evemu recording off it.

If not, run evemu-record anyway to get a recording of when it happens. Restart evemu frequently so that when it hits the recording is (hopefully) only of the last couple of seconds rather than a 30 minute recording. when you have a recording, reply it locally to see if you can reproduce the issue with the recording - from then on it should be fairly simple to fix.

Created attachment 987906 [details]
evemu-record output

I ran evemu-record and tried to reproduce the freeze.  It seems to happen when I apply two fingers to the trackpad for a right-click tap or click or for a two finger vertical scroll.  If I try to do a vertical scroll with two fingers, it's like the touchpad gets stuck in scrolling mode and won't let me move the pointer again -- even if I remove all fingers from the touchpad for several seconds.

Often times if I use two ringers to do a right click, the touchpad will freeze.  The only way to release is to wildly click with one or two fingers until the pointer starts moving again or the touchpad gets into a horrible state and I have to modprobe -r hid_multitouch to bring it back. ;)

However, I did find that if I *always* use only one finger, the touchpad doesn't freeze.  Two or three finger clicks/gestures cause it to freeze almost immediately.

I did find it unusual that evemu reported that the touchpad has a BTN_LEFT event but no BTN_RIGHT:

#   Event type 1 (EV_KEY)
#     Event code 272 (BTN_LEFT)
#     Event code 325 (BTN_TOOL_FINGER)
#     Event code 330 (BTN_TOUCH)
#     Event code 333 (BTN_TOOL_DOUBLETAP)
#     Event code 334 (BTN_TOOL_TRIPLETAP)

Xorg logs also report the touchpad as a "catchall touchpad".  Should I be placing an xorg config file into /etc/X11/xorg.conf.d/ to force the touchpad to use a certain driver?

(In reply to Major Hayden from comment #3)
> I did find it unusual that evemu reported that the touchpad has a BTN_LEFT
> event but no BTN_RIGHT:

that's normal these days, most touchpads don't have a right button anymore, it's all software-emulated.

(In reply to Major Hayden from comment #4)
> Xorg logs also report the touchpad as a "catchall touchpad".  Should I be
> placing an xorg config file into /etc/X11/xorg.conf.d/ to force the touchpad
> to use a certain driver?

nope, that's fine, it assigns the synaptics driver as should happen. Attach your Xorg.log anyway please

did this recording reproduce the bug? I'm running it here and I can see a right click and some moving around but no freeze.

Can you reproduce it with this recording yourself? sudo evemu-play /dev/input/eventX < recordings-file, with X being your touchpad. If that reproduces it, try replaying it through a uinput device, i.e.
sudo evemu-device recordings-file
prints an event node, replay through that event node. Does that reproduce the freeze?

The event sequence itself looks normal, from what I can tell.

Hey Peter -- I apologize for not being as detailed last night as I should have been.  I left out a bunch! :)

I ran your grabtest script in a loop while I was using the touchpad and it showed success even through two touchpad "freezes" in GNOME.  I never saw it say anything other than "success" in a 4-5 minute road test.

I tested the evemu output from last night with evemu-play this morning and the movements all look normal.  I didn't see any lockups or freezes on screen when I replayed the data from last night.  However, the touchpad was in its usual frozen state AFTER the playback was done.

After going back over the evemu-record output, it seems that this sequence makes the touchpad freeze:

E: 1.050649 0001 0145 0000	# EV_KEY / BTN_TOOL_FINGER      0
E: 1.050649 0001 014d 0001	# EV_KEY / BTN_TOOL_DOUBLETAP   1

This normally shows up if I apply more than one finger to the pad for vertical scrolling or a right-click.  I'm unable to do two-finger or three-finger taps on the pad -- they don't register in X.  Only single finger taps have any effect.

I'll get you the Xorg logs this evening.  Let me know if there's anything else to test in the meantime.

Hi Major, just for curiosity: did you try with xf86-input-libinput instead of evdev/synaptics?

Niccolò: I did.  However, I couldn't get the configuration file structured correctly in /etc/X11/xorg.conf.d/.  I tried quite a few different variations but X wouldn't start.  Do you have a sample config I could try?

Unfortunately not, libinput is on my to-do list but I will try it when I will receive my XPS 13 (next week, max two weeks from now). In the meantime I pinged peoples in the xf86-input-libinput gentoo bug report, I will let you know if someone actually succeeded.

Major: Here it is:
http://cgit.freedesktop.org/xorg/driver/xf86-input-libinput/tree/conf/99-libinput.conf

That looks easy enough, Niccolò! I'll try it this evening.

Created attachment 988341 [details]
unmodified F21 xorg logs from 2015-02-04

Here's the Xorg logs from the laptop.  I haven't modified any Xorg configs.  They're the F21 defaults.

I did find this backtrace in the log that looks interesting:

(EE) Backtrace:
(EE) 0: /usr/lib64/xorg/modules/input/synaptics_drv.so (_init+0x2bbf) [
(EE) 1: /usr/lib64/xorg/modules/input/synaptics_drv.so (_init+0x4f42) [
(EE) 2: /usr/libexec/Xorg.bin (DPMSSupported+0xe8) [0x4774c8]
(EE) 3: /usr/libexec/Xorg.bin (xf86SerialModemClearBits+0x277) [0x4a1ec7]
(EE) 4: /lib64/libc.so.6 (__restore_rt+0x0) [0x7f30162f894f]
(EE) 5: /lib64/libc.so.6 (__select_nocancel+0x2a) [0x7f30163bb04a]
(EE) 6: /usr/libexec/Xorg.bin (WaitForSomething+0x1b4) [0x595904]
(EE) 7: /usr/libexec/Xorg.bin (SendErrorToClient+0x111) [0x438fd1]
(EE) 8: /usr/libexec/Xorg.bin (remove_fs_handlers+0x416) [0x43d316]
(EE) 9: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7f30162e3fe0]
(EE) 10: /usr/libexec/Xorg.bin (_start+0x29) [0x4276ee]
(EE) 11: ? (?+0x29) [0x29]
(EE)
(EE) [dix] DLL0665:01 06CB:76AD UNKNOWN: unable to find touch point 1
(EE) BUG: triggered 'if (priv->num_active_touches > priv->num_slots)'
(EE) BUG: synaptics.c:2969 in UpdateTouchState()

It was repeated two or three times.

Also, I did test libinput tonight.  The touchpad still locked up with more than one finger on the pad.

It seems like this condition happened before: https://bugzilla.redhat.com/show_bug.cgi?id=877464

(In reply to Major Hayden from comment #7)
> After going back over the evemu-record output, it seems that this sequence
> makes the touchpad freeze:
> 
> E: 1.050649 0001 0145 0000	# EV_KEY / BTN_TOOL_FINGER      0
> E: 1.050649 0001 014d 0001	# EV_KEY / BTN_TOOL_DOUBLETAP   1

that's expected behaviour. FINGER, DOUBLETAP, TRIPLETAP, etc. are the markers for one, two, three, etc. fingers on the touchpad. Not all touchpads support proper multitouch but some can tell when there's more than one finger on the touchpad, hence the special keys.

nothing interesting in the log, but the BUG message is a hint, that usually happens when the touchpoint count is wrong. The trick is getting an evemu recording that reproduces it, without it it's a lot of guesswork.
Generally once you get the message once all bets are off and you need to restart X, it can only get worse. (there was a very common bug that triggered this after suspend but that has been fixed since, so I doubt anything you find in bugzilla is a duplicate)

Also, if libinput suffers from the same issue it's almost certainly some issue with the kernel event sequence.

Final note: the sequence you attached leaves one touchpoint on the device. If you replay that through your normal touchpad device, the touch count will be off after that. That'll give you false positives. Replay it through a uinput device to be safe, or record a sequence that ends with you releasing all fingers.

On my device I noticed this bug just happens with kernels 3.17 and newer. I am currently using kernel 3.16 and the trackpad works just fine. Switching to kernel 3.18 on the other hand shows exactly the described bug.
So it seems there is some change in the 3.17 kernel which somehow introduced this behaviour, maybe the event ordering you mentioned?

Major, can you bisect between 3.16 and 3.17?

Oof, well I guess I know the path ahead of me now. :/

So if I'm understanding the thread correctly, we're thinking that X isn't where the bug resides since the evemu-record playback causes the mouse pointer to move in the way we expect?

I'll have to hold off on the bisecting until the weekend.  I can get access to a box with a bunch of cores to do a bunch of kernel builds on it. ;)

the problem is that it's almost certainly a userspace bug but apparently triggered by some event sequence that changed in the kernel. If you can see evtest/evemu events from the kernel even when the touchpad is frozen that guarantees the lockup is in the xorg driver.

It's pin-pointing the exact sequence that's the issue.

You can also try grabbing libinput from git and using the tools/event-debug tool, then reproduce the bug (i.e. use two-finger until the event output stops). libinput is a lot easier to put printf statements everywhere to track down where things are going wrong. I think this should narrow down the sequence that triggers it, from that we may be able to get to the kernel bug too.

Having said that, if you can bisect the kernel that would of course be ideal ;)

I'll see if I can tinker with libinput and bisect the kernel. ;)

Kernel bisect underway. The touchpad doesn't freeze under 3.16.x (already tried multiple kernels in the 3.16 tree) but it shows up as a PS/2 mouse every time.  GNOME sees it as a plain mouse and you can't use two or three finger clicks.  Your only option would be to define certain areas on the pad to be left or right click areas -- not the result we're looking for.

Currently bisecting the 3.17 kernel tree.

Small breakthrough.  Kernel 3.17.0 works perfectly.  The trackpad shows up on the I2C bus with i2c_hid and hid_multitouch and it handles one/two/three finger clicks *and taps* without any problems.  Vertical scrolling works flawlessly.

I'm going to adjust the bisect to test kernels between 3.17 and 3.18 since 3.17.0 works fine.

59 patches left in the bisect (started with ~ 6500): https://gist.github.com/major/c3b7c576af32093f39b5

Alrighty, here's the problematic patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1c7e29e8d276c669e8790bb8be9f505ddc48888

If I build the kernel at the revision just prior to this patch, the touchpad works flawlessly.  There are no freezes and the tapping works.  Add in this patch and this happens:

1) Only single finger taps work
2) Multi-finger taps and vertical scrolling will cause a freeze
3) Two-finger clicks will often freeze the touchpad

------------------------------------------------------

From d1c7e29e8d276c669e8790bb8be9f505ddc48888 Mon Sep 17 00:00:00 2001
From: Gwendal Grignou <gwendal>
Date: Thu, 11 Dec 2014 16:02:45 -0800
Subject: HID: i2c-hid: prevent buffer overflow in early IRQ

Before ->start() is called, bufsize size is set to HID_MIN_BUFFER_SIZE,
64 bytes. While processing the IRQ, we were asking to receive up to
wMaxInputLength bytes, which can be bigger than 64 bytes.

Later, when ->start is run, a proper bufsize will be calculated.

Given wMaxInputLength is said to be unreliable in other part of the
code, set to receive only what we can even if it results in truncated
reports.

Signed-off-by: Gwendal Grignou <gwendal>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires>
Cc: stable.org
Signed-off-by: Jiri Kosina <jkosina>

diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 747d544..9c014803b4 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -369,7 +369,7 @@ static int i2c_hid_hwreset(struct i2c_client *client)
 static void i2c_hid_get_input(struct i2c_hid *ihid)
 {
 	int ret, ret_size;
-	int size = le16_to_cpu(ihid->hdesc.wMaxInputLength);
+	int size = ihid->bufsize;
 
 	ret = i2c_master_recv(ihid->client, ihid->inbuf, size);
 	if (ret != size) {
-- 

------------------------------------------------------

I'm not entirely sure what to do with this patch other than remove it.  I emailed Benjamin a few days ago for his opinion and he might know a bit more about this particular patch.

Would it make sense to simply increase the size of the input buffer?

/me lobs it over to Benjamin's court

I just got an update to xorg-x11-drv-synaptics and the trackpad is no longer freezing on Fedora 21 with kernel 3.18.5.  Major -- are you seeing the same thing?

Ryan, I'm still seeing freezes with 3.18.5 and xorg-x11-drv-synaptics-1.8.1-2.fc21.  Tapping doesn't work and once I apply more than one finger to the pad a few times, it freezes up.

Major -- I should have specified, I'm using xorg-x11-drv-synaptics-1.8.1-3.fc21.  I haven't gotten the cursor to freeze yet since the update, but I am seeing that if I lift my finger and put it back on the trackpad it will almost always move the cursor.  I will test some more and report back.

(In reply to Major Hayden from comment #25)
> Alrighty, here's the problematic patch:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=d1c7e29e8d276c669e8790bb8be9f505ddc48888
> 

This patch should not freeze the touchpad... unless there is a problem in the FW. And apparently there is :(

I will need 2 things:
- a full dmesg output with "i2c_hid.debug=1 log_buf_len=1M" appended to the command line
- a hid-recorder [1] trace of the events when there is a freeze.

If ihid->hdesc.wMaxInputLength is greater than ihid->bufsize, it shouldn't be difficult to fix that. If it is not, then it's going to be a little bit more tricky.

[1] http://bentiss.github.io/hid-replay-docs/Fedora.html

Created attachment 989916 [details]
dmesg output with i2c debug

Created attachment 989917 [details]
hid-recorder output

Thanks, Benjamin.  The files you requested are attached.  The trackpad freeze happened shortly after the 20 second mark and then un-froze around the 30 second mark.

What's odd is that when I did a hid-replay, I saw the pointer get stuck from about the 20 to 30 second mark.  I didn't see that same result with evemu-record and evemu-replay.  With evemu, the pointer kept moving during the replay when it was stuck during the recording (hopefully that makes sense).

Created attachment 989918 [details]
Full dmesg including hid-record test

The previous dmesg didn't include the i2c_hid debug output from the hid-record test.  Sorry about that.  You might want to look at this one instead.

Created attachment 990188 [details]
0001-HID-multitouch-force-release-of-touches-when-i2c-com.patch

Thanks for the logs.

We seem to lose some reports from time to time. It is not a problem most of the time, but when you see a freeze, that's because we missed one touch release from the touchpad.

From what I can see, ihid->hdesc.wMaxInputLength is 0x3c, while the computed length should be 0x3d. So the one byte off might explain why we are missing some reports here and there. Though it's going tricky to fix that at the i2c_hid level without breaking other devices.

I think I can fix that in hid-multitouch. See the attached patch. It might not work in 100% of the cases (especially in the "tap" settings), but it should be good enough with a touchpad.

Thanks, Benjamin.  I'll test out that patch tonight and report back.

I added the patch to 3.19-rc7 and it does eliminate the touchpad freeze!  Hooray!  One, two and three finger *clicks* work anywhere on the touchpad and there are no freezes after using the touchpad for about 5-10 minutes.  (I was consistently able to get a freeze in 15-20 seconds previously).

However, as you said, the tapping isn't working properly.  I'm able to tap with one finger but if I use more than one finger, the cursor seems to jump around as if it's trying to move the pointer to accommodate the first and then the second finger.  Three finger taps don't work either.

If I revert d1c7e29e8d276c669e8790bb8be9f505ddc48888, taps work properly.  Do you know if an additional patch could bring back the tapping?  Or, should that be in a new bug ticket?

Benjamin - I've tried the patch provided by you on the latest stable release 3.19.0 and after 25 minutes without any problem the freezes started again.
Though what I "discovered" while building a new kernel (obviously the cpu-load was very high) there aren't any freezes at all! (At the time discovering this, I already had your patch applied)

The arch-wiki says:
"If you use CPU frequency scaling, avoid using the "ondemand" governor and use the "performance" governor when possible, as the touchpad may lose sync when the CPU frequency changes."

Don't know if this information does help in any way, shape or form but I thought I provide it anyway.

Benjamin -- Any more ideas on how to restore tapping to the pad?

(In reply to Major Hayden from comment #40)
> Benjamin -- Any more ideas on how to restore tapping to the pad?

Besides partially reverting the faulty patch (which is required, otherwise we may write outside of an allocated memory), I have no more smart ideas.
I can't recall exactly which device had a faulty wMaxInputLength, but I might have seen one on a pre-production device at least. I might hack up a small hack around it, but I have not a good sight on what would be the effects on other devices :(

:(

Do you think it's a thing which Dell might fix with a firmware update?

Benjamin: Why not do the following? I'm not familiar with what the issues are with wMaxInputLength for some devices, but this approach does continue to prevent buffer overruns. I'm seeing much improved touchpad behavior with this change.


diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index d43e967..5e72fc2 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -370,7 +370,10 @@ static int i2c_hid_hwreset(struct i2c_client *client)
 static void i2c_hid_get_input(struct i2c_hid *ihid)
 {
        int ret, ret_size;
-       int size = ihid->bufsize;
+       int size = le16_to_cpu(ihid->hdesc.wMaxInputLength);
+
+       if (size > ihid->bufsize)
+               size = ihid->bufsize;
 
        ret = i2c_master_recv(ihid->client, ihid->inbuf, size);
        if (ret != size) {

(In reply to Seth Forshee from comment #43)
> Benjamin: Why not do the following? I'm not familiar with what the issues
> are with wMaxInputLength for some devices, but this approach does continue
> to prevent buffer overruns. I'm seeing much improved touchpad behavior with
> this change.

IIRC, the issue was that some devices used 0 as maxInputLength (which is obviously wrong) and others might have used a smaller length that the actual max input length (which is the case here, but the HW bugs without the advertised length).

Given that your patch addresses the former issue and that the latter seems a hardware bug, we could try with your patch.

Please submit it upstream and I'll add my Rev-by.

(In reply to Benjamin Tissoires from comment #44)
> (In reply to Seth Forshee from comment #43)
> > Benjamin: Why not do the following? I'm not familiar with what the issues
> > are with wMaxInputLength for some devices, but this approach does continue
> > to prevent buffer overruns. I'm seeing much improved touchpad behavior with
> > this change.

Based on the history in git the size was only changed to address the buffer overrun, and there's no indication that it fixed any other issues, though I suppose some devices could have been fixed by accident.

> IIRC, the issue was that some devices used 0 as maxInputLength (which is
> obviously wrong) and others might have used a smaller length that the actual
> max input length (which is the case here, but the HW bugs without the
> advertised length).
> 
> Given that your patch addresses the former issue and that the latter seems a
> hardware bug, we could try with your patch.
> 
> Please submit it upstream and I'll add my Rev-by.

Done.

http://lkml.kernel.org/r/1424454311-70750-1-git-send-email-seth.forshee@canonical.com

I've added the patch from Seth to F20-rawhide.  Thanks!

Using rawhide and the xorg libinput driver. Also have acpi_osi="!Windows 2013" and psmouse.resetafter=0 on the kernel command line.

Feb 25 07:43:13 localhost.localdomain kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, th
Feb 25 07:43:14 localhost.localdomain kernel: psmouse serio1: resync failed, issuing reconnect request
Feb 25 07:44:45 localhost.localdomain kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, th
Feb 25 07:44:45 localhost.localdomain kernel: psmouse serio1: resync failed, issuing reconnect request
Feb 25 07:44:50 localhost.localdomain kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4
Feb 25 07:44:50 localhost.localdomain kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Feb 25 07:44:50 localhost.localdomain kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Feb 25 07:44:50 localhost.localdomain kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Feb 25 07:44:50 localhost.localdomain kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Feb 25 07:44:50 localhost.localdomain kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Feb 25 07:44:50 localhost.localdomain kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced.

They are so frequent the trackpad is largely unusable

(In reply to darrell pfeifer from comment #47)
> Using rawhide and the xorg libinput driver. Also have acpi_osi="!Windows
> 2013" and psmouse.resetafter=0 on the kernel command line.
>
> Feb 25 07:44:50 localhost.localdomain kernel: psmouse serio1: TouchPad at
> isa0060/serio1/input0 - driver resynced.
> 
> They are so frequent the trackpad is largely unusable

There is a patch proposed upstream to solve this issue:
https://patchwork.kernel.org/patch/5849611/

The fact that having the touchpad or the soundcard not working is a bit worrying on this laptop :(

Benjamin,

darrell was running with psmouse.resetafter=0, though. All that patch does is automate setting resetafter=0.

The long-term solution for modern Linux is to run the soundcard in I2S mode and the touchpad in I2C mode. The touchpad already works well in I2C mode with patches in 4.0rc1 (er, I think; maybe it's just in master and didn't quite make rc1). The soundcard I2S work is ongoing. Dell is working on the HDA + PS/2 option because they want to support the kernel used in Ubuntu 14.04 LTS, to which it would be very hard to backport the required I2S support. They're also working on some BIOS/embedded controller firmware fixes which will likely improve the situation for the HDA + PS/2 option.

So I expect this hardware will be well supported soon, given Dell's commitment of resources plus ongoing work by other hardware companies and outside developers.

For documentation purposes...

Up until yesterday I was using kernel 3.17.4-301.fc21. There were no command extra command line parameters. I had not installed xorg libinput.

That combination worked pretty well, far better than the current version I described above.

I install kernels pretty much directy out of koji as they come out, so using 4.0.0-0.rc1.git1.1.fc23.x86_64. I'll watch for patches in the kernel.org git and update here if there are any changes.

darrell: btw, the lost sync messages are still normal with resetafter=0. It just means the driver won't reset due to errors and hence you won't have a long freeze while it does so.

Applied the just released A01 BIOS update.

The problems are fixed.

(kernel 4.0rc1, with both the command line parameters)

Re #52. The sync error messages still appear in the kernel messages but at least the freezes are gone. At some point it might be a good idea to hush the messages since they appear very frequently.

kernel-3.18.8-201.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/kernel-3.18.8-201.fc21

kernel-3.18.8-100.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.18.8-100.fc20

Package kernel-3.18.8-100.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.18.8-100.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-2990/kernel-3.18.8-100.fc20
then log in and leave karma (feedback).

kernel-3.18.8-201.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

kernel-3.18.9-100.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.18.9-100.fc20

kernel-3.18.9-100.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

I'm having having the same intermittent issue with my XPS 9350 in Fedora 23, kernel 4.4.6. The touchpad keeps freezing. This usually happens when I'm using two-finger scrolling, although it happens when that feature is disabled also. When it happens, the cursor is locked into scrolling mode and only the touchpad buttons and keyboard work. I have to play around with a combination of button presses or restart to fix it.

Will the patches above work for me? I'm on the newer Dell XPS 9350, 4.4.6-300.fc23.x86_64.

Andrew: I am seeing the same thing. I plan to triage it a bit.

I experience this issue from time to time on Fedora 26.