You are not logged in.
The changelog of Linux 5.11 seems like 2/3 of the commits are concerning the new AMD Platforms.
I think you misunderstood something coming up with the 2/3 figure see:
lwn: 5.11 Merge window, part 1 and lwn: 5.11 Merge window, part 2
$ git log --oneline v5.10..v5.11-rc4 | wc -l
14252
$ git log --oneline v5.10..v5.11-rc4 -- drivers/gpu/drm/amd | wc -l
935
$ git log --oneline v5.10..v5.11-rc4 -- drivers/platform | wc -l
99
$ git log --oneline v5.10..v5.11-rc4 -- arch/x86 | wc -l
323Offline
I don't remember the topic, but read about the changes of 5.11 somewhere on kernel.org.
One additional observation: while the bug happens, and the cursor stops moving, until I had lifted all finger, hid-recorder still shows "normal" input.
By "normal", you mean numbers continue to scroll up and update, but the cursor just doesn't move?
When my cursor pauses, the output of hid-recorder also pauses. I'm using 5.11-rc4
Offline
just compiled 5.11-rc5 and no improvement. I went back to tthe Manjaro thread and downloaded the pinctrl-amd fix that coiby made. He said it shouldn't be the fix for the problem, and it was made for the intent of helping out with a Microsoft, so no surprises there, but I was hopeful anyway. I'm completely out of ideas.
Offline
Additional Information:
When the bug occurs
hid-recorderstill gets input, whereas
libinput debug-eventsshows nothing anymore.
So my conclusion is, that not the kernel, but libinput is the main culprit.
I will look at the issues at
https://gitlab.freedesktop.org/libinput … t/-/issues
and if I don't find anything similar open a new one over there.
This problem still seems to be happening on all distros.
Offline
For those still following I filed a report at
Offline
Thanks for all your research and suggestions! I have the same problem on my Asus Vivobook 15 X512, with a Ryzen 3. I have tried numerous suggestions with no luck. I most recently tried turning the power control for the touchpad from auto to on as per the website: https://wiki.ubuntu.com/DebuggingTouchpadDetection
I did this by creating a script in /usr/local/bin/touchpad-fix.sh with the contents:
#!/bin/sh
# Set the touchpad to on to disable power management
sleep 5
echo "on" > "/sys/devices/platform/AMDI0010:01/i2c-0/i2c-FTE1200:00/0018:0B05:0701.0001/input/$(cat /proc/bus/input/devices | grep Touchpad -A 2 | grep -o 'input[0-9][0-9]')/power/control"I then created a system service in /etc/systemd/system/touchpad-fix.service with contents:
[Unit]
Description=Turn off power management for touchpad
[Service]
Type=oneshot
ExecStart=/usr/local/bin/touchpad-fix.sh
RemainAfterExit=true
ExecStop=
StandardOutput=journal
[Install]
WantedBy=multi-user.targetI then enabled the service:
systemctl enable touchpad-fix.service This seemed to decrease the touchpad errors, but not get rid of them completely.
I am now trying to change some BIOS settings to see if this makes any difference. I am turning off anything that might conflict with the touchpad:
Function Lock - Toggles the behaviour of the function key when pressing Fn+Esc
USB Mass Storage Support
Fastboot - Boots with a minimal set of drivers
I wonder if fastboot is causing a problem, just a hypothesis. If things improve, I'll likely try turning things on one at a time. If it doesn't improve, I might see if I can downgrade the BIOS in case it is a regression in the BIOS code.
Offline
No change. The touchpad freezing persists. My BIOS also does not seem to even recognize the Firmware files I downloaded. I'm out of ideas.
Offline
jdoggsc - I tried creating a udev rule based on your template, rebooted and then did sudo libinput list-devices and my Mouse device was gone from the list. After another few reboots I resumed having touchpad issues but when I repeated the sudo libinput list-devices, I found that the Mouse device was listed and had a different event number. I therefore altered your rule and removed the event number so it looks like the following for me:
ACTION=="add|change", ATTRS{name}=="FTE1200:00 0B05:0701 Mouse", ENV{LIBINPUT_IGNORE_DEVICE}="1"On reboot the Mouse device was not listed by sudo libinput list-devices anymore. I also for good measure have added:
ACTION=="add|change", ATTRS{name}=="Asus WMI hotkeys", ENV{LIBINPUT_IGNORE_DEVICE}="1"Just in case WMI hotkeys was causing a problem as well. Now both are ignored and don't show up under libinput list-devices.
I wonder if this may have been why it failed to work for you? I am still testing these modifications on my system, hopefully they will work.
Offline
Pleas share your experience. I abandoned any expectations that udev rules could help out with fixing this long ago.
linos' problem sounds similar to mine, but is different. His is apparently caused by the xorg libinput driver. Mine is clearly a kernel problem. You probably have the same situation as I do. I didn't mess with bios/power settings because the touchpad works perfectly in Windows. Didn't mess around with power settings yet because I have no understanding how they would be related to this.
I literally have no direction on this. The task of understanding AMD interrupt processing is too large for me to undertake right now. I'm holding on a while longer in hopes that this issue will be addressed by Kernel devs, but I can't live like this for years. If there's no indication that devs recognize this is a problem and are working on it, and If I can't figure out how to debug this problem and contribute to the kernel code, I'll probably have to sell my laptop after a few more months. I already hate using it as-is for this singular reason.
Offline
I have tap to click set to on and two finger natural scrolling. My touchpad was intermittently freezing on the screen for up to 30 seconds at a time. When the touchpad freezes over scrollable content, any finger movement would scroll the content but not move the cursor. Also tap to click was also intermittently refusing to work for about the same duration. Two finger tap to right click would also intermittently fail.
Now with changing the power settings, updating to kernel 5.11rc6 with a module enabling acpi calls via /proc/acpi/call, turning off fastboot in the bios, blacklisting the mac_hid kernel module and implementing the udev rules above the tap to click has been consistently working over the last 24 hours. I still get infrequent freezing of the cursor but it seems to last only a second or two as opposed to lasting up to 30 seconds like before. I am really not sure what has made the difference if any, but at least the machine is now usable with only an infrequent minor annoyance, so I am inclined to leave it for a bit to see if i have any longer failures. I will report back if that becomes the case.
I will also note that I tried pop_os and manjaro with no improvement. I even booted to an X11 session in manjaro and forced the synaptic drivers to load for the touchpad instead of libinput and that also did not change anything. I think in my case it is not solely due to libinput for that reason.
Last edited by jaygambrel (2021-02-16 05:23:45)
Offline
Also I had updated my script to ensure that all the power controls for the touchpad device were set to on, leaving only the one for the "mouse" set to auto:
#!/bin/sh
# Set the touchpad to on to disable power management
sleep 5
echo "on" > "/sys/devices/platform/AMDI0010:01/i2c-0/i2c-FTE1200:00/0018:0B05:0701.0001/input/$(cat /proc/bus/input/devices | grep Touchpad -A 2 | grep -o 'input[0-9][0-9]')/power/control"
echo "auto" > "/sys/devices/platform/AMDI0010:01/i2c-0/i2c-FTE1200:00/0018:0B05:0701.0001/input/$(cat /proc/bus/input/devices | grep Mouse -A 2 | grep -o 'input[0-9][0-9]')/power/control"
echo on > "/sys/devices/platform/AMDI0010:01/i2c-0/i2c-FTE1200:00/0018:0B05:0701.0001/power/control"
echo on > "/sys/devices/platform/AMDI0010:01/i2c-0/i2c-FTE1200:00/power/control"
echo on > "/sys/devices/platform/AMDI0010:01/power/control"Again, not sure this has any effect as it is happening intermittently enough now that I am having a hard time telling which interventions have helped.
Last edited by jaygambrel (2021-02-16 05:32:44)
Offline
I wonder in my case if there is a bug causing an issue involving communication between the kernel and userspace drivers that is being partially mitigated by one or more of these interventions. I wish I had time to delve deeper into this but I don't really at this point.
Offline
Anything touch-related freezes on my laptop. I can still press to click, but touch-to-click, and cursor movement freeze. When it happens, I can pause my finger for 2 seconds or so and it will start moving again. It's random as to whether it will happen again immediately the next time I lift my finger and put it down again.
One thing that is consistent, though. Let's say there's a 2-second countdown before touches will respond again (with finger staying on the trackpad, waiting). If it stops responding and I lift my finger before the 2-second countdown finishes, then it effectively resets the countdown. So if I repeatedly lift my finger and put it back on the trackpad again rapidly (meaning less than 2 seconds between times that my finger lands on the pad, then the problem will essentially persist indefinitely. I've taken it past 30 seconds.
I wonder in my case if there is a bug causing an issue involving communication between the kernel and userspace drivers that is being partially mitigated by one or more of these interventions
I don't think it's between the kernel and userspace drivers. Open two terminal windows. In window 1, run
$ sudo hid-recorder and choose the device which represents the ELAN touchpad
In terminal window 2, run
$ sudo libinput debug-eventsWhen the touchpad freezes, do you see both windows freeze?
The issue I'm seeing is that both of these freeze. This indicates that the kernel is not processing the interrupt from the i2c hid device. If no data are coming in, then there's nothing for libinput to process--it freezes too. If the output of hid-recorder does not freeze, but libinput does freeze (the problem that linos is apparently experiencing) the it would indicate a failure of libinput to process the data stream from the kernel.
Which are you experiencing?
Offline
I will give it a try when I get a chance and let you know. It is actually my partner's machine and she has mainly been using it now that the errors have been infrequent.
Offline
Well, that was quick. When the cursor completely freezes libinput debug-events freezes and hid-recorder does not. When the cursor gets stuck, but scrolls, both still record data, but the libinput records it as a different type of motion. Sorry didn't catch it. It ended and the events scrolled away before I thought to screenshot. I'll let you know next time it happens.
Offline
Again, that was fast. Libinput records it as pointer axis instead of pointer motion when it gets locked into scroll mode.
Offline
Problem still persists. I'm going to try exclusively grabbing all input from the "Mouse" device at the kernel level using evtest so that input should never even make it to libinput:
sudo evtest --grab "/dev/input/$(cat /proc/bus/input/devices | grep Mouse -A 5 | grep -o 'event[0-9]')"Offline
Hello, I had some similar issues with an elantech touchpad in my laptop. For me, adding i8042.noselftest=1 to the kernel line was necessary to get it working correctly, there apparently is an issue with the system running a self-test on the touchpad on resume, and on some models this makes it freak out and stop working (as far as I understand it, I'm no expert at all).
Normally there are certain models of laptops excluded from this (mainly ASUS laptops), but there might be more. You can check out this recent commit where there was a new model added to the exclusion list: https://git.kernel.org/pub/scm/linux/ke … e4c3b65eb9
If this is totally wrong, I'm sorry, I just recognized the frustration and I hope it can be of help.
Offline
I'll definitely check it out this evening. Anything helps at this point.
Last edited by jdoggsc (2021-03-02 23:34:02)
Offline
evtest --grab did not help me. Thanks Zom. I'll try your suggestion as well. I vaguely remember there are other i8042 kernel flags as well. If this one doesn't work I might look up some others and try them and report back.
Thanks again.
Offline
No luck with the noselftest flag. Here were some other flags that were referenced on https://bugzilla.kernel.org/show_bug.cgi?id=209199 with regards to touchpad detection problems
i8042.noloop i8042.nomux i8042.nopnp i8042.resetI'll try them as well.
Offline
No luck with the noselftest flag. Here were some other flags that were referenced on https://bugzilla.kernel.org/show_bug.cgi?id=209199 with regards to touchpad detection problems
i8042.noloop i8042.nomux i8042.nopnp i8042.resetI'll try them as well.
I already tried those with no luck
Offline
Hello, I had some similar issues with an elantech touchpad in my laptop. For me, adding i8042.noselftest=1 to the kernel line was necessary to get it working correctly, there apparently is an issue with the system running a self-test on the touchpad on resume, and on some models this makes it freak out and stop working (as far as I understand it, I'm no expert at all).
Normally there are certain models of laptops excluded from this (mainly ASUS laptops), but there might be more. You can check out this recent commit where there was a new model added to the exclusion list: https://git.kernel.org/pub/scm/linux/ke … e4c3b65eb9
If this is totally wrong, I'm sorry, I just recognized the frustration and I hope it can be of help.
my laptop does not even use the i8042 module, so loading it did nothing
Offline
Zom wrote:Hello, I had some similar issues with an elantech touchpad in my laptop. For me, adding i8042.noselftest=1 to the kernel line was necessary to get it working correctly, there apparently is an issue with the system running a self-test on the touchpad on resume, and on some models this makes it freak out and stop working (as far as I understand it, I'm no expert at all).
Normally there are certain models of laptops excluded from this (mainly ASUS laptops), but there might be more. You can check out this recent commit where there was a new model added to the exclusion list: https://git.kernel.org/pub/scm/linux/ke … e4c3b65eb9
If this is totally wrong, I'm sorry, I just recognized the frustration and I hope it can be of help.
my laptop does not even use the i8042 module, so loading it did nothing
Ah, too bad. Hope it works out!
Offline
Unfortuntately didn't work for me either. Thanks for trying though.
Offline