You are not logged in.
After upgrading using pacman -Syu, my keyboard goes back to the default repeat rate (how fast a key repeats when you hold down on a key, I prefer it for cursor-ing around.)
I use xset in xinitrc to set the repeat rate:
xset r rate 220 40
I can find two threads from 2023 about similar issues, about the keyboard layout reverting from each update. There were suggestions for workarounds, but it seems like it was a bug that fixed itself (I use a non-default keyboard layout through localectl and I'm not reporting that issue).
https://bbs.archlinux.org/viewtopic.php?id=290696
https://bbs.archlinux.org/viewtopic.php?id=288550
The solution, with the caveat that the setting doesn't apply just to one's user, by @seth is placing a file in /etc/X11/xorg.conf.d (https://wiki.archlinux.org/title/Xorg/K … tion_files)
The wiki lists 3 different solutions. The issue appears to be somewhat well-trodden. I'd really like to find out if there's a more satisfactory way than all the solutions so far because:
1. xset alone reverts too easily
2. No one seems keen on using xautocfg from the AUR
3. Placing a config file in xorg.conf.d applies my setting to all users
4. A startup option combination for XServer (-ardelay, -arinterval) can set the repeat rate, but this doesn't generalize to other settings.
Settings, be them in xset or xinput, generally do not persist.
I might set middle-click emulation for a mouse (at the expense of a bit of latency), and other users might prefer not having it. As a user, I might run xinput set-prop "SynPS/2 Synaptics TouchPad" "libinput Middle Emulation Enabled" 1, but this gets reverted if the device is so much as unplugged and re-plugged. The wiki page on libinput doesn't list a persistent, per user solution.
Some listener such as xautocfg might really be the solution.
Last edited by Affaisseras (2026-03-07 23:28:44)
Offline
I just tested xautocfg and it really works for detecting that keyboards have just been plugged in. However, it doesn't detect mice, and so the problem remains of a setting like middle mouse button emulation, set through xinput, not persisting.
You can run a script whenever a mouse/keyboard is hotplugged if you install this udev rule and a systemd service that runs as a user instance, the service has access to your X enviroment. (which would be hard with just a udev rule)
$ systemctl --user enable --now hid-hotplug.path
/etc/udev/rules.d/99-hid-hotplug.rules
ACTION=="add|change", SUBSYSTEM=="input", DEVPATH=="*/event*", ENV{ID_TYPE}=="hid", RUN+="/usr/bin/touch /var/tmp/hid-hotplug.notif'"~/.config/systemd/user/hid-hotplug.path
[Unit]
Description=Subscribe to notifications of plugged-in devices
After=graphical.target
[Path]
PathChanged=/var/tmp/hid-hotplug.notif
Unit=hid-hotplug.service
[Install]
WantedBy=default.target~/.config/systemd/user/hid-hotplug.service
[Unit]
Description=Re-apply input settings for just plugged-in devices
[Service]
Type=oneshot
# Execs any script
ExecStart=notify-send "Hi from hid-hotplug"
ExecStart=kbd-repeat
[Install]Last edited by Affaisseras (2026-03-07 23:27:01)
Offline
That approach seems much more solid than hacks that off of udev launch systemd-run on a hardcoded user, or the approach I had of running the script for all X processes. Here a user can choose to enable the systemd service to become a "subscriber".
You can also persist any settings you've changed outside of a script through xset or xinput. I override the xset and xinput command to keep a record of all commands that have been issued. This is stored in /tmp/hid-settings, a script that I configured hid-hotplug.service to execute.
An override script can be created at (or linked from) ~/.local/bin/xset, and as long as the environment variable PATH is set up like PATH="$HOME/.local/bin:$PATH the xset command will work just as before, but a record is stored in /tmp/hid-settings.
#!/usr/bin/env bash
me="$(basename "$0")"
# Create the base for the script if doesn't already exist
if [ ! -f /tmp/hid-settings ] || [ ! -x /tmp/hid-settings ]; then
echo '#!/usr/bin/env bash' > /tmp/hid-settings
chmod +x /tmp/hid-settings
fi
# The real xset/xinput on the system is invoked with its original parameters. If
# xset/xinput looks like it did something (the && ternary) we're recreating the
# invocation to append to the script.
# NOTE: xset doesn't seem to ever emit an unsuccessful exit code when you
# use the command syntax incorrectly. Only invalid xinput invocations are
# filtered from the script.
# The %q printf spec should prevent shell injection.
/usr/bin/"$me" "$@" && {
{ printf '%q ' /usr/bin/"$me" "$@" ; printf '\n' ; } >> /tmp/hid-settings
}Last edited by Affaisseras (2026-03-07 23:30:59)
Offline