Bug 1090161
| Summary: | Missing ButtonPress event on some boots with hid-rmi driver | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Abrahm Scully <abrahm.scully> |
| Component: | kernel | Assignee: | Benjamin Tissoires <btissoir> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | abrahm.scully, btissoir, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | kernel-3.14.4-100.fc19 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-05-10 03:20:01 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
Abrahm Scully
2014-04-22 19:10:24 UTC
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. |