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.
Created attachment 169031 [details]
3.18.8 dmesg, working touchscreen
Created attachment 169041 [details]
4.0 dmesg, touchscreen not working
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.
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
I guess I forgot to mention, mine is a Dell Venue 11 Pro 7130 as well.
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!
Created attachment 171321 [details]
Patch that broke Synaptics touchscreen/stylus
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.
Any update? Maybe bump this to 4.2 so it gets looked at?
Bump to 4.3? What exactly is the process for getting this reverted upstream?
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:
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?
I tried the patch on kernel 4.2.3
i did not work. Not recognized in dmesg.
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.
tried out 3.19 patched - not working
The patch tries to remove synchronize_rcu_exhibited() in the original code, causing the hunk to fail, as this should be synchronize_rcu_expedited().
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.
Appears to be fixed in 4.4!