Problem: Touchscreen (SP3) stops sending events

Hi folks,

I've found a reproducable problem where the touchscreen stops sending events.

The touchscreen is a NTRG (1b96:1b05) inside of a MS Surface Pro 3 and
the i2c-hid reports errors at bootup:

[   43.744915] i2c_hid i2c-NTRG0001:01: error in i2c_hid_init_report
size:9 / ret_size:0
[   43.745280] i2c_hid i2c-NTRG0001:01: error in i2c_hid_init_report
size:5 / ret_size:0
[   43.745661] i2c_hid i2c-NTRG0001:01: error in i2c_hid_init_report
size:5 / ret_size:259
[   43.746110] i2c_hid i2c-NTRG0001:01: error in i2c_hid_init_report
size:8 / ret_size:259
[   43.746706] i2c_hid i2c-NTRG0001:01: error in i2c_hid_init_report
size:15 / ret_size:259
[   43.747372] i2c_hid i2c-NTRG0001:01: error in i2c_hid_init_report
size:4 / ret_size:0
[   43.755432] i2c_hid i2c-NTRG0001:01: error in i2c_hid_init_report
size:63 / ret_size:0
[   43.755845] i2c_hid i2c-NTRG0001:01: error in i2c_hid_init_report
size:7 / ret_size:0
[   43.755898] input: NTRG0001:01 1B96:1B05 Pen as
/devices/pci0000:00/INT33C3:00/i2c-10/i2c-NTRG0001:01/0018:1B96:1B05.0005/input/input7
[   43.756058] input: NTRG0001:01 1B96:1B05 as
/devices/pci0000:00/INT33C3:00/i2c-10/i2c-NTRG0001:01/0018:1B96:1B05.0005/input/input8
[   43.756181] hid-multitouch 0018:1B96:1B05.0005: input,hidraw3:
<UNKNOWN> HID v1.00 Mouse [NTRG0001:01 1B96:1B05] on

Though, I've read that such messages are not fatal.

I can see events floating in (with evemu-record), until I do something
uncoordinated, any combination of:
- touch the screen randomly with all fingers
- put one hand completly on the screen, move it, lift fingers
- but both hands on the screen

Usually, after a few seconds, evemu-record doesn't proceed - no more
events are coming from the device. Only a reboot recovers it.
If I set i2c_hid.debug=1, I can see that i2c-hid still gets input, as
the "input: ..." debug messages appear.

Just digged a little bit deeper and hacked into
input_mt_get_slot_by_key(). With the attached patch, I can see that
all slots are active, but none is in use, and we search for a none
existing key. In such a case input_mt_get_slot_by_key() returns -1.
[  100.088510] input input8: input_mt_get_slot_by_key: XXX: All slots
active, none in use, searched for key:78, mt->frame:301
[  100.088515] input input8: input_mt_get_slot_by_key: XXX: slot[0]
key:64 frame:290
[  100.088517] input input8: input_mt_get_slot_by_key: XXX: slot[1]
key:74 frame:300
[  100.088519] input input8: input_mt_get_slot_by_key: XXX: slot[2]
key:65535 frame:275
[  100.088520] input input8: input_mt_get_slot_by_key: XXX: slot[3]
key:66 frame:291
[  100.088522] input input8: input_mt_get_slot_by_key: XXX: slot[4]
key:54 frame:266
[  100.088524] input input8: input_mt_get_slot_by_key: XXX: slot[5]
key:67 frame:293
[  100.088525] input input8: input_mt_get_slot_by_key: XXX: slot[6]
key:69 frame:290
[  100.088527] input input8: input_mt_get_slot_by_key: XXX: slot[7]
key:75 frame:300
[  100.088528] input input8: input_mt_get_slot_by_key: XXX: slot[8]
key:71 frame:293
[  100.088530] input input8: input_mt_get_slot_by_key: XXX: slot[9]
key:76 frame:300

The key:65535 looks suspicious, but isn't necessary to trigger the bug.

Additionally, the attached patch calls input_mt_drop_unused() if I hit
such a state, which hacks around the problem / keeps the events
floating.

Anyone has a clue, why we end up in such a state? Do you need more logs, which?


Cheers,
    Daniel Martin