You are not logged in.
Another idea.
cat /proc/bus/input/devices gives
I: Bus=0018 Vendor=0b05 Product=0701 Version=0100
N: Name="FTE1200:00 0B05:0701 Touchpad"
P: Phys=i2c-FTE1200:00
S: Sysfs=/devices/platform/AMDI0010:01/i2c-0/i2c-FTE1200:00/0018:0B05:0701.0002/input/input19
U: Uniq=
H: Handlers=event6 mouse1
B: PROP=5
B: EV=1b
B: KEY=e520 10000 0 0 0 0
B: ABS=2e0800000000003
B: MSC=20In looking along the sysfs path I found a file /sys/devices/platform/AMDI0010:01/i2c-0/i2c-FTE1200:00/0018:0B05:0701.0002/quirks that contained a non-zero value. Thinking this might be a quirk that is actually wrong I did:
echo 0 | sudo tee /sys/devices/platform/AMDI0010:01/i2c-0/i2c-FTE1200:00/0018:0B05:0701.0002/quirks then confirmed with
cat /sys/devices/platform/AMDI0010:01/i2c-0/i2c-FTE1200:00/0018:0B05:0701.0002/quirks which gave a value of 0
Hopefully this will help.
Offline
Nope. Back to the drawing board.
Offline
Found something on the manjaro forum. Apparently you can put a touchpad into polling mode with a kernel parameter instead of using interrupts. Supposed to be a fallback for misbehaving touchpads.
GRUB_CMDLINE_LINUX_DEFAULT="i2c-hid.polling_mode=1"Going to try this over the next few days.
Offline
I couldn't remember if I've already tried that. I remember Coiby saying something about polling mode, so I went ahead and tried it after your suggestion and so far my impressions are that it is slightly better, but definitely still there. What has your experience been, jaygambrel?
Offline
Pretty much the same. Still occurs maybe less often. I wasn't sure if I needed to recompile the i2c_hid kernel module with the appropriate patches though to make it work. I found this repository for coiby: https://github.com/coiby/standalone_i2c_hid
but I wasn't able to get it to compile. Make always kicked out errors. I wounder if you would have more luck.
Offline
I am now on kernel 5.11.2 and have gotten some libinput updates including libinput-gestures. Things seem to be working for now. Hopefully they will stay that way. Has your touchpad improved jdoggsc?
Offline
I checked i2c-hid c-source for a mention of polling_mode and didn't find anything. I haven't spent any time re-checking the manjaro forum for details about the mention of polling_mode, but it must have been something that was implemented as a one-off solution. It was wishful thinking that passing polling_mode=1 made any difference.
I'm using 5.11.1 and still problems. I'll update to 5.11.2 and give it some time to see if I have the same luck as you. As of the time of writing, I have libinput 1.17.0 and xf86-input-libinput 0.30.0-1
Last edited by jdoggsc (2021-03-12 03:32:29)
Offline
I have the same versions of libinput and xf86-input-libinput as you. The kernel is the only difference.
I had also given up on any improvement and had decided to chance ordering a replacement touchpad online. My machine is an x512d. I found a touchpad for a X512UF-1G that looks to have the same structure for securing it to the chasis. It has a fingerprint reader with a separate cable that I wouldn't be able to use, but thought it might be more compatible with the current kernel and libraries. Go figure I just get notification that it is on it's way and now my touchpad seems to be behaving. Even so, a backup couldn't hurt I guess.
Offline
So much for that. Back to getting stuck in scroll mode and losing tap to click again. Worked fine all day yesterday. Guess it's good I ordered that extra touchpad.
Offline
I wanted to let you all know that I have been experiencing this same/similar problem while running Windows 10 too. I just purchased a new Acer Aspire 5 laptop a few days ago and it has the ELAN I2C touchpad. In Device Manger the driver says it's from ELAN , dated 7/12/2019 and the version 13.6.15.1. As generally described in this thread, the cursor will stop moving, and as long as I'm rubbing my finger around with it stuck it will never move, no matter the pressure applied it remains stuck. Once I lift my finger and place it back down again on the pad, initiating a new cursor session, the mouse will once again start moving. I seem to be able to replicate this more easily by initially applying very light pressure while trying to start moving the cursor. This makes an otherwise decent new Acer laptop a serious frustration to try to use. Hope sharing this somehow helps.
Offline
Thanks for this. It is interesting to know that Windows users experience the same thing. I had read that not all touchpad manufacturers properly implement the HID over i2c standard and therefore the drivers for them act up. They then require quirks to be added to the drivers to get them to function correctly. This is of course up to the manufacturer. I have given up on a driver update coming along that will fix this. I have just installed my replacement touchpad for a slightly better model of Vivobook than I have. Fortunately it fit perfectly and the system has recognized it as an ELAN touchpad instead of the previous one manufactured by ASUS. Time will tell if this one is going to work better.
Offline
Thanks for this. It is interesting to know that Windows users experience the same thing. I had read that not all touchpad manufacturers properly implement the HID over i2c standard and therefore the drivers for them act up. They then require quirks to be added to the drivers to get them to function correctly. This is of course up to the manufacturer. I have given up on a driver update coming along that will fix this. I have just installed my replacement touchpad for a slightly better model of Vivobook than I have. Fortunately it fit perfectly and the system has recognized it as an ELAN touchpad instead of the previous one manufactured by ASUS. Time will tell if this one is going to work better.
How has it been? Replacing your FTE trackpad with a ELAN trackpad essentially sounded like you were trying to create my problem for yourself. I was skeptical that it would be an improvement, but you haven't come back to this thread, so I'm assuming you've had no problems to bring you back here.
I've been getting by by primarily using my laptop with a mouse, but when I do use the trackpad, it's hard to deal with the rage.
I've been looking at getting a new laptop as my solution to this problem but before pulling the trigger wanted to check into this topic once more since I haven't touched it for several months...
Offline
For me the freezes got less and less with over time. Didn't experience any for a month or so. Since linux 5.14 I think the touchpad is even a bit more responsive overall.
Offline
So it seems like this isn't an issue for thread participants anymore, but his has been a problem for me non-stop and without any improvement from kernel update to kernel update. I think I've found a solution, though.
In a last attempt to fix this before looking for a new laptop for cyber Monday, I checked out what progress has been made on this front. My new searches lead me back to this thread on bugzilla.kernel.org which I hadn't checked on since March. Contributions to the chat by Hans De Goede starting on 5/27 are particularly interesting, and by 5/31 Hans provides a patch to test for improvement.
I decided to give it a go and see what benefit I could see. It's been 2 days now that I've had this modified kernel module loaded and it feels like a completely different computer! Actually, it's the same computer, minus my rage. This is an unprecedented amount of time for my laptop to be on good behavior with the next longest time being around only 1 hour. I'm optimistic that Hans found the cure! Time will tell, but I intend to either manually build this modified kernel driver every time the kernel updates, or else just set
/etc/pacman.conf
IgnorePkg = linuxI got guidance from both this Arch wiki page and the steps provided by coiby in this comment on Ubuntu's launchpad to compile the module. I'll lay out the steps below(I had Linux 5.15.2 at the time I did this, so I'll just use that in my steps below. Substitute as needed for your computer.
Download the kernel source (kernel.org) and the patch from Hans De Goede
Uncompress the kernel source into a folder and cd into that folder (assuming Downloads folder as save location)
$ cd ~/Downloads
$ tar -xf linux-5.15.2.tar.xz
$ cd linux-5.15.2At the top level of the unzipped files from kernel.org run
$ make mrproper$ zcat /proc/config.gz > .configAgain, at the top level of the extracted source from kernel.org:
$ make EXTRAVERSION=-arch1 modules_prepare(change the -arch1 part if your kernel uses a different extraversion)
cd to the pinctrl module folder:
$ cd drivers/pinctrlpatch the file.
$ patch pinctrl-amd.c ~/Downloads/0001-pinctrl-amd-Fix-handling-of-PIN_CONFIG_BIAS_PULL_UP-.patchcompile the patched module:
$ make -C /lib/modules/`uname -r`/build M=`pwd`This will create, among other files, pinctrl-amd.ko
package/compress it with zstd so it corresponds to the format of the other modules in /lib/modules/5.15.2-arch1-1
$ zstd pinctrl-amd.koThis will result in a file called pinctrl-amd.ko.zst
make a backup of the module being currently used and copy the new one to /lib/modules/5-15.2-arch1-1
$ sudo cp /lib/modules/5.15.2-arch1-1/kernel/drivers/pinctrl/pinctrl-amd.ko.zst /lib/modules/5.15.2-arch1-1/kernel/drivers/pinctrl/pinctrl-amd.ko.zst.bak
$ sudo cp ./pinctrl-amd.ko.zst /lib/modules/5.15.2-arch1-1/kernel/drivers/pinctrl/pinctrl-amd.ko.zstIf you want to revert, then you can rename the pinctrl-amd.ko.zst.bak back to pinctrl-amd.ko.zst which overwrites the patched one we just created.
reboot
Upon reboot, your kernel will use the patched pinctrl-amd kernel module.
Last edited by jdoggsc (2021-12-03 16:35:32)
Offline
Shouldn't step 4 be run before 'zcat /proc/config.gz > .config'?
I will give the patch a go and so far it seems to be working. Having touchpad problem with dell inspiron and although the problem currently occurs less often (not sure if that's because of changes made to kernel recently or something else) it's still coming back randomly.
Last edited by magillos (2021-12-03 16:16:58)
Offline
you're right. make mrproper would have cleared the .config file created by the zcat command. I edited the steps. Thanks.
Offline
Yet another day without the issue. The patch seems to be working! It would be great if it could be included in the kernel...
And thanks for your very clear guide!
Meanwhile, I will be using this ugly script to speed up the process:
vers=5.15.6 #edit
extra=arch2 #edit
cd ~/Downloads
wget -c https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-$vers.tar.xz
tar -xf linux-$vers.tar.xz
cd linux-$vers
make mrproper
zcat /proc/config.gz > .config
make EXTRAVERSION=-$extra modules_prepare
cd drivers/pinctrl
patch pinctrl-amd.c ~/Downloads/0001-pinctrl-amd-Fix-handling-of-PIN_CONFIG_BIAS_PULL_UP-.patch
make -C /lib/modules/`uname -r`/build M=`pwd`
zstd pinctrl-amd.ko
sudo cp /lib/modules/$vers-$extra-1/kernel/drivers/pinctrl/pinctrl-amd.ko.zst /lib/modules/$vers-$extra-1/kernel/drivers/pinctrl/pinctrl-amd.ko.zst.bak
sudo cp ./pinctrl-amd.ko.zst /lib/modules/$vers-$extra-1/kernel/drivers/pinctrl/pinctrl-amd.ko.zst
rm ~/Downloads/linux-$vers.tar.xz
rm -fr ~/Downloads/linux-$versLast edited by magillos (2021-12-07 23:52:08)
Offline
I'm glad it's working for you!
After making this fix, I didn't notice problems for a few days in a row and then it was like the fix just stopped being the fix. I wondered if had loaded the wrong kernel version at boot and so rebooted but it came back again. Updated the kernel. patched the module, rebooted, still there.
In the bugzillla.kernel.org thread I linked in my post above, Austin said in comment 31 on May 14 that he applied the DSDT modification suggested by Mario Limonciello in comment 26. 2 weeks later, he reported back that the DSDT modification seems to have fixed his problem. The rest of the thread is trying to fix it through kernel code rather than DSDT. Austin also, as of August, wasn't getting a full fix from the patch here.
With just this patch, I couldn't believe I had gone as long as 2 days without my cursor freezing, but it's not the fix for me that I thought it was.
I spent last night trying to load a modified DSDT through initrd and grub. I tried it like 5 times in a row and saw no evidence in dmesg that it loaded. (Here's the how-to article on the wiki if you're interested in trying. I also referenced Austin Kilgore's steps from the bugzilla thread.)
I ended up needing to just compile the DSDT modification into the kernel (the arch Wiki tells how). It just took a while and is not the easy path forward I was hoping for. I haven't had much time since doing that to see if it's been on good behavior. Time will tell.
If you also find you need to go through this DSDT-modification process, please share your results. If this doesn't fix it for me I'm getting a new laptop with an intel CPU. I've dealt with this problem for over a year now and I'm not going to deal with it for another year. I can deal with an occasional kernel recompile, though.
Offline
I tried recompiling DSDT before in an attempt to fix some other issue and I remember failing so I wouldn't really bother, especially with that patch doing the job so far, but I hope it helps you.
It's possible that our issues are different, I'm not sure. When it occurs my cursor moves very erratically, almost as I had my hands wet and tapping doesn't work. Only reboot(s) helps. It looks exactly as on the video in this reddit thread (I never experienced that in Windows though but probably haven't spent enough time on it):
https://www.reddit.com/r/Dell/comments/ … ms_on_his/
The only error I could ever see was in xorg log
Touchpad: kernel bug: Touch jump detected and discarded.and it only appears when using libinput rather than synaptics drivers that I am using right now buy the problem exists for both of the drivers.
Offline
compiling a modified DSDT doesn't fix the problem
Offline
compiling a modified DSDT doesn't fix the problem
And the issue is back for me too...
I might now try to compile libinput with hysteresis disabled. Some people reported it to solve the problem but somehow I doubt it will make a difference.
Edit: no difference after disabling hysteresis, probably even worse behavior.
But if you want to try it yourself:
asp checkout libinput
cd libinput/repos/extra-x86_64
makepkg -oEdit line 203 of /tmp/makepkg/libinput/src/libinput-1.19.2/src/evdev-mt-touchpad.c file and set it to false or comment it out with
//(I think it should be sufficient to turn hysteresis off but I also tried what is included in the patch from outdated pkgbuild on AUR and that).
makepkg -eito install.
I'm back to synaptics driver as it at least seems to work most of the time.
Last edited by magillos (2021-12-13 17:10:25)
Offline