Tools to debug a broken input device (original) (raw)

Benjamin Tissoires

2015-09-16

who am I?

bentiss on freenode, gimpnet
benjamin.tissoires@{gmail|redhat}.com
mostly working on kernel input drivers (hid-multitouch, i2c-hid, hid-logitech-dj, hid-logitech-hidpp, wacom revamp)
working at Red Hat

General problem: input bug reports

To: linux-input@vger.kernel.org
Date: back in April
Subject: PROBLEM: Touchpad works just like a mouse

[1.] Touchpad works just like a mouse.

[2.] Touchpad features like scrolling, tapping, etc. do not work at all. Also, I cannot disable touchpad, even if I try to do it using special key functions (fn) for notebooks. Touchpad multitouch gestures doesn't work. It's simple to reproduce. I just boot my Linux system and I try to use my touchpad. System doesn't recognize it as a touchpad 8 (I cannot enable touchpad functions). My notebook model is ASUSTeK COMPUTER INC. PU551LA.

General problem: input bug reports

Triage:

Yep, it doesn't work.
????

Can we do something better?

the input layers

kernel or libinput?

evemu

http://www.freedesktop.org/wiki/Evemu/

shows the output of the kernel
can be replayed
sudo evemu-record

If the kernel is doing OK, most of the time, you blame Peter :)

kernel is OK

libinput-debug-events

shows the events as processed by libinput
bundled with libinput
sudo libinput-debug-events

then you talk to Peter

The kernel fails

Many reasons

The kernel can send garbage:

the ~~user~~ device goes insane
there is room for interpretation
there are bugs in the drivers

bug in the driver (commit e9e8520f229....)

Put one, two, three, two fingers down.

E: 0.000000 0001 014a 0001      # EV_KEY / BTN_TOUCH            1
E: 0.000000 0001 0145 0001      # EV_KEY / BTN_TOOL_FINGER      1
E: 0.770008 0001 0145 0000      # EV_KEY / BTN_TOOL_FINGER      0
E: 0.770008 0001 014d 0001      # EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 1.924716 0001 014d 0000      # EV_KEY / BTN_TOOL_DOUBLETAP   0
E: 1.924716 0001 014e 0001      # EV_KEY / BTN_TOOL_TRIPLETAP   1

.. changing from 3 to 2 fingers now

E: 3.152641 0001 014a 0000      # EV_KEY / BTN_TOUCH            0
E: 3.152641 0001 014d 0001      # EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 3.152641 0001 014e 0000      # EV_KEY / BTN_TOOL_TRIPLETAP   0
E: 3.176948 0001 014a 0001      # EV_KEY / BTN_TOUCH            1

So the kernel fails

Know your enemy

physical layers:

PS/2	I2C	SMBus	USB	Bluetooth	serial

protocols:

public	HID, psmouse
semi-public	RMI4, HID++ 2.0
proprietary	reverse-engineered, documentation under NDA

Know your enemy (continued)

Combinations:

RMI4 over HID over I2C
PS/2 over RMI4 over SMBus
HID++ over HID over DJ over HID over USB
WTF over GTFO over SNAFU

Finding out which bus/protocol is used

PS/2	I2C	SMBus	USB	Bluetooth	serial

=> dmesg | grep input:

[19679.866042] input: Logitech MX Master as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.2/0003:046D:C52B.0008/0003:046D:4041.0009/input/input15

[19679.866630] logitech-hidpp-device 0003:046D:4041.0009: input,hidraw1: USB HID v1.11 Keyboard [Logitech MX Master] on usb-0000:00:14.0-2:1

USB

usbmon

shows the output
good luck replaying it
sudo cat /sys/kernel/debug/usb/usbmon/1u

Other transport layers

we will figure it out

Wrapping up

Reporting an input bug

provide a full dmesg (not just an excerpt)
provide an evemu-record of the bug triggering
do not be afraid if we ask for additional different recordings (hid, PS/2, usbmon, etc)

Reporting an input bug

provide a full dmesg (not just an excerpt)
provide an evemu-record of the bug triggering
do not be afraid if we ask for additional different recordings (hid, PS/2, usbmon, etc)