My trackpad seems to be acting up today on Archlinux after updating to Linux 4.11 (though I'm not sure if that is just a coincidence or not). My touchpad on my Dell xps 13 used to feel great, and I could click and drag without any issues. However, since booting the first time after updating, any time I left or right click, it seems to disable touchpad input and the cursor will not respond anymore. This completely breaks clicking and dragging, and is overall very annoying
Yep it seems to be specific with Kernel 4.11.x, as rolling back to 4.10.11 fixes this issue.
Any chance you can bisect the kernel to find the issue? Benjamin, are you aware of it already?
Sorry peter, I think that's probably a bit outside my skill level :-/ If someone can walk me through it I can try, or I'm otherwise willing to give you guys whatever other info you need. Were there any Dell XPS driver updates with this kernel that might be causing this? I posted a question on reddit asking if other people were experiencing this and people with newer XPS 13 laptops than mine (the 2014 9333 model) said they were not experiencing the problem.
Strange, I cleared my package cache and redownloaded the new Linux kernel and upon booting this problem appears to be gone. I don't know what exactly happened from wednesday until today, but this seems to have cleared itself up
I take it back, I hadn't rebooted. After rebooting the issue is still present
I found this as far as changes to the synaptics driver in 4.11: https://patchwork.kernel.org/patch/9622411/ Further, the more I play with this issue the more I am figuring it out. The issue isn't that clicking disables moving the cursor, *the issue is actually that left and right clicks are not working at all*. Hence, left clicking and dragging my finger stops the cursor moving because it is treating it as two finger scrolling. In chrome, when I try to click and drag, it scrolls the page instead.
Bisecting a kernel is easier than you'd expect, at least the basic approach: https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/bug-bisect.html I suspect the biggest difficulty is figuring out what to do with builds that don''t build but you can do a git bisect skip on those. Plus, there's a high chance you can narrow the bisect to drivers/input, which should only give you a few revisions to look at. Attach an evemu-record of such a sequence though with a broken kernel, that should pinpoint what the problem is, which then may show what the cause could be.
Alright, with the update to 4.11.3 it seems like this issue has been worked out. Clicking seems to be working again
Strange everything was fine for about an hour, and while watching a youtube video my left/right clicking stopped working. Rebooting and the issue persisted through the reboot
Could you attach an evemu-record of your touchpad while exposing the bug, and also a dmesg after a start so we can see which driver is used. IIRC, 4.11 on these laptops should still be using hid-multitouch (like in v4.10) as we had some troubles with hid-rmi.
Yes I will get you that info asap. However, in the meanwhile, this is the bug report opened for archlinux https://bugs.archlinux.org/task/54178, where one of the users with the problem reported that with 4.11 a new module is being reported "rmi_core". Do you think that the touchpad is incorrectly using hid-rmi?
Ok interesting, on 4.10.x my device is using hid_multitouch like you had stated, but on 4.11.x my device is using hid_rmi according to lsmod. You said hid_rmi was buggy? What could be causing us to use hid_rmi?
https://bugzilla.kernel.org/show_bug.cgi?id=195949 This upstream bug has an individual who did a kernel bisect
Oh, good, thanks. let's move this to the kernel bug then. No point having a bug open here and benjamin is also cc'd on the kernel bug anyway.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.