Heya, Just got my Acer Aspire V3-371 back from repair where the synaptics touchpad was replaced by a elan one. Now I noticed that on 4.4-rc1 the new touchpad doesn't respond to input. I was able to bisect it to commit 6d4f5440a3a2bb2e9d0d582bbf98234e9e9bb095 "HID: multitouch: Fetch feature reports on demand for Win8 devices" and reverting it did indeed fix the problem. "dmesg |grep -i hid" shows the following with the patch reverted or on 4.3: err: i2c_hid i2c-ELAN0501:00: error in i2c_hid_init_report size:633 / ret_size:7 err: i2c_hid i2c-ELAN0501:00: error in i2c_hid_init_report size:69 / ret_size:7 info: hid-multitouch 0018:04F3:3010.0001: input: I2C HID v1.00 Mouse [ELAN0501:00 04F3:3010] on i2c-ELAN0501:00 without the revert on 4.4-rc1 the two errors are missing. Thanks a lot, Mirco
(In reply to Mirco Tischler from comment #0) > I was able to bisect it to commit > 6d4f5440a3a2bb2e9d0d582bbf98234e9e9bb095 "HID: multitouch: Fetch feature > reports on demand for Win8 devices" and reverting it did indeed fix the > problem. That is worrisome... I thought this commit would have been safe. > > "dmesg |grep -i hid" shows the following with the patch reverted or on 4.3: > err: i2c_hid i2c-ELAN0501:00: error in i2c_hid_init_report size:633 / > ret_size:7 > err: i2c_hid i2c-ELAN0501:00: error in i2c_hid_init_report size:69 / > ret_size:7 > info: hid-multitouch 0018:04F3:3010.0001: input: I2C HID v1.00 Mouse > [ELAN0501:00 04F3:3010] on i2c-ELAN0501:00 > > without the revert on 4.4-rc1 the two errors are missing. The errors missing are an actual improvement. The fact the touchpad doesn't work isn't :( Could you please attach a dmesg while adding i2c_hid.debug=1 appended to the command line? Also, could you attach a hid recording with hid-record (project hid-replay[1]) of the touchpad? I am interested in both the static part and the dynamic part of it (so please attach it even if no events can be recorded). Thanks! [1] http://bentiss.github.io/hid-replay-docs/
Created attachment 196001 [details] dmesg with i2c_hid.debug=1 on 4.4-rc3
Created attachment 196011 [details] output of 'sudo hid-recorder /dev/hidraw0' with a couple seconds of input
Just to check. When you say the touchpad is nonresponsive, do you have I2C debugging enabled? It produces lots of messages for each touch and might affect responsiveness.
I just enabled i2c debugging (CONFIG_I2C_DEBUG_{CORE,BUS}) now to see if there's anything in there. That's probably the reason for those i2c_designware lines. I can repost without them if needed. But with nonresponsive I mean no reaction whatsoever. I can neither move the mouse pointer nor can I click anything, even though the hidraw recording shows events are generated.
OK. The dmesg also shows that input events are being received by the driver: [ 72.961540] i2c_hid i2c-ELAN0501:00: input: 0b 00 01 00 00 ff 00 00 00 00 00 [ 72.968451] i2c_hid i2c-ELAN0501:00: input: 0b 00 01 00 ff 00 00 00 00 00 00 Unfortunately I don't speak HID protocol that well to be able to say what might be wrong here.
These input events looks like mouse events. Multi-touch events should have far more information than just +-1. The weird part is that I do not think your device should be affected by the change: get_report is called normally for "Contact Max" and "Button Type" (2 times report ID 3, given that the report descriptors declares contact max and button type in the same report). We then correctly send the command to switch it to the proper multitouch mode, and I do not see why the device stays in the mouse emulation mode (ignored by hid-multitouch). Would you mind posting a dmesg of i2c_hid.debug=1 with the reverted patch when it is working? I have the impression I am missing something while reading the logs. And yes, probably resending the faulty dmesg without i2c debugging would help too :)
Created attachment 196051 [details] 4.4-rc3 with i2c_hid.debug=1 and no CONFIG_I2C_DEBUG_*
Created attachment 196061 [details] dmesg with the mentioned patch reverted ontop of 4.4-rc3 and i2c_hid.debug=1
Created attachment 196071 [details] hid-recorder output on 4.4-rc3 with bisected commit reverted
Created attachment 196091 [details] 0001-HID-i2c-hid-fix-debug-output-for-get_report.patch OK, so it looks like we are not sending the correct input mode to the touchpad. In case of the working one, we send 05 00 33 03 06 00 05 00 03 03 03 and the non working one is 05 00 33 03 06 00 05 00 03 00 03 It looks like the debug output is missing the actual answer when you have the faulty commit. Could you apply the attach patched and re dump an output of dmesg with i2c_hid.debug=1? This should hopefully tell us where the error lies. crossing fingers knocking wood...
Created attachment 196101 [details] dmesg of 4.4-rc3 with the supplied patch and i2c_hid.debug=1
Created attachment 196221 [details] 0001-HID-multitouch-fix-input-mode-switching-on-some-Elan.patch OK, I think I got it. I do hope that I am correct here, otherwise the patch will need to be more invasive. Here are the explanations as written in the patch: This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") as the origin of the problem but this commit actually masked 2 firmware bugs that are annihilating each other: The report descriptor declares two features in reports 3 and 5: 0x05, 0x0d, // Usage Page (Digitizers) 318 0x09, 0x0e, // Usage (Device Configuration) 320 0xa1, 0x01, // Collection (Application) 322 0x85, 0x03, // Report ID (3) 324 0x09, 0x22, // Usage (Finger) 326 0xa1, 0x00, // Collection (Physical) 328 0x09, 0x52, // Usage (Inputmode) 330 0x15, 0x00, // Logical Minimum (0) 332 0x25, 0x0a, // Logical Maximum (10) 334 0x75, 0x08, // Report Size (8) 336 0x95, 0x02, // Report Count (2) 338 0xb1, 0x02, // Feature (Data,Var,Abs) 340 0xc0, // End Collection 342 0x09, 0x22, // Usage (Finger) 343 0xa1, 0x00, // Collection (Physical) 345 0x85, 0x05, // Report ID (5) 347 0x09, 0x57, // Usage (Surface Switch) 349 0x09, 0x58, // Usage (Button Switch) 351 0x15, 0x00, // Logical Minimum (0) 353 0x75, 0x01, // Report Size (1) 355 0x95, 0x02, // Report Count (2) 357 0x25, 0x03, // Logical Maximum (3) 359 0xb1, 0x02, // Feature (Data,Var,Abs) 361 0x95, 0x0e, // Report Count (14) 363 0xb1, 0x03, // Feature (Cnst,Var,Abs) 365 0xc0, // End Collection 367 The report ID 3 presents 2 input mode features, while only the first one is handled by the device. Given that we did not checked if one was previously assigned, we were dealing with the ignored featured and we should never have been able to switch this panel into the multitouch mode. However, the firmware presents an other bugs which allowed 6d4f5440 to counteract the faulty report descriptor. When we request the values of the feature 5, the firmware answers "03 03 00". The fields are correct but the report id is wrong. Before 6d4f5440, we retrieved all the features and injected them in the system. So when we called report 5, we injected in the system the report 3 with the values "03 00". Setting the second input mode to 03 in this report changed it to "03 03" and the touchpad switched to the mt mode. We could have set anything in the second field because the actual value (the first 03 in this report) was given by the query of report ID 5. To sum up: 2 bugs in the firmware were hiding that we were accessing the wrong feature.
Created attachment 196231 [details] dmesg of patched system with i2c_hid.debug=1 Yay it's working! This looks quite tricky, you rock! I attached the working dmesg again ftr. Thanks a lot Mirco
Ping. The patch hasn't made it to mainline yet. Is it planned to get this into 4.4?
Nevermind, found Jiri's reponse on the ML[1]. I can live with it going into 4.5. [1] https://www.mail-archive.com/linux-input@vger.kernel.org/msg20700.html
I created an account so I can thank you both. Thank you both very much!