Created attachment 888631 [details] dmesg of problem boot with i2c_hid.debug=1 Description of problem: On some boots, ButtonPress and ButtonRelease events are missing with Synaptic touchpad on a Dell XPS 13 after recent hid-rmi driver. Version-Release number of selected component (if applicable): kernel 3.14.1-200.1.fc20.x86_64 (Kernel from koji built with V1 of patch for bug 1089583). How reproducible: Every two to six boots. Steps to Reproduce: 1. Reboot until clicks don't register. Actual results: Clicks don't work. xinput test-xi2 doesn't mention ButtonPress/ButtonRelease events. Expected results: Clicks should work. Additional info:
Created attachment 888632 [details] hid-recorder output hid-recorder output of a single click while the clicks aren't working.
Created attachment 888633 [details] evemu-record output evemu-record output of a single click while clicks aren't working.
Created attachment 888648 [details] Xorg.0.log with clicks broken
Created attachment 888649 [details] Xorg.0.log with clicks working
The touchpad appears to be detected twice. Once as "DLL060A:00 06CB:2734", which appears to be the hid-rmi interface, and once as "SynPS/2 Synaptics TouchPad". In Xorg.0.log, the line: "(II) synaptics: DLL060A:00 06CB:2734: found clickpad property" only appears when clicking works.
Abrahm, it looks like the driver does not detect the buttons and so it does not set the clickpad property. I am wondering if this is a hardware problem. Unfortunately, the prototype I have here sends different data when probing it, so I'd like you to also post a dmesg with i2c_hid.debug=1 when the touchpad is working fine. This way, I should be able to spot if the device sends sometimes the feature or not, or if it is a bad driver implementation.
Created attachment 889049 [details] dmesg with buttons working and i2c_hid.debug=1
Thanks, I have now located the problem: after filtering and cleaning, the working version shows: - Read 0x14 from register 0x0045 i2c_hid i2c-DLL060A:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 45 00 14 ... - Received 14 bytes i2c_hid i2c-DLL060A:00: input: 20 00 0b 14 78 00 19 19 00 10 e6 0f a8 09 ... - Write page 0x01 i2c_hid i2c-DLL060A:00: __i2c_hid_command: cmd=25 00 17 00 09 01 ff 00 01 ... *unexpected incoming report of size 4* i2c_hid i2c-DLL060A:00: input: 20 00 0b 04 05 2f 4f 09 00 00 00 00 00 00 ... hid-rmi 0018:06CB:2734.0002: no read request pending * normal process of query f30 * - Read 2 bytes from register 0x0182 i2c_hid i2c-DLL060A:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 82 01 02 ... - Received 2 bytes i2c_hid i2c-DLL060A:00: input: 20 00 0b 02 28 03 19 19 00 10 e6 0f a8 09 ... - Read 2 bytes from register 0x016e i2c_hid i2c-DLL060A:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 6e 01 02 ... - Received 2 bytes i2c_hid i2c-DLL060A:00: input: 20 00 0b 02 00 04 19 19 00 10 e6 0f a8 09 ... While the non-working version assumes the unexpected report to be the answer to the query: - Read 0x14 from register 0x0045 i2c_hid i2c-DLL060A:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 45 00 14 ... - Received 14 bytes i2c_hid i2c-DLL060A:00: input: 20 00 0b 14 78 00 19 19 00 10 e6 0f a8 09 ... - Write page 0x01 i2c_hid i2c-DLL060A:00: __i2c_hid_command: cmd=25 00 17 00 09 01 ff 00 01 ... * normal process of query f30 * - Read 2 bytes from register 0x0182 i2c_hid i2c-DLL060A:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 82 01 02 ... *unexpected incoming report of size 4* -> wrong answer i2c_hid i2c-DLL060A:00: input: 20 00 0b 04 05 2f 4f 09 00 00 00 00 00 00 ... - Read 4 bytes from register 0x016f i2c_hid i2c-DLL060A:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 6f 01 04 00 ... - Received 4 bytes i2c_hid i2c-DLL060A:00: input: 20 00 0b 04 04 00 00 0c 00 10 e6 0f a8 09 ... I will check with Synaptics to understand why the unexpected report comes here and how we can discard it.
Created attachment 889103 [details] 0001-HID-rmi-do-not-fetch-more-than-16-bytes-in-a-query.patch I got the answer from Synaptics, and it is a FW bug. We can go around it quite easily and I attached a patch for it. I just launched a build, and I would be grateful if you could tell us if this works now. http://koji.fedoraproject.org/koji/taskinfo?taskID=6771661 Also, the possible side effect would be that the reported maximums for X and Y have been modified. It is very unlikely, but having the evemu-record of the device before the patch and after would help to check if nothing has changed on your device.
Created attachment 889344 [details] evemu-record output with working buttons with 3.14.1-200.bz1090161
The touchpad buttons have been detected reliably with the 3.14.1-200.bz1090161.fc20.x86_64 kernel. I have only booted a handful of times.
I checked on your log and and the reported maximums for X and Y did not changed with the new patch. Patch sent upstream: https://patchwork.kernel.org/patch/4055781/
Where is the correct place to request that this patch be integrated into the official Fedora kernels that have the backported hid-rmi driver? I have had no issues with 3.14.1-200.bz1090161.fc20.x86_64, but I'd prefer to run an official Fedora kernel.
My bad. I sent this and thought I would ping the Fedora kernel maintainers once it will land upstream. Unfortunately, I did not got any reply from the HID maintainer, and I forgot to ask Fedora. I am on it.
I should have seen this as well. I'll get to it soon.
Patch added to Fedora git. It will be in the next builds on the various releases.
kernel-3.14.3-200.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.14.3-200.fc20
Package kernel-3.14.3-200.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.14.3-200.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6122/kernel-3.14.3-200.fc20 then log in and leave karma (feedback).
kernel-3.14.3-100.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.14.3-100.fc19
This kernel seems to work well.
kernel-3.14.3-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.14.4-100.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.14.4-100.fc19
kernel-3.14.4-100.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.