Bug 414559 - Running "sudo udevadm trigger -s input" resets touchpad configuration; can happen after system upgrade
Summary: Running "sudo udevadm trigger -s input" resets touchpad configuration; can ha...
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_touchpad (show other bugs)
Version: 5.17.5
Platform: Arch Linux Linux
: HI normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 419533 421069 423315 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-11-27 07:09 UTC by joey.joey586
Modified: 2023-02-07 16:52 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.27
Sentry Crash Report:


Attachments
Touchpad config window (70.99 KB, image/png)
2019-12-04 07:32 UTC, joey.joey586
Details

Note You need to log in before you can comment on or make changes to this bug.
Description joey.joey586 2019-11-27 07:09:48 UTC
SUMMARY
Running "sudo udevadm -s input" resets touchpad configuration

STEPS TO REPRODUCE
1. Modify touchpad settings in the System Settings (enable tap-to-click, inverse scrolling, etc.)
2. Apply the changes
3. Run "sudo udevadm trigger -s input"
4. Immediately the settings previously applied in Step 1 is reverted back to defaults (tap-to-click disabled, inverse scrolling disabled, etc.)
5. Logging out and logging back in reverses this effect, however

OBSERVED RESULT
Previously applied touchpad settings resets back to default touchpad settings

EXPECTED RESULT
Running "sudo udevadm trigger -s input" should not have altered the touchpad configuration.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 5.17.3
KDE Frameworks Version: 5.64.0
Qt Version: 5.13.2
Kernel Version: 5.3.11-arch1-1
OS Type: 64-bit
Processors: 3 × , 1 × Intel® Core™ i5-7200U CPU @ 2.50GHz
Memory: 11.5 GiB of RAM


ADDITIONAL INFORMATION
This bug occurs when modifying partitions with Partitionmanager, which calls "udevadm trigger" as root, which in turn caused this unusual touchpad behavior.

Partitionmanager bug here: https://bugs.kde.org/show_bug.cgi?id=413973
Comment 1 Nate Graham 2019-12-02 20:37:24 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.
Comment 2 joey.joey586 2019-12-04 07:32:26 UTC
Created attachment 124304 [details]
Touchpad config window

I think it's using libinput since I don't have synaptics installed
Comment 3 Nate Graham 2019-12-04 16:48:03 UTC
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!
Comment 4 joey.joey586 2019-12-05 19:53:19 UTC
@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
Comment 5 Nate Graham 2019-12-09 17:10:34 UTC
Darn.
Comment 6 joey.joey586 2019-12-22 12:59:53 UTC
@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.
Comment 7 Nate Graham 2020-06-22 16:42:21 UTC
*** Bug 419533 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2020-06-22 16:43:52 UTC
*** Bug 421069 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2020-06-23 00:09:54 UTC
*** Bug 423315 has been marked as a duplicate of this bug. ***
Comment 10 Justin Zobel 2020-06-23 02:29:42 UTC
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.
Comment 11 Nate Graham 2020-06-23 16:04:09 UTC
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.
Comment 12 David 2020-06-27 16:48:46 UTC
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.
Comment 13 Nate Graham 2020-10-05 16:50:29 UTC
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.
Comment 14 Patrick Silva 2020-10-05 17:02:42 UTC
duplicate bug 419533 happened on neon unstable.
Comment 15 Nate Graham 2020-10-05 17:07:35 UTC
Ah, thanks! So I guess it's happening virtually everywhere but Gentoo then.
Comment 16 Nate Graham 2021-11-25 16:15:51 UTC
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.
Comment 17 Mikel Pérez 2021-11-25 17:50:31 UTC
(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
Comment 18 Gerry Gavigan 2022-01-21 10:29:12 UTC
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.
Comment 19 Zach White 2022-02-10 16:06:44 UTC
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.
Comment 20 Cuchac 2022-02-21 06:53:52 UTC
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`
Comment 21 Adam E 2022-03-04 16:47:45 UTC
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.
Comment 22 Adam E 2022-03-04 16:53:32 UTC
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
Comment 23 Zach White 2022-03-04 17:50:31 UTC
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.
Comment 24 robin 2022-05-24 22:34:16 UTC
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.
Comment 25 sausagefactory0 2022-06-14 08:59:16 UTC
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
Comment 26 sausagefactory0 2022-06-14 09:01:09 UTC
^ Sorry, forgot to add: I'm using KDE with X11, and everything is on a real PC, no VMs involved.
Comment 27 Zach White 2022-06-14 15:48:56 UTC
(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.
Comment 28 Abdullah 2022-10-06 13:06:11 UTC
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.
Comment 29 Abdullah 2022-10-06 13:17:32 UTC
(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
Comment 30 robin 2022-11-15 10:10:45 UTC
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.
Comment 31 Bug Janitor Service 2023-02-06 15:22:19 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1376
Comment 32 Nate Graham 2023-02-07 16:51:44 UTC
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
Comment 33 Nate Graham 2023-02-07 16:52:26 UTC
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