Hello, guys
I’m on Framework 13 with Intel Core Ultra with Ubuntu 25 and I’m experiencing this issue. Are there any updates in context of make it work properly “by default”?
If not, do anyone knows what is the best workaround for this problem at the moment?
Hi all,
May or may not be unrelated, but I have had two Framework 16 AMD Motherboards with a similar issue. The difference for me is that touching the touchpad sometimes causes the system to stutter for about 500-1000ms. This is extreme frustrating when I use it to perform live as a DJ.
I originally thought that this issue was specific to AMD, but perhaps it’s actually the touchpad?
Thanks,
Evan
It is related to this touchpad model + linux. I even bought another touchpad with hope that maybe this issue is related only to some copies of this touchpad - but it didn’t help - issue still occurs ![]()
Did this issue ever get resolved? I’m on a FW16 with AMD 7840 and I still see a significant increase in battery usage over idle when using the touch pad. Latest BIOS & Ubuntu 25.10.
Not fixed. Proposed kernel fix is to put the IRQs on the same CPU which one of the scripts or the kernel parameter methods in the thread can do as well (make sure it works properly, including after waking from sleep though). I personally just live with it and it hasn’t bothered me a ton (also IRQs just happen to both be pinned to CPU 0 after waking from sleep for me).
As of right now, an interrupt is generated any time there is data available to read, even if that’s 1-2 bytes of an incomplete “touchpad event” packet, and no current plan to address that part.
tbh I hope that this issue will not occur anymore on the new haptic touchpad from Framework 13 Pro
but I guess we will see
After 4 years and several upgrades of the hardware and software the problem still bugs me, because I have the feeling that this is root cause of mediocre battery life with light work loads.
From my understanding it isn’t a problem that is connected to the mainboard you use (have the problem under intel 11gen and ryzen 7000), the problem is caused by the touchpad itself?!
I really really hope the new haptic touchpad will solve this! I am so looking forward to the pro upgrade kits in silver. I have accumulated so many spare parts since 2021 that I will be able to build an frankenstein pro with ryzen 7000 and the original one with the intel 11 gen ![]()
I’m not sure if this is related but I also see messages such as “Disabling IRQ #27” related to the kernel modules handling the touchpad.
Jul 06 16:33:34 kernel: irq 27: nobody cared (try booting with the "irqpoll" option)
Jul 06 16:33:34 kernel: CPU: 15 UID: 0 PID: 0 Comm: swapper/15 Not tainted 6.18.38-1-lts #1 PREEMPT(voluntary) 8bc4b5a0030cf6db63bb4ceff07f39d5d5051d77
Jul 06 16:33:34 kernel: Hardware name: Framework Laptop (12th Gen Intel Core)/FRANGACP06, BIOS 03.18 07/02/2025
Jul 06 16:33:34 kernel: Call Trace:
Jul 06 16:33:34 kernel:
Jul 06 16:33:34 kernel: dump_stack_lvl+0x5d/0x80
Jul 06 16:33:34 kernel: \__report_bad_irq+0x35/0xbf
Jul 06 16:33:34 kernel: note_interrupt.cold+0x1a/0x58
Jul 06 16:33:34 kernel: handle_irq_event+0x72/0x90
Jul 06 16:33:34 kernel: handle_fasteoi_irq+0xda/0x210
Jul 06 16:33:34 kernel: \__common_interrupt+0x41/0xa0
Jul 06 16:33:34 kernel: common_interrupt+0x80/0xa0
Jul 06 16:33:34 kernel:
Jul 06 16:33:34 kernel:
Jul 06 16:33:34 kernel: asm_common_interrupt+0x26/0x40
Jul 06 16:33:34 kernel: RIP: 0010:cpuidle_enter_state+0xbb/0x400
Jul 06 16:33:34 kernel: Code: 00 00 e8 98 cb f2 fe e8 43 f2 ff ff 48 89 c5 0f 1f 44 00 00 31 ff e8 e4 34 f1 fe 45 84 ff 0f 85 26 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 70 01 00 00 44 >
Jul 06 16:33:34 kernel: RSP: 0000:ffffd2ea40213e78 EFLAGS: 00000246
Jul 06 16:33:34 kernel: RAX: ffff8c329637a000 RBX: 0000000000000001 RCX: 0000000000000000
Jul 06 16:33:34 kernel: RDX: 0000000338346860 RSI: fffffffc6b0464fc RDI: 0000000000000000
Jul 06 16:33:34 kernel: RBP: 0000000338346860 R08: 0000000000000001 R09: 000001d1a94a2000
Jul 06 16:33:34 kernel: R10: 00000000ffffffff R11: ffffffffffffffff R12: ffff8c324e9fe8c0
Jul 06 16:33:34 kernel: R13: ffffffffb7bf1ec0 R14: 0000000000000001 R15: 0000000000000000
Jul 06 16:33:34 kernel: ? cpuidle_enter_state+0xac/0x400
Jul 06 16:33:34 kernel: cpuidle_enter+0x31/0x50
Jul 06 16:33:34 kernel: do_idle+0x157/0x2a0
Jul 06 16:33:34 kernel: cpu_startup_entry+0x29/0x30
Jul 06 16:33:34 kernel: start_secondary+0x119/0x140
Jul 06 16:33:34 kernel: common_startup_64+0x13e/0x141
Jul 06 16:33:34 kernel:
Jul 06 16:33:34 kernel: handlers:
Jul 06 16:33:34 kernel: \[<000000004f30b529>\] idma64_irq \[idma64\]
Jul 06 16:33:34 kernel: \[<00000000280aa276>\] i2c_dw_isr
Jul 06 16:33:34 kernel: Disabling IRQ #27
By the way, the new touchscreen seems to use the same I2C interface as the touchpad. As a result, you also see interrupt spikes and a significant power usage spike, similar to when you use the touchpad.
It seems like a mess. It says the hardware only outputs up to 140 interrupts per second, but somehow the kernel has to handle 1000s. That just sounds like broken drivers or broken hardware to me.
In my view the touchpad should be able to do this task of sensing input in far fewer interrupts.
To save power, i would have the gpio to be a level trigger. If low, data is waiting, so wake up. If high, no data waiting, so sleep.
The, if it is low, continue to poll the i2c reads until the level is high again.
Then, add an i2c command to suppress the gpio or not, for example, if you don’t want any input right now or don’t want the touchpad to wake up the cpu.
Maybe that is actually how the touchpad works, and the linux kernel is treating it as a level triggered interrupt and should not be.
I.e. high->low edge trigger gpio acpi wakeup. Keep polling i2c reads based on gpio level.
What I dont understand: I see the same amount of interrupts when using the touchpad on a x1 yoga with a intel gen 11 processor, but I dont see high amount of power usage as on the framework 13 (+2-3 W).
Could someone with the new Framework 13 Pro share data on touchpad interrupt frequency and power draw? I’m curious to see if the new touchpad hardware shows measurable efficiency gains over the previous generation. I really hope that it is not a motherboard issue that can only be fixed with the new Intel 300 series mainboards.
I hope to get my new unit by Friday. If you’ve not had that data by the weekend, ping me in this thread, and I will see if I can get it for you. I expect to use Mint in the first instance.
Has there been a solution for this issue?
I’ve finally took some time to investigate why my fan is constantly spinning, and this seems like the issue. The touchpad irq irq/174-PIXA3854 is constantly using 2-3% of my CPU ![]()
Would someone on this thread add some Linux commands to count touchpad interrupts or determine touchpad processor load? I can run them if they don’t require a kernel recompile ![]()
I just used “powertop -t 2”. I only need to put my finger on the touchpad and see an overall jump of about 2 watts of power usage. Normaly it would also show interrupt counts but atm it doesnt, must be something with my system config atm.
Replicated on Mint, to some degree, on a Pro 13 with AMD (Ryzen AI 7 350). I installed and used PowerTOP.
Without trackpad activity, I get 3800 interrupts/sec at 6.3W, and with drawing circles on the touchpad, I get 4500 interrupts/sec at 7.0W.
So it does look like the trackpad is generating a lot of hardware events. I’ve no idea what normal/expected numbers would look like though. Current estimations of battery life are 10h, but that’s based on idling so far.
Thanks alot for the testing. I tested Linux Mint / Cinnamon in the past and it used alot more resources in idle states compared to other desktops with wayland sessions, so the high interrupts/sec count could be normal. But on the other hand youre idle powerusage of around 6W is rather good for the amd plattform. The best thing is you only get around 0,7W power usage and about 700 interrupts/sec more using the touchpad, that is way less then my +2W and arount 1500+ interrupts/sec. ![]()
Would anyone with a Intel Core Ultra Series 3 variant of the Pro be able to test this?