This kernel version is not supported.

Please confirm it's an issue in 6.12.16 or 6.13.4.

If it's a regression, please bisect:

https://docs.kernel.org/admin-guide/bug-bisect.html

Created attachment 307707 [details]
attachment-9195-0.html

The problem exists in kernel 6.13.4. It has been present since 6.9. I did
bisect, the problem is 9140ce47872bfd89fca888c2f992faa51d20c2bc. Revert
this commit to fix the problem.

Here is my PR that likely won't get merged because I don't know how to
structure it:

From: Eliah Reeves <ereeclimb@gmail.com>
From dd4478d63b6a2b6891fcc1800eb26ce3f1ead1d4 Mon Sep 17 00:00:00 2001
Date: Wed, 19 Feb 2025 20:58:52 -0800
Subject: [PATCH] input: revert commit 9140ce4 to fix ELAN1206 touchpad
issues

Reverting commit 9140ce47872bfd89fca888c2f992faa51d20c2bc fixes a
regression that caused touchpad malfunctions. The original change
introduced unintended behavior affecting touchpad input.
---
 drivers/dma/idma64.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/idma64.c b/drivers/dma/idma64.c
index d147353d47ab..afcce6f5a636 100644
--- a/drivers/dma/idma64.c
+++ b/drivers/dma/idma64.c
@@ -171,9 +171,10 @@ static irqreturn_t idma64_irq(int irq, void *dev)
        u32 status_err;
        unsigned short i;

+       /* Commented to restore ELAN1206 Touchpad functionality */
        /* Since IRQ may be shared, check if DMA controller is powered on */
-       if (status == GENMASK(31, 0))
-               return IRQ_NONE;
+       /* if (status == GENMASK(31, 0))
+             return IRQ_NONE; */

        dev_vdbg(idma64->dma.dev, "%s: status=%#x\n", __func__, status);

--
2.48.1

1: Description
===========

Reverting commit 9140ce47872bfd89fca888c2f992faa51d20c2bc fixes a
regression that caused touchpad malfunctions. The original change
introduced unintended behavior affecting touchpad input with the
ELAN1206.

2: Touchpad Behavior with 9140ce47872bfd89fca888c2f992faa51d20c2bc
===========
The touchpad appears to send an event indicating touch up immediately
after each touch down event. This prevents libinput from moving the
cursor rendering the touchpad useless. It is also worth noting that in
addition to incorrect events the touchpad also appears to send events
much less frequently.

evtest output:

  Event: time 1738819278.422243, type 3 (EV_ABS), code 57
(ABS_MT_TRACKING_ID), value 73
  Event: time 1738819278.422243, type 3 (EV_ABS), code 53
(ABS_MT_POSITION_X), value 1264
  Event: time 1738819278.422243, type 3 (EV_ABS), code 54
(ABS_MT_POSITION_Y), value 860
  Event: time 1738819278.422243, type 1 (EV_KEY), code 330 (BTN_TOUCH),
value 1
  Event: time 1738819278.422243, type 1 (EV_KEY), code 325
(BTN_TOOL_FINGER), value 1
  Event: time 1738819278.422243, type 3 (EV_ABS), code 0 (ABS_X), value 1264
  Event: time 1738819278.422243, type 3 (EV_ABS), code 1 (ABS_Y), value 860
  Event: time 1738819278.422243, type 4 (EV_MSC), code 5
(MSC_TIMESTAMP), value 0
  Event: time 1738819278.422243, -------------- SYN_REPORT ------------
  Event: time 1738819278.526021, type 3 (EV_ABS), code 57
(ABS_MT_TRACKING_ID), value -1
  Event: time 1738819278.526021, type 1 (EV_KEY), code 330 (BTN_TOUCH),
value 0
  Event: time 1738819278.526021, type 1 (EV_KEY), code 325
(BTN_TOOL_FINGER), value 0
  Event: time 1738819278.526021, -------------- SYN_REPORT ------------
  Event: time 1738819278.630874, type 3 (EV_ABS), code 57
(ABS_MT_TRACKING_ID), value 74
  Event: time 1738819278.630874, type 3 (EV_ABS), code 53
(ABS_MT_POSITION_X), value 1415
  Event: time 1738819278.630874, type 3 (EV_ABS), code 54
(ABS_MT_POSITION_Y), value 799

3: Touchpad Behavior without 9140ce47872bfd89fca888c2f992faa51d20c2bc
===========
The touchpad functions smoothly and consistently.

4: Fixes
===========
closes: https://bugzilla.kernel.org/show_bug.cgi?id=219799

5: Impacts
===========
Reverting 9140ce47872bfd89fca888c2f992faa51d20c2bc would theoretically
reopen
https://lore.kernel.org/r/700bbb84-90e1-4505-8ff0-3f17ea8bc631@gmail.com

6: Methods
===========
I bisected the Linux kernel and found that
9140ce47872bfd89fca888c2f992faa51d20c2bc was the first commit where my
touchpad didn't work. Building the latest kernel with 9140ce4 removed
resulted in a working touchpad.

Let me know if I can help.
Signed-off-by: Eliah Reeves <ereeclimb@gmail.com>


On Mon, Feb 24, 2025, 8:30 AM <bugzilla-daemon@kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=219799
>
> Artem S. Tashkinov (aros@gmx.com) changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>              Status|NEW                         |NEEDINFO
>
> --- Comment #1 from Artem S. Tashkinov (aros@gmx.com) ---
> This kernel version is not supported.
>
> Please confirm it's an issue in 6.12.16 or 6.13.4.
>
> If it's a regression, please bisect:
>
> https://docs.kernel.org/admin-guide/bug-bisect.html
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You reported the bug.

My "patch" causes 1 cpu core to be maxed all the time handling interrupts. Just realized that.

I have been looking into this a bit more because my ELAN1206 touchpad (Q528EH Laptop) is having similar issues on kernel 6.x+ (I have not done a ton of testing on this but 5.8.0 was the newest kernel I tried that worked for me, I also tried 6.9, and 6.13.4, neither function with the touchpad).  Currently I am at the this point:
- mt_expired_timeout() is causing an ABS_MT_TRACKING_ID -1 to be sent when it shouldnt be.  Removing the following lines from drivers/hid/hid-multitouch.c mt_touch_report() partially fixes the issue (testing currently using 6.8.12):
			mod_timer(&td->release_timer,
				  jiffies + msecs_to_jiffies(100));

The ABS_MT_TRACKING_ID -1 is possibly causing libinput or some other component to send BTN_TOUCH and BTN_TOOL_FINGER 0 even when you are still using the touchpad.  Then when you continue moving, the touchpad will send BTN_TOUCH and BTN_TOOL_FINGER 1 again, where the process repeats.

I originally tried using pm_runtime_get_sync() to get past the issue Eliah showed above, but that failed on the next check in the idma64 interrupt.  I think that may be because the constant BTN_TOUCH 1 and 0 events were causing the bus to go down and up in rapid succession from pm_runtime related things which caused any input to not be transferred from i2c-hid.   

When mod_timer() lines are removed, the touchpad works however the cursor is very slow - I am currently working on determining whether the issue may be caused by the touchpad itself just taking forever to send events (past the 100 msec timeout) or if its some other issue like something within the input handler causing a small delay.  Increasing the timeout in the above line has a similar affect when increased to around 210 msecs.  If anyone has any advice on places to look that would be much appreciated as I do not have a ton of knowledge regarding these drivers.  Thank you!

I believe I have narrowed down the issue a little further - i2c_master_recv() in i2c_get_hid_input() is taking around 0x74 ms to complete - much more than the 100ms timeout.