[PATCH v2] HID: i2c-hid-acpi: restore touchscreen IRQ routing on HP OmniBook Flip laptops

[PATCH v2] HID: i2c-hid-acpi: restore touchscreen IRQ routing on HP OmniBook Flip laptops

[Waqar Gulzar]

On the HP OmniBook X Flip 16, OmniBook 7 Flip 16 and OmniBook X Flip 14
the ELAN2514 touchscreen interrupt is a GPIO pad (GPP_E_18) routed
directly to the IO-APIC. The firmware's touchscreen power resource does

    PTPL._ON:  \_SB.SGRA (TPI2, TPIP)        // TPIP = T0IP = 0
    PTPL._OFF: \_SB.SGRA (TPI2, TPIP ^ 1)

while the device's _INI enables routing with SGRA (GPLI, T0IP ^ 1).
So _ON clears PADCFG0.GPIROUTIOXAPIC and disconnects the pad from the
IO-APIC. Linux evaluates _ON at probe and on every D3->D0 transition
(Windows apparently does not while _STA already reports the resource
on), after which the level-triggered IRQ never deasserts:

  - ~630 interrupts/s while idle, nearly every read returns 0xffff
  - frames shifted by a leading 0xff, "incomplete report (67/7167)"
  - stylus reports arrive at ~25 Hz instead of the native ~268 Hz
  - touch stalls and false stylus proximity

Re-enable the routing through the firmware's own \_SB.SGRA helper from
the power_up hook, which runs at probe and on resume before the HID
reset.

Tested with this patch on the OmniBook X Flip 16 (board 8DA1, BIOS
F.20): idle interrupts drop from ~630/s to 0 after boot and after
s2idle resume, and pen and touch behave as on Windows.

The same faulty _ON, the same pad and the same ~630/s storm were
confirmed by other owners on the OmniBook 7 Flip 16 (board 8DA0, BIOS
F.08) and the OmniBook X Flip 14 (board 8D9F, BIOS F.08). On both,
correcting the _ON value through an ACPI table override stops the storm
(routing bit set, 0 interrupts/s idle, also after s2idle), which is the
same correction this patch applies at runtime.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220854
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142384
Link: https://github.com/testyfishy/hp-omnibook-flip16-touchscreen-fix
Link: https://github.com/iamwaqargulzar/hp-omnibook-x-flip-16-linux-touchscreen-pen-fix
Cc: stable@vger.kernel.org
Signed-off-by: Waqar Gulzar <iamwaqargulzar@gmail.com>
---
The firmware of the HP OmniBook X Flip 16, OmniBook 7 Flip 16 and
OmniBook X Flip 14 disconnects the ELAN2514 touchscreen interrupt from
the IO-APIC in its power resource _ON method, which Linux runs at probe
and resume. This patch re-enables the routing through the firmware's own
helper from i2c-hid-acpi's power_up hook.

Tested with the patch on board 8DA1 (BIOS F.20), Linux 7.2.8,
including s2idle resume. Boards 8DA0 and 8D9F were confirmed by their
owners to have the same faulty _ON and storm, and to be fixed by the
equivalent ACPI table correction (kernel bugzilla 220854).

Full analysis, ACPI excerpts, and Windows/Linux traces:
https://github.com/iamwaqargulzar/hp-omnibook-x-flip-16-linux-touchscreen-pen-fix
---
Changes in v2:
- Add board 8D9F (OmniBook X Flip 14): same faulty _ON, confirmed by
  its owner in bugzilla 220854.
- Fix the description of 8DA0: it is the OmniBook 7 Flip 16, a sibling
  model, not another board ID of the X Flip 16; now confirmed by its
  owner as well.
- Subject and commit message now name all three models; add the
  bugzilla link.
- Link to v1: https://patch.msgid.link/20260930-b4-elan2514-irq-route-v1-1-44671bf01d05@gmail.com
---
 drivers/hid/i2c-hid/i2c-hid-acpi.c | 65 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index 9371db200..b307d9a3d 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -21,6 +21,7 @@
 
 #include <linux/acpi.h>
 #include <linux/device.h>
+#include <linux/dmi.h>
 #include <linux/i2c.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
@@ -55,6 +56,67 @@ static void i2c_hid_acpi_restore_sequence(struct i2chid_ops *ops)
 	i2c_hid_acpi_get_descriptor(ihid_acpi->adev);
 }
 
+/*
+ * HP OmniBook X Flip 14 (board 8D9F), OmniBook 7 Flip 16 (8DA0) and
+ * OmniBook X Flip 16 (8DA1): the touchscreen power resource
+ * \_SB.PC00.I2C4.PTPL._ON writes the wrong value to the GPIROUTIOXAPIC bit
+ * of the touchscreen interrupt pad, disconnecting it from the IO-APIC. The
+ * level-triggered interrupt then never deasserts, the controller is read
+ * continuously (~630 reads/s while idle) and it cannot deliver pen reports
+ * at its native rate. Windows does not run _ON while the resource already
+ * reports on, so it is not affected. Linux runs _ON at probe and on every
+ * resume, so re-enable the routing with the firmware's own helper before
+ * the HID reset.
+ */
+static const struct dmi_system_id i2c_hid_acpi_irq_route_dmi[] = {
+	{
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "8D9F"),
+		},
+	},
+	{
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "8DA0"),
+		},
+	},
+	{
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "8DA1"),
+		},
+	},
+	{ }
+};
+
+static int i2c_hid_acpi_restore_irq_route(struct i2chid_ops *ops)
+{
+	struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
+	union acpi_object args[2];
+	struct acpi_object_list arg_list = { ARRAY_SIZE(args), args };
+	unsigned long long pad;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(NULL, "\\GPLI", NULL, &pad);
+	if (ACPI_FAILURE(status))
+		return 0;
+
+	args[0].type = ACPI_TYPE_INTEGER;
+	args[0].integer.value = pad;
+	args[1].type = ACPI_TYPE_INTEGER;
+	args[1].integer.value = 1;
+
+	status = acpi_evaluate_object(NULL, "\\_SB.SGRA", &arg_list, NULL);
+	if (ACPI_FAILURE(status))
+		acpi_handle_warn(acpi_device_handle(ihid_acpi->adev),
+				 "failed to restore interrupt routing: %s\n",
+				 acpi_format_exception(status));
+
+	/* Never fail probe or resume because of this workaround */
+	return 0;
+}
+
 static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
 {
 	struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
@@ -85,6 +147,9 @@ static int i2c_hid_acpi_probe(struct i2c_client *client)
 	ihid_acpi->adev = adev;
 	ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
 	ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
+	if (acpi_dev_hid_uid_match(ihid_acpi->adev, "ELAN2514", NULL) &&
+	    dmi_check_system(i2c_hid_acpi_irq_route_dmi))
+		ihid_acpi->ops.power_up = i2c_hid_acpi_restore_irq_route;
 
 	acpi_device_fix_up_power(adev);
 

---
base-commit: 145c2b2e9a5c0f794fb4009bcb072ab19f8ccfcd
change-id: 20260930-b4-elan2514-irq-route-d8274fcf805b

Best regards,
--  
Waqar Gulzar <iamwaqargulzar@gmail.com>

[PATCH v2] HID: i2c-hid-acpi: restore touchscreen IRQ routing on HP OmniBook Flip laptops

[Waqar Gulzar via B4 Relay]

From: Waqar Gulzar <iamwaqargulzar@gmail.com>

On the HP OmniBook X Flip 16, OmniBook 7 Flip 16 and OmniBook X Flip 14
the ELAN2514 touchscreen interrupt is a GPIO pad (GPP_E_18) routed
directly to the IO-APIC. The firmware's touchscreen power resource does

    PTPL._ON:  \_SB.SGRA (TPI2, TPIP)        // TPIP = T0IP = 0
    PTPL._OFF: \_SB.SGRA (TPI2, TPIP ^ 1)

while the device's _INI enables routing with SGRA (GPLI, T0IP ^ 1).
So _ON clears PADCFG0.GPIROUTIOXAPIC and disconnects the pad from the
IO-APIC. Linux evaluates _ON at probe and on every D3->D0 transition
(Windows apparently does not while _STA already reports the resource
on), after which the level-triggered IRQ never deasserts:

  - ~630 interrupts/s while idle, nearly every read returns 0xffff
  - frames shifted by a leading 0xff, "incomplete report (67/7167)"
  - stylus reports arrive at ~25 Hz instead of the native ~268 Hz
  - touch stalls and false stylus proximity

Re-enable the routing through the firmware's own \_SB.SGRA helper from
the power_up hook, which runs at probe and on resume before the HID
reset.

Tested with this patch on the OmniBook X Flip 16 (board 8DA1, BIOS
F.20): idle interrupts drop from ~630/s to 0 after boot and after
s2idle resume, and pen and touch behave as on Windows.

The same faulty _ON, the same pad and the same ~630/s storm were
confirmed by other owners on the OmniBook 7 Flip 16 (board 8DA0, BIOS
F.08) and the OmniBook X Flip 14 (board 8D9F, BIOS F.08). On both,
correcting the _ON value through an ACPI table override stops the storm
(routing bit set, 0 interrupts/s idle, also after s2idle), which is the
same correction this patch applies at runtime.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220854
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142384
Link: https://github.com/testyfishy/hp-omnibook-flip16-touchscreen-fix
Link: https://github.com/iamwaqargulzar/hp-omnibook-x-flip-16-linux-touchscreen-pen-fix
Cc: stable@vger.kernel.org
Signed-off-by: Waqar Gulzar <iamwaqargulzar@gmail.com>
---
The firmware of the HP OmniBook X Flip 16, OmniBook 7 Flip 16 and
OmniBook X Flip 14 disconnects the ELAN2514 touchscreen interrupt from
the IO-APIC in its power resource _ON method, which Linux runs at probe
and resume. This patch re-enables the routing through the firmware's own
helper from i2c-hid-acpi's power_up hook.

Tested with the patch on board 8DA1 (BIOS F.20), Linux 7.2.8,
including s2idle resume. Boards 8DA0 and 8D9F were confirmed by their
owners to have the same faulty _ON and storm, and to be fixed by the
equivalent ACPI table correction (kernel bugzilla 220854).

Full analysis, ACPI excerpts, and Windows/Linux traces:
https://github.com/iamwaqargulzar/hp-omnibook-x-flip-16-linux-touchscreen-pen-fix
---
Changes in v2:
- Add board 8D9F (OmniBook X Flip 14): same faulty _ON, confirmed by
  its owner in bugzilla 220854.
- Fix the description of 8DA0: it is the OmniBook 7 Flip 16, a sibling
  model, not another board ID of the X Flip 16; now confirmed by its
  owner as well.
- Subject and commit message now name all three models; add the
  bugzilla link.
- Link to v1: https://patch.msgid.link/20260930-b4-elan2514-irq-route-v1-1-44671bf01d05@gmail.com
---
 drivers/hid/i2c-hid/i2c-hid-acpi.c | 65 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index 9371db200..b307d9a3d 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -21,6 +21,7 @@
 
 #include <linux/acpi.h>
 #include <linux/device.h>
+#include <linux/dmi.h>
 #include <linux/i2c.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
@@ -55,6 +56,67 @@ static void i2c_hid_acpi_restore_sequence(struct i2chid_ops *ops)
 	i2c_hid_acpi_get_descriptor(ihid_acpi->adev);
 }
 
+/*
+ * HP OmniBook X Flip 14 (board 8D9F), OmniBook 7 Flip 16 (8DA0) and
+ * OmniBook X Flip 16 (8DA1): the touchscreen power resource
+ * \_SB.PC00.I2C4.PTPL._ON writes the wrong value to the GPIROUTIOXAPIC bit
+ * of the touchscreen interrupt pad, disconnecting it from the IO-APIC. The
+ * level-triggered interrupt then never deasserts, the controller is read
+ * continuously (~630 reads/s while idle) and it cannot deliver pen reports
+ * at its native rate. Windows does not run _ON while the resource already
+ * reports on, so it is not affected. Linux runs _ON at probe and on every
+ * resume, so re-enable the routing with the firmware's own helper before
+ * the HID reset.
+ */
+static const struct dmi_system_id i2c_hid_acpi_irq_route_dmi[] = {
+	{
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "8D9F"),
+		},
+	},
+	{
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "8DA0"),
+		},
+	},
+	{
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "8DA1"),
+		},
+	},
+	{ }
+};
+
+static int i2c_hid_acpi_restore_irq_route(struct i2chid_ops *ops)
+{
+	struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
+	union acpi_object args[2];
+	struct acpi_object_list arg_list = { ARRAY_SIZE(args), args };
+	unsigned long long pad;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(NULL, "\\GPLI", NULL, &pad);
+	if (ACPI_FAILURE(status))
+		return 0;
+
+	args[0].type = ACPI_TYPE_INTEGER;
+	args[0].integer.value = pad;
+	args[1].type = ACPI_TYPE_INTEGER;
+	args[1].integer.value = 1;
+
+	status = acpi_evaluate_object(NULL, "\\_SB.SGRA", &arg_list, NULL);
+	if (ACPI_FAILURE(status))
+		acpi_handle_warn(acpi_device_handle(ihid_acpi->adev),
+				 "failed to restore interrupt routing: %s\n",
+				 acpi_format_exception(status));
+
+	/* Never fail probe or resume because of this workaround */
+	return 0;
+}
+
 static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
 {
 	struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
@@ -85,6 +147,9 @@ static int i2c_hid_acpi_probe(struct i2c_client *client)
 	ihid_acpi->adev = adev;
 	ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
 	ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
+	if (acpi_dev_hid_uid_match(ihid_acpi->adev, "ELAN2514", NULL) &&
+	    dmi_check_system(i2c_hid_acpi_irq_route_dmi))
+		ihid_acpi->ops.power_up = i2c_hid_acpi_restore_irq_route;
 
 	acpi_device_fix_up_power(adev);
 

---
base-commit: 145c2b2e9a5c0f794fb4009bcb072ab19f8ccfcd
change-id: 20260930-b4-elan2514-irq-route-d8274fcf805b

Best regards,
--  
Waqar Gulzar <iamwaqargulzar@gmail.com>

Re: [PATCH v2] HID: i2c-hid-acpi: restore touchscreen IRQ routing on HP OmniBook Flip laptops

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] hid: i2c-hid-acpi: ACPI IRQ routing workaround bypassed on resume if wakeup enabled
--

commit 395f14993542089fc82210b5b3e47d5cf6164163
Author: Waqar Gulzar <iamwaqargulzar@gmail.com>

HID: i2c-hid-acpi: restore touchscreen IRQ routing on HP OmniBook Flip laptops

This patch works around a firmware bug on several HP OmniBook Flip laptops
where the touchscreen ACPI _ON method incorrectly disconnects the interrupt
from the IO-APIC. It attempts to re-enable the correct IRQ routing during
device initialization and resume using the i2c_hid_acpi driver's power_up
hook.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220854
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142384
Link: https://github.com/testyfishy/hp-omnibook-flip16-touchscreen-fix
Link: https://github.com/iamwaqargulzar/hp-omnibook-x-flip-16-linux-touchscreen-pen-fix

> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> index 9371db200fc4d..b307d9a3d0455 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c

[ ... ]

> @@ -147,6 +147,9 @@ static int i2c_hid_acpi_probe(struct i2c_client *client)
>  	ihid_acpi->adev = adev;
>  	ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
>  	ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
> +	if (acpi_dev_hid_uid_match(ihid_acpi->adev, "ELAN2514", NULL) &&
> +	    dmi_check_system(i2c_hid_acpi_irq_route_dmi))
> +		ihid_acpi->ops.power_up = i2c_hid_acpi_restore_irq_route;

[Severity: High]
Does this workaround get bypassed on system resume if the device is
configured as a wakeup source?

Looking at i2c_hid_core_resume() in drivers/hid/i2c-hid/i2c-hid-core.c,
the power_up hook is skipped if the device may wake the system:

drivers/hid/i2c-hid/i2c-hid-core.c:i2c_hid_core_resume() {
    ...
	if (!device_may_wakeup(&client->dev))
		i2c_hid_core_power_up(ihid);
    ...
}

If the user or system configures the touchscreen to wake the system from
sleep, the ACPI _ON method will run during the transition back to D0 and
disconnect the IRQ routing, but the power_up hook won't be called to
restore it.

Could this cause the interrupt storm to return immediately upon enabling
the IRQ on system resume?

>  
>  	acpi_device_fix_up_power(adev);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008-b4-elan2514-irq-route-v2-1-432d95eb7348@gmail.com?part=1

Re: [PATCH v2] HID: i2c-hid-acpi: restore touchscreen IRQ routing on HP OmniBook Flip laptops

[Waqar Gulzar]

On the wakeup question (same as raised on v1): the ELAN2514 is not
wake-capable on these boards. TPL1 has no _PRW, and its _CRS interrupt
is not marked wake-capable, so i2c_acpi_get_irq() reports wake_capable
= false, I2C_CLIENT_WAKE is never set, and the device has no
power/wakeup attribute in sysfs (checked on 8DA1, BIOS F.20).
device_may_wakeup() is therefore always false, and power_up runs on
every resume.

If a future firmware marked the interrupt wake-capable,
i2c_hid_core_suspend() would also skip power_down under the same
condition, so the driver would not take the device through the
D3cold/_ON cycle that clears the routing in the first place.

Waqar