Bug 1188439 - Dell XPS 13 9343 (2015) touchpad freeze
Summary: Dell XPS 13 9343 (2015) touchpad freeze
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Benjamin Tissoires
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-02 22:04 UTC by Major Hayden
Modified: 2017-10-26 15:34 UTC (History)
24 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-03-09 08:16:48 UTC


Attachments (Terms of Use)
evemu-record output (296.10 KB, text/plain)
2015-02-04 03:14 UTC, Major Hayden
no flags Details
unmodified F21 xorg logs from 2015-02-04 (98.78 KB, text/plain)
2015-02-05 00:20 UTC, Major Hayden
no flags Details
dmesg output with i2c debug (57.34 KB, text/plain)
2015-02-10 02:27 UTC, Major Hayden
no flags Details
hid-recorder output (153.05 KB, text/plain)
2015-02-10 02:27 UTC, Major Hayden
no flags Details
Full dmesg including hid-record test (284.31 KB, text/plain)
2015-02-10 02:32 UTC, Major Hayden
no flags Details
0001-HID-multitouch-force-release-of-touches-when-i2c-com.patch (1.49 KB, patch)
2015-02-10 17:43 UTC, Benjamin Tissoires
no flags Details | Diff

Description Major Hayden 2015-02-02 22:04:29 UTC
I've installed Fedora 21 on a Dell XPS 13 9343 (2015 model) and I'm seeing some peculiar trackpad freezes.  I can use the trackpad for a good while but then it will refuse to move around the screen any longer.  Clicks (left, right, and middle) seem to work but the pointer is locked in place.

If I use 'evtest' to monitor the device, I see constant X/Y and button input when I use trackpad (even when the pointer freezes on screen).  However, if I use 'xinput --test' with the device, I do not see any X/Y input (only clicks) in the terminal.  If I keep mashing the touchpad with different finger combinations, the device will eventually start working again.

Could this be a possible problem in the X driver for synaptics since the kernel still sees activity with evtest?

This happens under kernels 3.17.4, 3.18.3, and 3.18.5.  I've tried xorg-x11-drv-synaptics-1.8.1-2.fc21 from updatest-testing but it has no impact.

$ xinput --list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Logitech Unifying Device. Wireless PID:101a	id=12	[slave  pointer  (2)]
⎜   ↳ ELAN Touchscreen                        	id=13	[slave  pointer  (2)]
⎜   ↳ DLL0665:01 06CB:76AD UNKNOWN            	id=15	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=17	[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)]
    ↳ Apple Inc. Apple Keyboard               	id=10	[slave  keyboard (3)]
    ↳ Apple Inc. Apple Keyboard               	id=11	[slave  keyboard (3)]
    ↳ Integrated_Webcam_HD                    	id=14	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=16	[slave  keyboard (3)]
    ↳ Dell WMI hotkeys                        	id=18	[slave  keyboard (3)]

$ lsmod | grep hid
hid_rmi                17521  0 
hid_multitouch         17419  0 
i2c_hid                18719  0 
hid_logitech_dj        18447  0

Comment 1 Major Hayden 2015-02-02 22:40:06 UTC
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.

Comment 2 Peter Hutterer 2015-02-04 00:28:35 UTC
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.

Comment 3 Major Hayden 2015-02-04 03:14:39 UTC
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)

Comment 4 Major Hayden 2015-02-04 03:16:08 UTC
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?

Comment 5 Peter Hutterer 2015-02-04 04:32:57 UTC
(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

Comment 6 Peter Hutterer 2015-02-04 04:46:23 UTC
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.

Comment 7 Major Hayden 2015-02-04 13:08:11 UTC
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.

Comment 8 Niccolò Belli 2015-02-04 14:16:20 UTC
Hi Major, just for curiosity: did you try with xf86-input-libinput instead of evdev/synaptics?

Comment 9 Major Hayden 2015-02-04 14:39:30 UTC
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?

Comment 10 Niccolò Belli 2015-02-04 14:50:01 UTC
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.

Comment 12 Major Hayden 2015-02-04 18:49:23 UTC
That looks easy enough, Niccolò! I'll try it this evening.

Comment 13 Major Hayden 2015-02-05 00:20:26 UTC
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.

Comment 14 Major Hayden 2015-02-05 00:36:24 UTC
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.

Comment 15 Major Hayden 2015-02-05 00:38:23 UTC
It seems like this condition happened before: https://bugzilla.redhat.com/show_bug.cgi?id=877464

Comment 16 Peter Hutterer 2015-02-05 09:46:20 UTC
(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.

Comment 17 Jan Henke 2015-02-05 09:51:50 UTC
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?

Comment 18 Niccolò Belli 2015-02-05 10:06:57 UTC
Major, can you bisect between 3.16 and 3.17?

Comment 19 Major Hayden 2015-02-05 13:09:18 UTC
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. ;)

Comment 20 Peter Hutterer 2015-02-05 21:55:24 UTC
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 ;)

Comment 21 Major Hayden 2015-02-05 21:59:52 UTC
I'll see if I can tinker with libinput and bisect the kernel. ;)

Comment 22 Major Hayden 2015-02-06 03:11:26 UTC
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.

Comment 23 Major Hayden 2015-02-06 13:51:21 UTC
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.

Comment 24 Major Hayden 2015-02-06 22:12:45 UTC
59 patches left in the bisect (started with ~ 6500): https://gist.github.com/major/c3b7c576af32093f39b5

Comment 25 Major Hayden 2015-02-07 04:49:10 UTC
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@chromium.org>
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@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

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.

Comment 26 Ryan Hartlage 2015-02-07 13:57:18 UTC
Would it make sense to simply increase the size of the input buffer?

Comment 27 Peter Hutterer 2015-02-08 21:34:42 UTC
/me lobs it over to Benjamin's court

Comment 28 Ryan Hartlage 2015-02-08 22:19:54 UTC
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?

Comment 29 Major Hayden 2015-02-08 22:34:17 UTC
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.

Comment 30 Ryan Hartlage 2015-02-08 22:59:27 UTC
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.

Comment 31 Benjamin Tissoires 2015-02-09 15:25:22 UTC
(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

Comment 32 Major Hayden 2015-02-10 02:27:00 UTC
Created attachment 989916 [details]
dmesg output with i2c debug

Comment 33 Major Hayden 2015-02-10 02:27:26 UTC
Created attachment 989917 [details]
hid-recorder output

Comment 34 Major Hayden 2015-02-10 02:30:58 UTC
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).

Comment 35 Major Hayden 2015-02-10 02:32:29 UTC
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.

Comment 36 Benjamin Tissoires 2015-02-10 17:43:26 UTC
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.

Comment 37 Major Hayden 2015-02-10 18:09:27 UTC
Thanks, Benjamin.  I'll test out that patch tonight and report back.

Comment 38 Major Hayden 2015-02-10 23:00:28 UTC
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?

Comment 39 me 2015-02-12 18:58:32 UTC
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.

Comment 40 Major Hayden 2015-02-17 21:25:56 UTC
Benjamin -- Any more ideas on how to restore tapping to the pad?

Comment 41 Benjamin Tissoires 2015-02-17 23:27:19 UTC
(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 :(

Comment 42 Niccolò Belli 2015-02-18 17:46:37 UTC
:(

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

Comment 43 Seth Forshee 2015-02-20 16:14:17 UTC
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) {

Comment 44 Benjamin Tissoires 2015-02-20 17:11:44 UTC
(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.

Comment 45 Seth Forshee 2015-02-20 19:27:18 UTC
(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

Comment 46 Josh Boyer 2015-02-23 20:15:34 UTC
I've added the patch from Seth to F20-rawhide.  Thanks!

Comment 47 darrell pfeifer 2015-02-25 15:52:26 UTC
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

Comment 48 Benjamin Tissoires 2015-02-25 16:08:00 UTC
(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 :(

Comment 49 Michael Leuchtenburg 2015-02-25 17:20:06 UTC
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.

Comment 50 darrell pfeifer 2015-02-25 17:34:24 UTC
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.

Comment 51 Michael Leuchtenburg 2015-02-25 18:19:42 UTC
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.

Comment 52 darrell pfeifer 2015-02-25 18:57:23 UTC
Applied the just released A01 BIOS update.

The problems are fixed.

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

Comment 53 darrell pfeifer 2015-02-25 20:25:29 UTC
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.

Comment 54 Fedora Update System 2015-03-02 12:34:28 UTC
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

Comment 55 Fedora Update System 2015-03-02 12:36:15 UTC
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

Comment 56 Fedora Update System 2015-03-04 10:24:43 UTC
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).

Comment 57 Fedora Update System 2015-03-09 08:16:48 UTC
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.

Comment 58 Fedora Update System 2015-03-09 21:13:55 UTC
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

Comment 59 Fedora Update System 2015-03-14 09:15:10 UTC
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.

Comment 60 Andrew Wright 2016-03-27 18:07:59 UTC
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.

Comment 61 Jon Masters 2016-04-12 22:25:02 UTC
Andrew: I am seeing the same thing. I plan to triage it a bit.

Comment 62 Luke Orland 2017-10-26 15:34:03 UTC
I experience this issue from time to time on Fedora 26.


Note You need to log in before you can comment on or make changes to this bug.