Touchpad interrupts & battery usage issues (idma64.2)

I contacted framework support and they sent me a new input cover but unfortunately the issue persists. Behavior was identical as with the old touchpad. Thanks though to framework support for being prompt after I reached out! To sum up what I have ruled out so far:

  1. touchpad hardware (from testing new input cover)
  2. touchpad connnection (from testing new input cover)
  3. multitouch kernel drivers (disabling intel_lpss_pci, issue persisted on i8042)
  4. i2c_designware driver (disabling i2c_designware, issue persisted on i8042)
  5. kernel version (tested countless versions since 5.13)
  6. Linux distribution (tested NixOS and Fedora 35)

I’ll post any updates if I find a solution/learn more from framework support.


DIY 1185G7 running Fedora 35.
Just wanted to confirm the outlined observations.

I noticed the very same behaviour when moving a wired USB mouse (IBM Travel Mouse) or a wireless BT mouse with dedicated USB adapter (Logitech V500) while leaving the touchpad completely unused.

Similar findings on DIY i7-1165G7. Arch with kernels 5.16.{0…16} and 5.17.{1…4}, and Ubuntu 22.4 with 5.15.0.

Interrupt 30, idma64.2, is not triggered unless I touch the touchpad. If i just rest a finger on it, it gets up to ~1500/s. If i continuously move the cursor, up to ~2000/s.

The same is visible in powertop. The system idles at 2.7W, but gently moving the cursor about doubles that.

PS/2 emulation is disabled, multitouch is enabled.

I had problems with my touchpad’s hardware click button not registering unless you pressed real hard. framework support replaced my touchpad and that fixed the HW issue, but I found this thread while I was trying to troubleshoot.

I’m running Ubuntu 20.04 with Kernel 5.14.9-051409-generic, and I too see a shitton (metric) of interrupts from idma64.2, and i2c_designware.2 while interacting with the touchpad. I just ran dstat -t --top-int which displays the highest offender every second, and I see close to 2000 per second just with a finger on the TP.

I’m an embedded systems engineer, but not a Linux expert. However, I can’t understand why this many interrupts would be needed? I’ve spent hours and hours trying to get the power consumption tuned better so far, I’m still nowhere as good as my old Lenovo X1 6th gen, which had no special tuning. I’m running lightdm, and I can’t get suspend to work right either, so I have it disabled.

It seems that framework is labeling this as a kernel driver issue that is out of scope of support. I might be wrong as support wasn’t super specific but thats what I got from the tone of the email. If anyone in the community is experienced in linux kernel driver programming this excerpt might be of help: “The touchpad is an i2c-hid device that is connected directly to the intel SOC.”

My key takeaway is that if its a kernel driver issue then everyone running linux should be affected. Thus I am extremely interested in knowing if any linux users don’t have this issue. I am currently running 5.17.3 and have had this issue since I got my framework laptop at 5.13.

1 Like

Adding on the one thing I haven’t tested is bios version. From dmidecode I am running version 3.02 with revision 3.2. When I get the chance I will upgrade to the latest bios and see if that fixes anything.

edit: updated to bios 3.07. Still no change. I replied to framework support to see if they can give any insight on what kernel/distro was being run where they achieved 150 interrupts/sec.

BIOS 3.08 - high wake-up count unchanged.

Going off the tip that it is a kernel issue, I found a thread that may help uncover more clues as to what might be going on. Warning: I am a complete linux noob and testing this solution is way over my head; hoping that someone more knowledgeable can tell me if there is anything here.

This user was experiencing a very similar issue on a Dell laptop with increased power consumption when touching or using the touchpad. Looks like it was a kernel bug related to i2c-HID and SMBus that was resolved in 5.8 which is so old it may not be relevant but since there are no other leads at the moment figured it was worth sharing.

Read through the patch and it is regarding optimization of the transfer buffer size. It doesn’t comment on a fix/reasons for a number of irqs of the touchpad. So I don’t believe it is related to the issue here, someone can correct me if I am wrong. Thanks for the link though.

I have been following the topic and seeing the direction wanted to point out that in my testing this is not a Linux issue.

BIOS 3.07

Both Fedora 35 (5.17.4-200, gnome 41.5) and Windows 10 21H2 show the same behaviour when moving the mouse. This is both with the touchpad and a USB optical mouse.

I have also had the chance to test a second input cover (rattling touchpad) and saw very similar interrupts to the original.

1 Like

This is good to hear, so maybe Framework can take a look at this problem now. I had an interesting bug happen the other day, I had accidentally turned on caps-lock, and I went to turn it off and while pressing it and the A key accidentally, my right forearm clicked the touchpad. At that point the A key began infinite repeat, and both the touchpad and the keyboard were offline. I was forced to hold the power key down for about 30 seconds to reboot the machine to rectify this. I was not able to reproduce it later. Just something of note.

Just to throw this in this thread. the touchpad only generates 140interrupts/second when it is touched/moving.

As mentioned previously in the thread, the large number of interrupts generated are probably from the i2c controller on the SOC, as each physical interrupt requires the CPU to transfer multiple bytes. A more optimized Linux kernel driver may be able to fix this.


…so we’re saying that the hardware is exposing the currently less-than-optimized state of the kernel driver?

I think I understand the issue now. The touchpad is generating 140 hardware interrupts/second. This is separate from i2c. The Linux kernel is then receiving those interrupts either over i2c/i8042. Due to how the drivers are written the kernel is causing more interrupts then it is receiving. ~14 interrupts per hardware interrupts for the i2c driver and ~3 per hardware interrupt for i8042. I misunderstood and thought we were supposed to be expecting 140 interrupts/sec on i2c.

Next steps would be to debug the i2c drivers and see why it is generating so many interrupts from each hardware interrupts? @Kieran_Levin

@Kieran_Levin Thanks for clarifying.

A more optimized Linux kernel driver may be able to fix this.

I see the same occurrence with similar power deltas under Windows 10 unless I’m mistaken this indicates this is not a Linux related issue but a fact of the hardware?

Edit: Testing more I saw slightly lower power usage from Windows.

Moving the cursor used up to 2.8W over idle on Windows, 3.1W on Fedora 35. Just touching the touchpad used 1.5W over idle on Windows while Fedora showed 2.2W.

It makes sense that touching it immediately spikes the power usage; even if the input itself doesn’t result in a program responding, the act of touching the touchpad sensor is enough to generate interrupts that wake the CPU up and make it process them (i.e. use power).

I think a more reasonable comparison would be dragging your finger around for a minute or so on each OS and comparing the power usage then.

Hey thanks for the feedback! I agree this seems to be from processing the interrupts rather than the touchpad itself.

One problem I had was to keep motion consistent between tests this is why I went for resting a finger on the touchpad and peak power draw from moving. I think you are right however measuring total consumption rather than rate would be better.

To clarify “just touching” is me resting a finger on the touchpad and the additional power draws mentioned above are constant rather than just spikes.

I did some further testing only in Windows to remove Linux variables.

When using the touchpad vs an optical USB mouse the touchpad is on average using 0.9 watts more doing the same task.

I considered doing a total consumption comparison but the duration needed to get some reasonable numbers would be longer than is physically comfortable.

Makes sense, since the proccessor needs to do more computer to get where ur moving your finger and all that.

1 Like

Thanks that does make sense knowing that. So only a more efficient CPU will help. Seems I will be wanting that Ryzen upgrade ASAP!

1 Like