Intel Amber Lake I2C/GpioInt issue, ELAN touchpad unusable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux