Buttons do not work after restart

[mohapatra-sambit]

Hi,

I am new to Ubuntu and all I was trying to was to make my Logitech MX Anywhere 2 work with Ubuntu.
I have some additional buttons which I configured using input-remapper. It worked like a charm.
But then everything got reset once I restart the system. Below are the steps I followed to get things done:

1. Downloaded input-remapper-1.4.0.deb file.
2. Double-clicked and installed the same.
3. Open the application and selected the mouse from the drop-down.
4. Configured the keys as per my requirements. Screenshot attached.
5. Clicked on Apply, waited for some time and closed the application.
6. All the buttons worked according to the configurations.
7. Restarted the system. None of the buttons worked as expected.
8. Checked the service, It seem to run fine. Screenshot attached.

In the first image, if I click on Apply again, the buttons will start working as expected.
For your reference, I am also attaching a zip file that contains the config files (.config folder).
Please let me know if I am, missing anything.
input-remapper.zip

Thanks in advance!

Sambit Mohapatra

[sezanzeb]

what happens if you run input-remapper-control --command autoload right after logging in?

[mohapatra-sambit]

This is what got printed in the terminal when I executed input-remapper-control --command autoload :

But the buttons didn't work.

[sezanzeb]

is systemctl status input-remapper showing anything after the autoload command?

If not, lets try:

sudo systemctl stop input-remapper
sudo input-remapper-service -d

and afterwards input-remapper-control --command autoload in a separate terminal. Is it injecting now? What is the input-remapper-service command printing?

[mohapatra-sambit]

systemctl status input-remapper printed this:

I, however, went ahead and stopped the service and tried the commands you mentioned.

And in the separate terminal, I executed the autoload command. It worked!!
So can you please suggest me on what I need to do for this to work automatically on system startup?

[sezanzeb]

I don't know yet.

Next time after you booted your computer (don't run any input-remapper-* command), please run sudo evtest and post the complete list of devices

[mohapatra-sambit]

Here you go....

[sezanzeb]

It's very surprising that input-remapper-control --command autoload after logging in doesn't work. Everything looks good

sudo systemctl restart input-remapper
input-remapper-control --command autoload

maybe, for whatever unknown reason, this problem only applies when input-remapper is running via systemd. So please try the above as well.

[mohapatra-sambit]

That worked as well!

[sezanzeb]

are you really 100% sure that running input-remapper-control --command autoload after you logged in (without running anything prior to that) does not work?

[mohapatra-sambit]

Now that you are asking this, I would say, I am 99% sure.
Let me restart my system and try the above 2 commands.
I will let you know in some time.

[sezanzeb]

2 commands? Just the autoload please. Afterwards systemctl status would be interesting to check if the service is receiving anything

[mohapatra-sambit]

Ok, I restarted my system and then tried the following...

It was working.

[sezanzeb]

Ok, if you turn off your mouse and turn it on after you logged in, does the injection start?

There were some issues in the past with bluetooth devices, for which the udev rule https://github.com/sezanzeb/input-remapper/blob/main/data/99-input-remapper.rules was added: #25.

This udev rule should trigger when your mouse connects in order to autoload for it.

[sezanzeb]

What does systemd-analyze print?

[JackDeSomeTrades]

I have the exact same issue as the OP. Same system config as well as far as I can tell - Ubuntu 20.04 and KDE. Remapped bluetooth mouse buttons no longer work after restart until I run the input remapper gui and provide the su password.

On the other hand, it works without a hitch on my other computer (Ubuntu 18.04, KDE) which has a wired mouse i.e., the config persists even after restarting the computer.

[sezanzeb]

@JackDeSomeTrades if you unplug and reconnect the bluetooth mouse after logging in, does the injection that is configured to autoload start?

[JackDeSomeTrades]

Just tried it. It doesn't work.

[sezanzeb]

Thanks! Maybe we can find the issue by going via that route.

Please run this:

sudo udevadm control --log-priority=debug
journalctl -f | grep input-remapper

and then reconnect the mouse again. It is expected that after a few seconds some logs from /bin/input-remapper-control are appearing (if autoload is correctly set, and if there is not an issue with the small udev rule file). If input-remapper-control throws an error, it will be visible there.

[JackDeSomeTrades]

Feb 01 17:08:34 tenebrous systemd-udevd[119182]: input29: /usr/lib/udev/rules.d/99-input-remapper.rules:8 RUN '/bin/input-remapper-control --command autoload --device $env{DEVNAME}'
Feb 01 17:08:34 tenebrous systemd-udevd[119182]: input29: Running command "/bin/input-remapper-control --command autoload --device "
Feb 01 17:08:34 tenebrous systemd-udevd[119182]: input29: Starting '/bin/input-remapper-control --command autoload --device '
Feb 01 17:08:34 tenebrous systemd-udevd[119182]: input29: Process '/bin/input-remapper-control --command autoload --device ' failed with exit code 1.
Feb 01 17:08:34 tenebrous systemd-udevd[119182]: input29: Command "/bin/input-remapper-control --command autoload --device " returned 1 (error), ignoring.
Feb 01 17:08:34 tenebrous systemd-udevd[119189]: input30: /usr/lib/udev/rules.d/99-input-remapper.rules:8 RUN '/bin/input-remapper-control --command autoload --device $env{DEVNAME}'
Feb 01 17:08:34 tenebrous systemd-udevd[119189]: input30: Running command "/bin/input-remapper-control --command autoload --device "
Feb 01 17:08:34 tenebrous systemd-udevd[119189]: input30: Starting '/bin/input-remapper-control --command autoload --device '
Feb 01 17:08:34 tenebrous systemd-udevd[119190]: input31: /usr/lib/udev/rules.d/99-input-remapper.rules:8 RUN '/bin/input-remapper-control --command autoload --device $env{DEVNAME}'
Feb 01 17:08:34 tenebrous systemd-udevd[119190]: input31: Running command "/bin/input-remapper-control --command autoload --device "
Feb 01 17:08:34 tenebrous systemd-udevd[119190]: input31: Starting '/bin/input-remapper-control --command autoload --device '
Feb 01 17:08:34 tenebrous systemd-udevd[119189]: input30: Process '/bin/input-remapper-control --command autoload --device ' failed with exit code 1.
Feb 01 17:08:34 tenebrous systemd-udevd[119189]: input30: Command "/bin/input-remapper-control --command autoload --device " returned 1 (error), ignoring.
Feb 01 17:08:34 tenebrous systemd-udevd[119190]: input31: Process '/bin/input-remapper-control --command autoload --device ' failed with exit code 1.
Feb 01 17:08:34 tenebrous systemd-udevd[119190]: input31: Command "/bin/input-remapper-control --command autoload --device " returned 1 (error), ignoring.

This is what it throws up.

Quick edit: So the remapped keys were working until I disconnected them and reconnected them. I guess this has nothing to do with restarting the computer in as much registering a new bluetooth device via USB? I don't have a compatible wired mouse on me right now to check if I have the same issue with that.

[sezanzeb]

ah, the device is missing there for whatever reason.

Running command "/bin/input-remapper-control --command autoload --device " should print something like Running command "/bin/input-remapper-control --command autoload --device /dev/input/event5" instead.

[JackDeSomeTrades]

Yes this makes sense. The conf gets loaded the moment I input the sudo password in the GUI to relaunch input remapper (i.e., it gets access to /dev/) to search for the device.

Can input remapper get elevated privileges in perpetuity?

[sezanzeb]

input-remapper-control already has root privileges via udev

Please try udevadm monitor --environment --udev --subsystem input and plug in your bluetooth mouse. This will print the available variables for the udev rule. I would expect DEVNAME to be empty there since it seems to be missing from the command as shown by journalctl

[JackDeSomeTrades]

https://pastebin.com/FypswgQt

This is the output after running udevadm monitor --environment --udev --subsystem input.

[sezanzeb]

DEVNAME seems to be there though.

sudo nano /usr/lib/udev/rules.d/99-input-remapper.rules and change it to:

ACTION=="add", SUBSYSTEM=="input", RUN+="/bin/input-remapper-control --command autoload"

Then run sudo udevadm control --reload-rules and reconnect the bluetooth mouse. Does the injection start automatically now?

This will try to autoload the presets for every device, each time any device connects, which of course is not how it should be. But if this works it would give me a hint what to do about it.

[JackDeSomeTrades]

Tried this now but no. No automatic injection.

[sezanzeb]

anything insightful from

sudo udevadm control --log-priority=debug
journalctl -f | grep input-remapper

?

The only bad workaround for this I can think of otherwise would be to add a new file /etc/xdg/autostart/input-remapper-autoload-delayed.desktop with

[Desktop Entry]
Type=Application
Exec=bash -c "sleep 5 && input-remapper-control --command autoload"
Name=input-remapper-autoload
Icon=/usr/share/input-remapper/input-remapper.svg
Comment=Starts injecting all presets that are set to automatically load for the user

assuming that a delay of 5 seconds is enough

[sezanzeb]

If that works, /usr/lib/udev/rules.d/99-input-remapper.rules should be changed back to

ACTION=="add", SUBSYSTEM=="input", RUN+="/bin/input-remapper-control --command autoload --device $env{DEVNAME}"

to avoid more problems

[sezanzeb]

ToDo:

• don't send --device, but rather tell the daemon to look for new devices and autoload for them (if this turns out to have downsides, maybe only do this if DEVNAME is not set)
• if the daemon can't see the device at the provided path, it should look for it a second time after a few seconds