Bug 108481

(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!