Touch input not working after IPTS reset (0x80000005 failed status = 11)

kitakar5525 commented 5 years ago

Sometimes IPTS will reset itself on Chromium OS:

kern  :err   : [ 1494.058680] ipts mei::3e8d0870-271a-4208-8eb5-9acb9402ae04:0F: 0x80000005 failed status = 11
kern  :info  : [ 1494.058688] DEBUG: ipts_stop called
kern  :info  : [ 1494.058692] DEBUG: ipts_send_sensor_quiesce_io_cmd called
kern  :info  : [ 1494.059630] DEBUG: ipts_send_sensor_clear_mem_window_cmd called
kern  :info  : [ 1494.061624] DEBUG: ipts_send_sensor_quiesce_io_cmd called
kern  :info  : [ 1494.061832] DEBUG: ipts_start called
kern  :info  : [ 1494.096182] input: ipts 1B96:005E Pen as /devices/pci0000:00/0000:00:16.4/mei::3e8d0870-271a-4208-8eb5-9acb9402ae04:0F/0044:1B96:005E.0004/input/input50
kern  :info  : [ 1494.096869] input: ipts 1B96:005E as /devices/pci0000:00/0000:00:16.4/mei::3e8d0870-271a-4208-8eb5-9acb9402ae04:0F/0044:1B96:005E.0004/input/input51
kern  :info  : [ 1494.097078] input: ipts 1B96:005E UNKNOWN as /devices/pci0000:00/0000:00:16.4/mei::3e8d0870-271a-4208-8eb5-9acb9402ae04:0F/0044:1B96:005E.0004/input/input55
kern  :info  : [ 1494.097767] hid-multitouch 0044:1B96:005E.0004: input,hidraw2: <UNKNOWN> HID v16900.00 Mouse [ipts 1B96:005E] on heci3
kern  :info  : [ 1494.097842] DEBUG: ipts_send_sensor_clear_mem_window_cmd called
kern  :err   : [ 1494.099123] ipts mei::3e8d0870-271a-4208-8eb5-9acb9402ae04:0F: touch enabled 4
kern  :err   : [ 1494.103526] ipts mei::3e8d0870-271a-4208-8eb5-9acb9402ae04:0F: 0x80000005 failed status = 4
kern  :err   : [ 1494.107274] ipts mei::3e8d0870-271a-4208-8eb5-9acb9402ae04:0F: touch enabled 4

However, after the reset, Chromium OS will not recognize the touch input anymore. But IPTS may still be working. You can confirm that by evtest.

So, the issues are:

how to get Chromium OS to recognize the IPTS touch input device again after the reset?
why does the reset (0x80000005 failed status = 11) happen? I've never seen this reset on Arch Linux

kitakar5525 commented 5 years ago

You can reproduce this issue manually by:

echo 1 | sudo tee /sys/kernel/debug/ipts/ipts_stop
echo 1 | sudo tee /sys/kernel/debug/ipts/ipts_start

kitakar5525 commented 5 years ago

# evtest output on Arch Linux
$ evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event0:  Lid Switch
/dev/input/event1:  Video Bus
/dev/input/event2:  Surface Pro 3/4 Buttons
/dev/input/event3:  PC Speaker
/dev/input/event4:  HDA Intel PCH Mic
/dev/input/event5:  HDA Intel PCH Headphone
/dev/input/event6:  HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event7:  HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event8:  HDA Intel PCH HDMI/DP,pcm=8
/dev/input/event9:  HDA Intel PCH HDMI/DP,pcm=9
/dev/input/event10: HDA Intel PCH HDMI/DP,pcm=10
/dev/input/event11: ipts 1B96:005E
/dev/input/event12: ipts 1B96:005E
/dev/input/event13: ipts 1B96:005E UNKNOWN
/dev/input/event14: ipts 1B96:005E
/dev/input/event15: ipts 1B96:005E
/dev/input/event16: ipts 1B96:005E UNKNOWN
/dev/input/event17: ydotoold virtual device
/dev/input/event18: Simulated Right Button
/dev/input/event19: ipts 1B96:005E
/dev/input/event20: ipts 1B96:005E
/dev/input/event21: ipts 1B96:005E UNKNOWN
/dev/input/event22: Microsoft Surface Keyboard
/dev/input/event23: Microsoft Surface Keyboard Consumer Control
/dev/input/event24: Microsoft Surface Keyboard Touchpad
Select the device event number [0-24]: ^C

After ipts_stop/ipts_start cycle, old IPTS devices will not be removed. (11 to 16) This behavior might confuse the Chromium OS.

kitakar5525 commented 5 years ago

Whereas unloading IPTS modules (sudo modprobe -r ipts_surface) will remove old IPTS devices as expected.

kitakar5525 commented 5 years ago

ipts_hid_init() will be called from ipts_handle_resp() [ipts-msg-handler.c] when we load intel_ipts module and it will register hid devices.
ipts_hid_release() will be called from ipts_mei_cl_remove() [ipts-mei.c] when we unload intel_ipts module and it will unregister the hid devices. But not called from ipts_stop()

So, the possible ways to fix I think are:

call ipts_mei_cl_exit() when the reset will take place instead of just calling ipts_stop()
move ipts_hid_release() from ipts_mei_cl_remove() to ipts_stop()

kitakar5525 commented 5 years ago

The flow until `ipts_hid_init()` will be called when we load intel_ipts module:

ipts_mei_cl_probe() 👇 init_work_func() 👇 ipts_start() 👇 send a commend: ipts_handle_cmd(ipts, TOUCH_SENSOR_NOTIFY_DEV_READY_CMD, NULL, 0); 👇 The response (TOUCH_SENSOR_NOTIFY_DEV_READY_RSP) will be caught in ipts_handle_resp() 👇 send a commend: ipts_handle_cmd(ipts, TOUCH_SENSOR_GET_DEVICE_INFO_CMD, NULL, 0); 👇 The response (TOUCH_SENSOR_GET_DEVICE_INFO_RSP) will be caught in ipts_handle_resp() 👇 in the switch statement, ipts_hid_init() will be called

The flow until `ipts_hid_release()` will be called when we unload intel_ipts module:

ipts_mei_cl_exit() 👇 mei_cldev_driver_unregister() 👇 ipts_mei_cl_remove() 👇 (ipts_stop() will also be called, then) ipts_hid_release() will be called

kitakar5525 commented 5 years ago

So, more concisely,

ipts_mei_cl_probe() 👉 ipts_start() 👉 ipts_hid_init()
ipts_mei_cl_exit() 👉 ipts_hid_release()

When considering the fact that ipts_start() will finally call ipts_hid_init(), I'd expect ipts_stop() will also finally call ipts_hid_release(), but it will not.

kitakar5525 commented 5 years ago

I need to confirm next that moving ipts_hid_release() from ipts_mei_cl_remove() to ipts_stop() will really fix this issue after the reset happened.

kitakar5525 commented 5 years ago

Or adding ipts_hid_release() to ipts_restart() may be another option.

kitakar5525 commented 4 years ago

Fortunately, I don't see this issue for a long time. Closing for now.

kitakar5525 / chromeos-kernel-linux-surface