How tense, I hope you can solve this.
What brand/model of your notebook? Maybe it has something like this that I found for your notebook.
That works for a legacy boot system. If it is uefi boot the cmmand would be
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
There is a grub change for Fedora 34
It’s happening on this machine and also on this one.
Sadly, that didn’t work either.
Anything I can use?
So you want to add that kernel boot parameter to see if it helps for your touchpad.
This commend work for me:
$ sudo grubby --update-kernel=ALL --args="i8024.nopnp"
You can check your kernel parameters by
$ sudo grubby --info=ALL
So run that before and after the update and make sure they are being changed correctly.
My system is EFI and it worked for me
Thank you for sharing this with me, thankful.
A question, do I have to do this process with each update? And another, why does it work on 34 and not on Rawhide?
I had to format the PC and I have Fedora 34 now, but I intend to put Rawhide back on and live in hardcore mode again.
It seems likely there’s a kernel regression. See bug report above and also the bit on bisecting if you’re interested in helping narrow it down.
Among Fedora 33, the behavior of grub2-config is changing.
For me, it is using my current kernel cmdline to generate new loader entries for kernel updates instead of /etc/default/grub
It seems that the latest kernel solved the issue, not my touchpad works again
Would it be possible to set this permanent configuration? For what I realized with each new kernel I have to perform the same step by step
If it doesn’t work because the default configuration isn’t right, that’s a bug we should fix rather than needing perpetual workarounds.
̶I̶n̶ ̶t̶h̶i̶s̶ ̶n̶e̶w̶ ̶k̶e̶r̶n̶e̶l̶ ̶i̶t̶ ̶d̶o̶e̶s̶n̶’̶t̶ ̶e̶v̶e̶n̶ ̶w̶o̶r̶k̶ ̶e̶v̶e̶n̶ ̶b̶y̶ ̶a̶d̶d̶i̶n̶g̶ ̶t̶h̶e̶ ̶p̶a̶r̶a̶m̶e̶t̶e̶r̶,̶ ̶a̶n̶d̶ ̶i̶t̶ ̶l̶i̶s̶t̶s̶ ̶t̶h̶e̶ ̶E̶l̶a̶n̶T̶e̶c̶h̶ ̶d̶r̶i̶v̶e̶r̶ ̶a̶n̶d̶ ̶e̶v̶e̶n̶ ̶g̶i̶v̶e̶s̶ ̶t̶h̶e̶ ̶t̶o̶u̶c̶h̶p̶a̶d̶ ̶a̶s̶ ̶t̶u̶r̶n̶e̶d̶ ̶o̶n̶ ̶b̶u̶t̶ ̶i̶t̶ ̶d̶o̶e̶s̶n̶’̶t̶ ̶w̶o̶r̶k̶.̶ ̶M̶a̶y̶b̶e̶ ̶I̶ ̶w̶i̶l̶l̶ ̶l̶e̶a̶v̶e̶ ̶t̶h̶e̶ ̶r̶a̶w̶h̶i̶d̶e̶ ̶a̶s̶i̶d̶e̶ ̶a̶n̶d̶ ̶p̶u̶t̶ ̶t̶h̶e̶ ̶3̶4̶ ̶b̶e̶t̶a̶ ̶w̶h̶i̶c̶h̶ ̶i̶s̶ ̶a̶ ̶l̶i̶t̶t̶l̶e̶ ̶m̶o̶r̶e̶ ̶s̶t̶a̶b̶l̶e̶.̶
Edit:
Good to start I needed that part mentioned above, and when searching again I found this by doing until step 3 I got my touchpad back again. I’ll leave the link just ahead.
In case your Touchpad stops working after a while
This is generally a case of a kernel ( linux ) or xorg bug. In this case, in the description field, specify the steps to make the touchpad stop working (e.g. hit a key, drag an icon, after X seconds of inactivity, etc.).
- If your Touchpad stops working after it has been left unused for awhile, it may be due to runtime power-management. Disable runtime power management of the Touchpad device and check if the issue persists.
- Look for your Touchpad device in /proc/bus/input/devices.
- The line starts with S: is the path of the Touchpad device, the full path will be something like /sys/devices/platform/i8042/serio1/input/input5/power/control.
- Disable runtime power-managed by running echo on | sudo tee /sys/devices/platform/i8042/serio1/input/input5/power/control (replace the path with the one for your Touchpad device.
This link Debugging Touchpad Detection helped me
Moving on to warn you that the rawhide image that was generated today solved the touchpad problem at least for me, thanks for all the effort of the team.