Bug 195949 - Dell XPS 13 9333 left/right clicks not working with Linux 4.11.x
Summary: Dell XPS 13 9333 left/right clicks not working with Linux 4.11.x
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
Depends on:
Reported: 2017-05-31 23:41 UTC by Britt Yazel
Modified: 2017-08-05 14:24 UTC (History)
10 users (show)

See Also:
Kernel Version: 4.11.x
Regression: No
Bisected commit-id:

dmesg after cold boot on kernel 4.11.3 (49.22 KB, text/plain)
2017-06-06 13:11 UTC, Aaron
Xorg log after cold boot 4.11.3 (24.41 KB, text/plain)
2017-06-06 13:13 UTC, Aaron
Workaround via delay (716 bytes, patch)
2017-06-06 21:23 UTC, Jake Merdich
Details | Diff
4.11 s3203 Workaround F54_QUERY_LEN (416 bytes, patch)
2017-06-19 07:14 UTC, Thomas Maier
Details | Diff

Description Britt Yazel 2017-05-31 23:41:32 UTC
With the update to Linux kernel 4.11.x on Archlinux on my Dell XPS 9333, left and right click events are no longer working. The touchpad itself works fine and tap-to-click works, but the physical left and right clicks don't do anything. This makes it really impossible to use the system for any length of time. Reverting to kernel 4.10.x brought back the left/right clicking, so it seems to be kernel specific.

There are quite a few people reporting this issue on the Archlinux forums, and it seems to be people with XPS 13 9333 laptops, with at least one person with a XPS 13 9343 NOT reporting the issue.

I am guessing there is some device specific regression which is driving this bug.
Comment 1 Britt Yazel 2017-06-02 16:52:14 UTC
It appears that on 4.11.x my laptop is trying to make use of hid_rmi to control the touchpad, whereas on kernels <4.11.x hid_multitouch was used (at least from what I can tell from lsmod).
Comment 2 Aaron 2017-06-06 05:00:01 UTC
I can also confirm on Dell 3542

On kernel 4.10 my touchpad was identified as: 
'DLL0651:00 06CB:2985'
With Synaptics Capabilities (306):   1, 0, 0, 1, 1, 1, 0

On kernel 4.11 my touchpad was identified as:
Device 'Synaptics s3203':
With Synaptics Capabilities (307):   0, 0, 0, 1, 1, 1, 0

I think the regression 1st appeared in v4.11-rc1

HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4
HID: rmi: Handle all Synaptics touchpads using hid-rmi
HID: rmi: fallback to generic/multitouch if hid-rmi is not built
Comment 3 Benjamin Tissoires 2017-06-06 08:08:10 UTC
That's weird. "HID: rmi: Handle all Synaptics touchpads using hid-rmi" has been reverted in 84379d83d8e536aef2c and it has been shipped since v4.11-rc7. Looking at the code in v4.11.3 shows that the faulty commit has been reverted and you still should be using hid-multitouch.

Are you using a vanilla v4.11.x or one shipped by your distribution?
Comment 4 Aaron 2017-06-06 13:01:03 UTC
4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux

I didn't know it had been reverted, I was on Opensuse tumbleweed until they reached the 4.11 (when the regression started)
Hopped on to Ubuntu 17.10 thinking it was a distro bug and the same thing happened on 4.11, (I tried the v4.11-rc1 to see when the regression began and it was that kernel)

I started using Antergos.
Comment 5 Aaron 2017-06-06 13:11:14 UTC
Created attachment 256879 [details]
dmesg after cold boot on kernel 4.11.3
Comment 6 Aaron 2017-06-06 13:13:59 UTC
Created attachment 256885 [details]
Xorg log after cold boot 4.11.3
Comment 7 Jake Merdich 2017-06-06 21:23:13 UTC
I have the same issue on my Dell 9Q33 (similar innards to 9333). After bisecting, the issue does indeed appear after the introduction of hid_rmi. It seems that the f54 probe has a race condition that corrupts a future read, and when the probing tries to read the next function's data, it gets a garbled mess.

I'm attaching a hacky patch as a workaround while I look into the root cause, can you try it on a 9333?
Comment 8 Jake Merdich 2017-06-06 21:23:52 UTC
Created attachment 256895 [details]
Workaround via delay
Comment 9 Tomi Leppänen 2017-06-10 19:30:39 UTC
I confirm that the patch helps on 9333 too. I applied it to v4.11 and now my touchpad has clickfinger listed as click method in libinput-list-devices output and I can click by pressing the touchpad. This is on Dell XPS 13 model 9333.
Comment 10 Andrew Duggan 2017-06-14 19:39:41 UTC
Yes, it does sound like the F54 probe maybe causing an issue here. There have been previous problems with the 9333 i2c bus. We even have a function which was added to hid-rmi called rmi_check_sanity() which works around instances where we get incorrect data.

The F54 probe does a a larger then normal read (27 bytes) which results in the response being reported in two consecutive HID reports. It's possible that these two reports are causing an issue. It looks like F54 is only looking at the first 6 bytes so we could reduce the size of the read to 6 bytes and get the response in a single report. That might be worth trying just to confirm that this is what is causing the issue.

But, if this system has issues with reading lots of data we should probably just disable F54 for this device. F54 is used for diagnostics and tries to read hundreds of bytes when it is being used. We can add a flag to prevent it from loading.
Comment 11 Jake Merdich 2017-06-14 20:00:00 UTC
Can confirm that both changing F54_QUERY_LEN to 6 and disabling the f54 outright result in proper behavior on my 9q33. Either would work as a fix.
Comment 12 Thomas Maier 2017-06-15 16:15:13 UTC
I also can confirm that setting F54_QUERY_LEN to 6 'fixed' the issue on my XPS 9333. The touch pad works sometimes without any modifications (In like 1 out of 10 boots), so this seems to be a timing problem.
Comment 13 Andrew Duggan 2017-06-17 00:22:26 UTC
OK, thanks for testing. I will prepare a patch that limits the reads in F54 to 6 bytes.
Comment 14 allen832008 2017-06-18 16:04:40 UTC
I am having the same issues on a Dell Latitude E7270 running Fedora 25. Two finger scrolling also seems to drop off intermittently and have a delay as well. Could anyone tell me how to install the patch? I am not very familiar with Bugzilla.
Comment 15 Jake Merdich 2017-06-18 16:45:52 UTC
The easiest way to fix this is to simply disable the RMI4_F54 option in your kernel config, no patch needed (though you must still rebuild it). As it stands, F54 won't work right on our machines without some more extensive quirks anyways.

I haven't been experiencing the two-finger scrolling issue though, so YMMV.
Comment 16 Thomas Maier 2017-06-19 07:14:29 UTC
Created attachment 257071 [details]
4.11 s3203 Workaround F54_QUERY_LEN
Comment 17 Thomas Maier 2017-06-19 07:17:30 UTC
You can apply this: https://bugzilla.kernel.org/attachment.cgi?id=257071&action=diff patch with:
patch -p1 -i "${srcdir}/4.11_s3203_workaround.patch" and rebuild your kernel afterwards.
Comment 18 Andrew Duggan 2017-06-20 23:46:51 UTC
I posted my version of the patch to the kernel mailing list:
Comment 19 Britt Yazel 2017-06-27 04:18:03 UTC
Any chance that this fix will make it into a 4.11.x release? I'd hate to wait till 4.12 to have a working touchpad
Comment 20 Teo Sakel 2017-08-05 14:24:56 UTC
Problem fixed in 4.12.x but now the touchpad is disabled after suspend.
(touchscreen working fine)

[  226.363005] hid-rmi 0018:06CB:2734.0001: rmi_hid_read_block: timeout elapsed
[  227.376382] hid-rmi 0018:06CB:2734.0001: rmi_hid_read_block: timeout elapsed
[  228.389699] hid-rmi 0018:06CB:2734.0001: rmi_hid_read_block: timeout elapsed
[  229.402955] hid-rmi 0018:06CB:2734.0001: rmi_hid_read_block: timeout elapsed
[  230.416357] hid-rmi 0018:06CB:2734.0001: rmi_hid_read_block: timeout elapsed
[  230.416363] rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask.
[  230.416377] dpm_run_callback(): i2c_hid_resume+0x0/0xf0 [i2c_hid] returns -11
[  230.416385] PM: Device i2c-DLL060A:00 failed to resume async: error -11
[  230.416478] PM: resume of devices complete after 5193.346 msecs

Don't know if it's a coincidence thought.
Other people experienced it with 4.11.x as well:

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