Touchpad not working since update (Archlinux)

Framework Laptop 16 Linux
41

Does anyone encountering this issue use an encrypted root? Mine is encrypted and I have never experienced this issue. Currently on these versions:
linux 6.8.9.arch1-1
mkinitcpio 39-1

I’m wondering if the delay while I type in my encryption password is enough to allow it to work. I’m just thinking back when I was originally using the systemd hook, the keyboard would glitch in the middle of typing my password, ruining it, if I didn’t wait a few seconds after the prompt appeared. I know it’s the trackpad, but maybe it needs time to initialize. Some bug in the trackpad and keyboard firmwares.

1 Like
42

More clues…

After compiling 6.9.0-1-git-01154-gf4e8d8029285 with the I2C debug options enabled and the I2C HID modules built in, I was able to capture this suspicious error message upon boot and reproduction of the trackpad fault:

[    0.434751] i2c_designware AMDI0010:03: clock-frequency: 0
[    0.434752] i2c_designware AMDI0010:03: i2c-scl-rising-time-ns: 0
[    0.434753] i2c_designware AMDI0010:03: i2c-scl-falling-time-ns: 0
[    0.434754] i2c_designware AMDI0010:03: i2c-scl-internal-delay-ns: 0
[    0.434755] i2c_designware AMDI0010:03: i2c-sda-falling-time-ns: 0
[    0.434756] i2c_designware AMDI0010:03: i2c-sda-hold-time-ns: 0
[    0.434757] i2c_designware AMDI0010:03: i2c-digital-filter-width-ns: 0
[    0.434758] i2c_designware AMDI0010:03: i2c-analog-filter-cutoff-frequency: 0
[    0.441370] i2c_designware AMDI0010:03: ACPI slave is not supported yet
[    0.441385] i2c_designware AMDI0010:03: Standard Mode HCNT:LCNT = 642:749
[    0.441387] i2c_designware AMDI0010:03: Fast Mode HCNT:LCNT = 132:239
[    0.441390] i2c_designware AMDI0010:03: SDA Hold Time TX:RX = 48:48
[    0.441391] i2c_designware AMDI0010:03: Bus speed: Fast Mode (400 kHz)
[    0.442125] i2c i2c-1: client [PIXA3854:00] registered with bus id i2c-PIXA3854:00
[    0.637523] i2c_hid_acpi i2c-PIXA3854:00: probe
[    0.637615] i2c_designware AMDI0010:03: i2c_dw_xfer: msgs: 1
[    0.637642] i2c_designware AMDI0010:03: enabled=0x1 stat=0x10
[    0.637698] i2c_designware AMDI0010:03: enabled=0x1 stat=0x750
[    0.637714] i2c_designware AMDI0010:03: i2c_dw_handle_tx_abort: slave address not acknowledged (7bit mode)
1 Like
43

Great that you can repro like that. I think you should raise this with I2C maintainers.

44

This his really is great! May I ask you to put somewhere full logs of successful and failed enumeration? I’m very curious of the order of events in both cases.

@Mario_Limonciello are you sure this is a case for i2c folks? I still see a possibility of some races between hardware initialization and actual i2c bus usage.

45

I’m not 100% sure. It absolutely is a race, but we don’t know where right now. It’s best to get artifacts added to a bug on kernel bugzilla.

http://bugzilla.kernel.org/

What would be interesting is if it’s unique to the Framework 16 or if it can also reproduce on Framework 13 AMD or not.

1 Like
46

One more clarifying question about this, as it’s not clear from the post - is the trackpad initialization failure always reproducible with i2c HID compiled it or is it also random? I assumed the latter, but if it is consistent then it should make things easier to work with (eventually).

47

It’s random but happens roughly half the time when compiled into the kernel.

1 Like
48

I submitted the issue to Bugzilla at: 218836 – Framework Laptop 16 i2c-hid Based Touchpad Sometimes Fails To Initialize Properly On Early Boot

The issue was also submitted to the linux-input mailing list at: BUG: Framework Laptop 16 i2c-hid Based Touchpad Sometimes Fails To Initialize Properly On Early Boot

Thanks for the guidance.

49

Looks like the update to revert the breaking change made it’s way through the pipeline and I can reliably reboot with tracpad now. Hopefully a proper fix can be found, but I’m glad to have my tracpad back.

50

PixArt, the vendor behind the Framework touch pad module, recently submitted a trackpad driver to the linux-input mailing list. I am not certain as to how this impacts the Framework situation but it is encouraging to see that the touch pad vendor is actively working to improve Linux support.

https://lore.kernel.org/linux-input/cover.1715224143.git.zhoubinbin@loongson.cn/T/#t

3 Likes