Hi, We're working with a new consumer laptop product based on Intel Amber Lake (Intel Core m3-8100Y). Unfortunately the hid-multitouch touchpad is not working right - when using the touchpad there are lots of cursor jumps, and libinput also complains that it's detected/ignored several jumps every second. This has been reproduced on Linus git as of yesterday. I: Bus=0018 Vendor=04f3 Product=30ce Version=0100 N: Name="ELAN1201:01 04F3:30CE Touchpad" P: Phys=i2c-ELAN1201:01 S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-5/i2c-ELAN1201:01/0018:04F3:30CE.0002/input/input18 U: Uniq= H: Handlers=mouse0 event15 B: PROP=5 B: EV=1b B: KEY=e520 10000 0 0 0 0 B: ABS=2e0800000000003 B: MSC=20 Full boot log: https://gist.github.com/dsd/cf411da3f4b84bfbc3871bd7915a7bce The touchpad has ACPI HID ELAN1201 and HID ID 04F3:30CE. We've worked with other products with the same HID & ID before, so my initial thinking is that this is a platform-level problem, especially given the newness of Amber Lake in consumer products and similar bugs that we've faced with brand-new platforms in the past. The touchpad works fine under Windows 10. The touchpad is probed via ACPI; the _CRS provides an I2C device and a GPIO interrupt. The GPIO interrupt comes off a controller with ACPI HID INT344B driven by pinctrl-sunrisepoint.c: 00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21) Subsystem: ASUSTeK Computer Inc. Sunrise Point-LP Serial IO I2C Controller [1043:18b1] When using the touchpad, interrupts are raised and then i2c_hid_get_input() will read data that is not in the form you would expect... - The 16-byte input reports are almost always duplicated. That is, right after an input report is read, another interrupt arrives and the exact same 16 byte report is read back again. - After an input report is read (and usually for the 2nd time as it gets duplicated), between 0 and 4 further interrupts arrive, but the i2c request here returns 0 bytes of data, as if the interrupts are spurious - Especially when holding your finger on the touchpad for more than an instant, within the data stream there will occasionally be 16 byte input reports read that are entirely 0xff bytes Is there any awareness of issues like this on the new Amber Lake platform? If not, hopefully this mail acts as a useful first step towards a solution. Suggestions appreciated! Thanks Daniel
