| Summary: | Running "sudo udevadm trigger -s input" resets touchpad configuration; can happen after system upgrade | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | joey.joey586 |
| Component: | kcm_touchpad | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aalexandera, abdullah.kasim.123, bugseforuns, cuchac, david0rh, gerrysw11, giraffeFile+kde, io, justin.zobel, katyaberezyaka, kde, linuxadame, nate, postix, robin, sausagefactory0, sean, v, y |
| Priority: | HI | ||
| Version: | 5.17.5 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=413973 https://bugs.kde.org/show_bug.cgi?id=435113 |
||
| Latest Commit: | https://invent.kde.org/plasma/plasma-desktop/commit/eb0f45dfb1da15631d6f768bad55051ab478c38a | Version Fixed In: | 5.27 |
| Sentry Crash Report: | |||
| Attachments: | Touchpad config window | ||
|
Description
joey.joey586
2019-11-27 07:09:48 UTC
Are you using the Libinput driver, or Synaptics? If you're not sure, please attach a screenshot showing what the Touchpad KCM looks like for you. Created attachment 124304 [details]
Touchpad config window
I think it's using libinput since I don't have synaptics installed
Thanks. This is a bug in Libinput itself, not our configuration module. Please report it upstream to the Libinput devs: https://gitlab.freedesktop.org/libinput/libinput/issues Thanks! @Nate Graham I'm not entirely sure this is a libinput bug, since I tried running this on two Fedora 31 live ISOs and: 1) "sudo udevadm trigger -s input" had no effect on GNOME live iso 2) running this on KDE live iso caused the touchpad to stop working, like on my Arch KDE system 3) They are both running libinput Darn. @Nate Graham Sorry for the late reply, but I have tested it on another laptop I have: a Lenovo Ideapad s10-3s that uses a synaptics syn/ps2 touchpad and the bug did occur on this device. (I also have another device, an MSI vr420, but I was unable to test on this device since the laptop has only 1gb RAM and the Fedora KDE ISO was not able to run with that little RAM) Also, Jan Przybylak in https://bugs.kde.org/show_bug.cgi?id=413973 mentions that the bug also occurs on his laptop. The problem: the laptops tested are lenovo laptops, so still unsure if this is a lenovo-specific bug or not. *** Bug 419533 has been marked as a duplicate of this bug. *** *** Bug 421069 has been marked as a duplicate of this bug. *** *** Bug 423315 has been marked as a duplicate of this bug. *** Also experiencing on Solus 4.1 Plasma Plasma 5.18.5 Frameworks 5.70.0 Let me know if any logs might be of use, happy to provide. Urgh, dupes piling up, marking as VHI. It is quite annoying and mysterious when it happens. I can intermittently reproduce this when I perform a system upgrade on openSUSE TUmbleweed. I guess there's some package that runs `udevadm trigger -s input` as a post-install step which triggers this bug. I haven't been able to find how the touchpad code reacts to that signal yet. Possibly related -- As a Solus Plasma user who is also experiencing touch pad settings being reset every time a system update is performed, the following also occurs at every system update: The Plasma Vault widget becomes empty. Restart, and the vault(s) are back; it's the same with the touch pad settings. This may be distro-specific. We have reports from people on Arch, Fedora, openSUSE Tumbleweed, and Solus. One person on Gentoo cannot reproduce it. No reports from anyone using Debian/Ubuntu-based distro. duplicate bug 419533 happened on neon unstable. Ah, thanks! So I guess it's happening virtually everywhere but Gentoo then. FWIW since moving from openSUSE Tumbleweed to Fedora, I haven't seen this again. However my wife who uses Neon does see it. The triggering event somehow seems to be distro-packaging-specific. Still, we should fix the issue on the KDE side so that whatever does this doesn't reset your touchpad configuration. (In reply to Nate Graham from comment #16) > FWIW since moving from openSUSE Tumbleweed to Fedora, I haven't seen this > again. However my wife who uses Neon does see it. > > The triggering event somehow seems to be distro-packaging-specific. > > Still, we should fix the issue on the KDE side so that whatever does this > doesn't reset your touchpad configuration. this does happen to me on Fedora 35 (just tried it) and happened on previous versions On power up the left-hand radio button is checked but the mouse is right-handed. To persuade the mouse to be left-handed I have to toggle the radio button twice. This only happens to me on an laptop. I never see it on my desktop. I upgraded my KDE Neon (5.24) system over the weekend and this started to occur for me. I do not have a touchpad at all, I'm using a Logitech MX Ergo with the wireless receiver, and the bug is triggered every time my trackball wakes up from sleep (being wireless the device itself goes into a sleep mode, this is not DPMS or the host sleeping.) The problem does not occur if I briefly (~30s) turn the trackball off and back on again. I can trigger the problem with `sudo udevadm trigger -s input`. Is there a workaround I can use here to make my preferred settings the default settings? I tried `sudo cp ~/.config/kcminputrc /root/.config` but that did not work. Hello, this issue hit me after upgrade to 5.24. Arch Linux here. Mouse sensitivity is reset on each sleep. I can trigger the bug on `sudo udevadm trigger -s input` Hi all, I'm on latest Arch Linux on a desktop and experiencing the same issue. Running the command resets mouse sensitivity settings - tested by lowering mouse sensitivity and then running that command. In my case I use a dock to switch inputs between two computers and so on every switch the mouse sensitivity is reset. Sorry, I didn't realize I can't edit my replies so adding some more information here: Using Xorg, not wayland (although the system does have some wayland packages installed) Using libinput not synaptics. I got here from Bug 435113 which seems more similar to my issue but that report says they did not have an issue with this udevadm command. Let me know if I can provide any additional information or assistance I tried to dig into this problem a little bit and here is what I was able to observe. I still have not figured out how I can either fix or workaround the issue. The first surprising observation is that `sudo udevadm monitor` does not register any output at all at times I would expect it to. For example, there is no output when I run `udevadm trigger -s input` but there is output when I run `sudo udevadm trigger -s input`. This is what I see running that: https://gist.github.com/skullydazed/6a0703258dc9f0a231cebc0395174228 When I unplug and plugin my mouse here is what udevadm shows: https://gist.github.com/skullydazed/855393941da35627e15870b313224b7d Now, here's where things get interesting. I grabbed a second mouse and plugged it in (a Logitech TrackMan Marble.) When I did this my first mouse (Logitech MX Ergo) kept the correct settings but the new mouse had incorrect settings. More interestingly, when I went into System Settings -> Input Devices -> Mouse and changed a setting both mice adopted the correct settings. Steps to reproduce with any 2 mice: 1. Have first mouse plugged in, second mouse unplugged. 2. Go to System Settings -> Input Devices -> Mouse, check "Invert scroll direction", click "Apply". 3. Verify that moving the scroll wheel away from you scrolls a window down. 4. Plug in second mouse 5. Observe that first mouse scrolls down when the wheel is scrolled away from you while second mouse scrolls down when the wheel is scrolled towards you. 6. In the mouse settings window check (or uncheck) "Press left and right buttons together", then click Apply. 7. Observe that both mice scroll identically I believe this bug is classified incorrectly. Based on my observations it seems that the problem is that USB plug events are configuring devices with the default settings rather than the user's settings. I am also running into this issue with two mice. My desktop computer is a qemu/libvirt/kvm virtual machine, which means it has my real passed through USB mouse but by default also an emulated PS/2 mouse. Whenever I unplug my USB mouse and plug it back in, settings like pointer acceleration reset. I have a similar issue with mouses on Arch Linux. Either of the things listed below, resets the mouse acceleration to "Adaptive", even though it still shows in Settings UI as "Flat", and then I need to change it two times (to "Adaptive" and then to "Flat") to make it flat again. 1. sudo udevadm trigger -s input 2. simply disconnecting the mouse and then connecting it again to the same USB port ^ Sorry, forgot to add: I'm using KDE with X11, and everything is on a real PC, no VMs involved. (In reply to sausagefactory0 from comment #25) > I need to change it two times > (to "Adaptive" and then to "Flat") to make it flat again. You can avoid changing it two times by changing another setting instead. I toggle "Press left and right buttons for middle-click" one time and it resets all my settings, so I only have to "Apply" once. I wrote a workaround here: https://askubuntu.com/a/1434072/1638910 It's not perfect but it's usable for me currently. Probably the easiest way is to run a 60-second watchdog when udev triggers, but that'll require more scripting effort. (In reply to Abdullah from comment #28) > I wrote a workaround here: https://askubuntu.com/a/1434072/1638910 > > It's not perfect but it's usable for me currently. Probably the easiest way > is to run a 60-second watchdog when udev triggers, but that'll require more > scripting effort. Don't use this workaround. I've deleted it as I've found a better workaround from another poster here: https://bugs.kde.org/show_bug.cgi?id=435113#c88 The issue where mouse settings reset when reconnecting a mouse with multiple mice connected seems to be fixed now that I upgraded from Ubuntu 22.04 to Ubuntu 22.10. Not sure how that relates to the original report though. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1376 Git commit ca59a847bddc906c51fbb41635128f40b1b31a30 by Nate Graham, on behalf of David Edmundson. Committed on 07/02/2023 at 15:55. Pushed by ngraham into branch 'master'. Re-run touchpad kcminit on device connect kcminit runs once on boot then closes. Devices are less static. For mouse and keyboard the keyboard daemon watches for input devices changing and re-runs kcminit modules for both keyboard and mouse. This patch adds touchpad to the list to cover remaining devices. Having this inside the keyboard daemon is not semantically sane, but it's an established pattern and we want a safe fix for 5.27. Fixed-in: 5.27.0 M +4 -4 kcms/keyboard/keyboard_daemon.cpp M +1 -1 kcms/keyboard/keyboard_daemon.h https://invent.kde.org/plasma/plasma-desktop/commit/ca59a847bddc906c51fbb41635128f40b1b31a30 Git commit eb0f45dfb1da15631d6f768bad55051ab478c38a by Nate Graham, on behalf of David Edmundson. Committed on 07/02/2023 at 16:52. Pushed by ngraham into branch 'Plasma/5.27'. Re-run touchpad kcminit on device connect kcminit runs once on boot then closes. Devices are less static. For mouse and keyboard the keyboard daemon watches for input devices changing and re-runs kcminit modules for both keyboard and mouse. This patch adds touchpad to the list to cover remaining devices. Having this inside the keyboard daemon is not semantically sane, but it's an established pattern and we want a safe fix for 5.27. Fixed-in: 5.27.0 (cherry picked from commit ca59a847bddc906c51fbb41635128f40b1b31a30) M +4 -4 kcms/keyboard/keyboard_daemon.cpp M +1 -1 kcms/keyboard/keyboard_daemon.h https://invent.kde.org/plasma/plasma-desktop/commit/eb0f45dfb1da15631d6f768bad55051ab478c38a |