Input-remapper needs CONSTANT restarting!

[eobet]

Input-remapper stops remapping if I close the laptop lid or even if my bluetooth trackball temporarily (for just a few seconds) loses connection... sometimes it feels as if just the trackball goes into power-saving mode the remappings are lost.

So, this happens several times per day.

This only happened after the latest Fedora 40 update I applied using the Nobara (the old Gnome flavor) system updater... but I'm new at Linux, so not sure why this happened.

Running the systemctl command again does not matter.

Leaving the input-remapper app open also does not matter, and while it may look like it's working fine, the Apply and Stop buttons just stop working, and I have to close the app and start it again (which always prompts me for the root password).

[RedSnt]

Is /usr/bin/python3 /usr/bin/input-remapper-service --hide-info running when you resume using you computer? I'd assume the point of the service was to keep track of whether the remapping had been overwritten.

[eobet]

Thank you for the tip! I'm new to Linux and I guess I shouldn't just paste any command in the terminal but this felt relatively safe:

eobet@surface:~$ /usr/bin/python3 /usr/bin/input-remapper-service --hide-info
Loaded config from "/home/eobet/.config/input-remapper-2/config.json"
WARNING: The service usually needs elevated privileges
ERROR: Is the service already running? (name already exists on the bus)
Stopping all injections

So, the input-remapper-service is running, but it's not remapping?

Possibly unrelated, but Godot Engine is just now in the process of adding Wayland support and it gets three keyboards reported from my laptop after I wake it from sleep (it's a Microsoft Surface Studio) which causes issues for them...

[RedSnt]

I'm new to linux as well, so I'm not much help besides trying to pinpoint the problem for you :)

I found something that might work as a workaround if you can get something like this to trigger every time you wake up/resume your PC: https://github.com/sezanzeb/input-remapper/discussions/850

I'm not much help regarding a SystemD solution as I'm on MX Linux, but you might get away with using a script by putting it in /usr/lib/systemd/system-sleep as described here. The parts that the discussion I linked should go in the "post" part.

So something like this:

#!/bin/sh

PATH=/sbin:/usr/sbin:/bin:/usr/bin

case "$1" in
    pre)
            #code execution BEFORE sleeping/hibernating/suspending
    ;;
    post)
            #code execution AFTER resuming
            sleep 30 && input-remapper-control --command start --device "USB Optical Mouse" --preset "my_awesome_preset"
    ;;
esac

exit 0

~~Not sure if the sleep is necessary, most likely not, so just remove the sleep 30 or change it around, I was just thinking something else might be overwriting the remapping on resume. Also, the device and preset names ought to be changed so it matches your system.
Oh and don't forget to chmod +x yourScriptFile to make it executable.~~

EDIT: Seems like I'm trying to reinvent the wheel here. There's already a discussion going here: https://github.com/sezanzeb/input-remapper/issues/390

So to debug you'd need to run journalctl -b | grep input-remapper after your system wakes up and input-remapper isn't working. There's still hope for a SystemD script method, one linked to here combined with input-remapper-control --command autoload.

[eobet]

Well, I just checked by switching on and off on my Bluetooth trackball, and I had to restart input-remapper and apply the mappings again, so for me, it's not only sleep but almost anytime the bluetooth reconnects too.