Bug 94281 - Synaptics Touchscreen Stops Getting Detected
Summary: Synaptics Touchscreen Stops Getting Detected
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Drivers/I2C virtual user
Depends on:
Reported: 2015-03-04 19:32 UTC by Jianlong Liu
Modified: 2016-01-01 22:51 UTC (History)
8 users (show)

See Also:
Kernel Version: 3.19-4.3
Tree: Mainline
Regression: Yes

3.18.8 dmesg, working touchscreen (73.17 KB, application/octet-stream)
2015-03-04 19:33 UTC, Jianlong Liu
4.0 dmesg, touchscreen not working (72.16 KB, application/octet-stream)
2015-03-04 19:33 UTC, Jianlong Liu
Patch that broke Synaptics touchscreen/stylus (1.75 KB, text/plain)
2015-03-20 02:37 UTC, Jianlong Liu

Description Jianlong Liu 2015-03-04 19:32:33 UTC
I am running Arch, currently on 3.18.8.
Touchscreen gets detected as SYNA7500:00 06CB:3AF0 and has entries in /sys as

However, as soon as I upgrade to either 3.19 or 4.0, the only present ones become /sys/bus/acpi/devices/SYNA7500:00
the others just never appear.

Running udev info  on the last entries on 3.18.8 and 4.0 showed no difference, so it looks to be i2c related?

If it helps to pinpoint the problem, doing a find on INT33C3 (I'll check the directory structures in a bit) both resulted in

I have glanced through dmesg (attached), but don't see anything that stands out.

Note that it might be related to bug 91281, but this appears to be a regression from 3.18.x.
Comment 1 Jianlong Liu 2015-03-04 19:33:05 UTC
Created attachment 169031 [details]
3.18.8 dmesg, working touchscreen
Comment 2 Jianlong Liu 2015-03-04 19:33:29 UTC
Created attachment 169041 [details]
4.0 dmesg, touchscreen not working
Comment 3 Jianlong Liu 2015-03-04 19:49:21 UTC
As far as I can tell, the only difference in directory structures in /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C3:00/SYNA7500:00 are the two links (present in 3.18.8, missing in 4.0)
lrwxrwxrwx  1 root root    0 Mar  4 11:43 physical_node -> ../../../../../pci0000:00/INT33C3:00/i2c-9/i2c-SYNA7500:00
lrwxrwxrwx  1 root root    0 Mar  4 11:43 physical_node1 -> ../../../../../pci0000:00/INT33C3:00/i2c-9/i2c-SYNA7500:00/0018:06CB:3AF0.0002

There's no difference for the existing INT33C3:00.
Comment 4 Konstantin K. 2015-03-11 08:51:02 UTC
I can confirm this.
Dell Venue Pro 11 7130.

Gentoo 3.18.9 - touchscreen working (but in my case I need reload i2c_designware_platform for appear new input device (such as /sys/devices/pci0000:00/INT33C3:00/i2c-9/i2c-SYNA7500:00)).

Gentoo 3.19.1 - touchscreen not work.
if try reload i2c_designware_platform I get this in dmesg:
i2c_designware INT33C3:00: Unknown Synopsys component type: 0xffffffff
Comment 5 Jianlong Liu 2015-03-11 16:28:46 UTC
I guess I forgot to mention, mine is a Dell Venue 11 Pro 7130 as well.
Comment 6 Jianlong Liu 2015-03-20 02:35:58 UTC
I finished bisecting earlier today, and just compiled a kernel from latest upstream source with the (following) problematic patch reverted, and the touchscreen/stylus works again!
Comment 7 Jianlong Liu 2015-03-20 02:37:14 UTC
Created attachment 171321 [details]
Patch that broke Synaptics touchscreen/stylus
Comment 8 axfelix 2015-05-13 05:07:00 UTC
Any progress on getting this upstream? I just came here to report this bug (also on a Venue 11 Pro, also on Arch, have locked kernel version at 3.18 for the past couple months as a result) and pleased to see that the problematic patch has apparently already been identified.
Comment 9 axfelix 2015-07-05 20:43:18 UTC
Any update? Maybe bump this to 4.2 so it gets looked at?
Comment 10 axfelix 2015-09-08 02:26:13 UTC
Bump to 4.3? What exactly is the process for getting this reverted upstream?
Comment 11 Alexander Diewald 2015-11-02 12:06:50 UTC
For me personally, I have made some small patch that reverts the problematic change and applies the original patch from the Nvidia engineer, which works without problems for a while now. Luckily, Gentoo supports automatic patching of packages.
I proposed this change to the acpi mailing list, but I did not receive a response:
Comment 12 axfelix 2015-11-05 03:36:23 UTC
Well, I got a response, but unfortunately it's of the "this code should work in theory" variety, and I don't have anywhere near the necessary experience with kernel drivers to try to make a case as to why we should just revert it. Anyone else in this thread want to try to jump in on the mailing list?

Comment 13 Jack K. 2015-11-10 01:23:18 UTC
I tried the patch on kernel 4.2.3
i did not work. Not recognized in dmesg.
Comment 14 Jianlong Liu 2015-11-11 13:12:44 UTC
I got around to trying the patch (I reverted the one I linked, then used that patch), and it didn't work for me either in 4.3.
Comment 15 Jack K. 2015-11-12 09:30:53 UTC
tried out 3.19 patched - not working
Comment 16 Peter Hunt 2015-11-24 17:10:55 UTC
The patch tries to remove synchronize_rcu_exhibited() in the original code, causing the hunk to fail, as this should be synchronize_rcu_expedited().
Comment 17 Peter Hunt 2015-11-24 20:41:37 UTC
There's also a problem with the second hunk, the last line should read

 void __iomem *acpi_os_get_iomem(acpi_physical_address phys, unsigned int size)

(i.e. all on one line). At the moment "size)" is on a new line on its own, which causes the patch to stop at this point and the remainder not to be applied.
Comment 18 Jianlong Liu 2016-01-01 22:51:07 UTC
Appears to be fixed in 4.4!

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