i2c_hid_acpi: ELAN2514 touchscreen causes IRQ flood on HP Omnibook X 14 (Lunar Lake)

i2c_hid_acpi: ELAN2514 touchscreen causes IRQ flood on HP Omnibook X 14 (Lunar Lake)

[Dennis Foster]

Hi,

I'm seeing a continuous IRQ flood from the ELAN2514 touchscreen on an HP Omnibook X 14 (Intel Core Ultra 5 226V, Lunar Lake). With the driver bound, IRQ 20 fires non-stop and keeps one CPU core at ~30% load with the machine otherwise idle.

Kernel: 7.0.8-arch1-1
Machine: HP Omnibook X 14, Intel Core Ultra 5 226V
Touchscreen: ELAN2514, 04F3:43F4, ACPI \_SB_.PC00.I2C4.TPL1
Controller: i2c_designware.2 on IRQ 20 (IR-IO-APIC 20-fasteoi)

At boot, i2c_hid_acpi logs this once during probe (rate-limited):

[    5.042325] i2c_hid_acpi i2c-ELAN2514:00: i2c_hid_get_input: IRQ triggered but there's no data

The device registers successfully after that, but the interrupt line never deasserts. The counter on CPU5 climbs without bound:

    20:    0    0    0    0    0    19537    0    0   IR-IO-APIC   20-fasteoi   i2c_designware.2

Also worth noting - the device registers an unusual set of input nodes, including several labeled UNKNOWN:

ELAN2514:00 04F3:43F4 Touchscreen
ELAN2514:00 04F3:43F4 Stylus
ELAN2514:00 04F3:43F4 Keyboard
ELAN2514:00 04F3:43F4 Mouse
ELAN2514:00 04F3:43F4 UNKNOWN  (x5)

As a workaround I'm unbinding the driver via udev immediately after probe completes:

ACTION=="bind", DRIVER=="i2c_hid_acpi", KERNEL=="i2c-ELAN2514:00", \
    RUN+="/bin/sh -c 'echo i2c-ELAN2514:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind'"

This stops the flood but obviously leaves the touchscreen non-functional.

--
Dennis

Re:i2c_hid_acpi: ELAN2514 touchscreen causes IRQ flood on HP Omnibook X 14 (Lunar Lake)

[Dennis Foster]

Couple of corrections.

The machine is actually an HP OmniBook X Flip 16, not the
"Omnibook X 14" I wrote in the original - my mistake. Also bumped to
kernel 7.0.9 today; same behavior. BIOS is HP F.11
(03/04/2026), board 8DA1.

I disabled the udev workaround briefly to get an actual rate. With the
driver bound for ~40 seconds, /proc/interrupts went from 18,811 to
1,778,374 on IRQ 20, i.e. roughly 42,900/s pinned on CPU5. Kernel
never marks the line bad - no "nobody cared", no "disabling IRQ", it
just keeps fasteoi'ing.

One thing I missed in the DSDT that might be relevant: TPL1's
interrupt isn't a GpioInt() resource, it's a regular Interrupt()
template with the vector patched in at _INI:

    Name (SBFI, ResourceTemplate ()
    {
        Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, _Y4F)
        { 0x00000000, }
    })

    Method (_INI, ...)
    {
        ...
        INT2 = INUM (GPLI)
        ...
    }

That's why it surfaces as IR-IO-APIC 20-fasteoi rather than something
gpiolib-backed. _CRS picks between this template and a G_IN()/GpioInt
template based on the BIOS variable TPLM, and this firmware ships
with TPLM != 0 so we end up on the APIC path. I don't see a setup
option to flip it.

Probably unrelated but in the same area of the DSDT - this prints
once at boot:

    ACPI BIOS Error (bug): Could not resolve symbol
        [\_SB.PC00.I2C5.TPL1], AE_NOT_FOUND

I2C5 has no TPL1 in this firmware (the touchscreen is on I2C4).

Happy to send the full decompiled DSDT/SSDTs, a fuller dmesg with
i2c_hid dyndbg enabled, or test patches.

--
Dennis

Re: i2c_hid_acpi: ELAN2514 touchscreen causes IRQ flood on HP Omnibook X 14 (Lunar Lake)

[Strider Jones]

Adding a second machine with the same failure, in case it helps get this
looked at. Happy to test patches or collect more data.

Hardware
  HP OmniBook 7 Flip Laptop 16-au0xxx (SKU B88B1UA#ABA), board 8DA0
  Intel Core Ultra 7 258V (Lunar Lake), Insyde BIOS F.10 (2025-10-22),
  latest available on LVFS as of 2026-09-15
  Touchscreen: ELAN2514:00, 04F3:43F0 (yours is 43F4)
  ACPI path \_SB.PC00.I2C4.TPL1 on I2C #4, PCI 00:19.0
  (8086 Core Ultra 200V I2C #4), i2c_designware.2, IRQ 20
  Ubuntu 26.10 development branch, kernels 7.0.0-30 and 7.2.0-5 both
  affected; first seen 2026-08-09.

Symptoms match your report exactly. At probe:

  i2c_hid_acpi i2c-ELAN2514:00: i2c_hid_get_input: IRQ triggered but there's no data

and then IRQ 20 (the i2c-designware controller line, IR-IO-APIC level)
never stops. Measured today by binding the driver by hand with my udev
workaround disabled:

  - ~49,500 interrupts on IRQ 20 within 2 s of the bind
  - steady state ~21,500/s, all on one CPU
  - the irq/108-ELAN2514:00 thread sits in D state; on an earlier
    occurrence (2026-09-03) its kernel stack was inside i2c_dw_xfer and
    the log had repeated
      i2c_hid_get_input: incomplete report (67/65280)
    i.e. reads returning 0xff filler.
  - echo i2c-ELAN2514:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind
    drops IRQ 20 to 0/s immediately.

The device's own interrupt is IRQ 108 (IR-IO-APIC, level). The touchpad
(SYNA3503:00 on I2C #5 / i2c_designware.3) on the same platform is fine.

DSDT details, consistent with your Interrupt()-vs-GpioInt() finding:
TPL1 carries two resource buffers; SBFI is an Extended Interrupt
descriptor with flags 0x05 (level, active-low, exclusive) and its vector
is patched at _INI with INT2 = INUM(GPLI). _CRS returns the GpioInt()
variant (G_IN(GPLI,...)) only when TPLM == 0; this firmware has
TPLM != 0, so we get the APIC path. _HID is rewritten to "ELAN2514" at
_INI when TPLT == 7.

Storm frequency is intermittent on my box rather than every boot: some
boots ran for days without it, others hit it at probe. When it happens
it takes the desktop down (compositor waits on the stuck I2C bus), so
I'm running the same unbind-at-probe udev rule you described:

  ACTION=="add|bind", SUBSYSTEM=="i2c", KERNEL=="i2c-ELAN2514:00", \
    RUN+="/bin/sh -c 'echo i2c-ELAN2514:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind'"

Interesting aside: when hid-multitouch binds it registers the usual
touchscreen/stylus nodes plus five "UNKNOWN" input nodes and a
"Keyboard" node, same odd set you saw. When it probed via hid-generic on
one boot the primary node was reported as "I2C HID v1.00 Keyboard".

I can provide the decompiled DSDT, an acpidump, dmesg with
i2c-designware/i2c-hid dynamic debug, or test a quirk against 04F3:43F0
on request.

Strider Jones