2

I want to make xinput settings for my usb mouse persist after it has been turned off and on again. How can I monitor this event?

This does not work, as I never unplug the usb receiver: How to make xinput settings persist after devices are unplugged, replugged, and after shutdown, restart, etc?

As far as I've understood, udev can be used for HW detection applications, but it doesn't seem to be able to detect state changes in the device such as a Logitech Unifying Receiver.

I guess the key to get this solved is to successfully track events in the Receiver and write a script to execute the xinput command. Would anyone know how I can detect this event? Solaar is off course able to detect this, but that doesn't mean it is simple for a non-expert Linux user.

Thanks!

toxUP
  • 21
  • 5

1 Answers1

0

I solved this issue based on a suggestion that came from another post in unix stack exchange.

In a nutshell I run a background shell script that loops every 2 seconds looking for a change in the mouse, when it find's one it re-runs the xinput command.

The original (and more simple) solution is posted here:

https://unix.stackexchange.com/questions/332573/how-to-make-xinput-commands-permanent/340594#340594

Here's the script I run in ~/.xinitrc:

# Map mouse button 8 (top right) to button 2 (top left) and vice versa, run when changes to the mouse occur
while true; do
        NEW_MOUSEID=$(xinput | grep "Expert Mouse" | grep -o -E '[0-9]+' | head -n 1)
        if [ "$MOUSEID" != "$NEW_MOUSEID" ]; then
                MOUSEID=$NEW_MOUSEID
                if [ "$MOUSEID" != "" ]; then
                        xinput --set-button-map $MOUSEID 1 8 3 4 5 6 7 2 9 10 11 12
                fi
        fi
        sleep 2
done &

Basic structure:

  • Watch for changes in the USB's ID from xinput every 2 seconds
  • If the mouse ID is blank, it's not connected, don't run xinput (you'll get an error if you do)
  • The parsing of the xinput command just returns the USB device ID for mouse "Expert Mouse", ex: "14"

Note that the original answer suggests monitoring for changes in lsusb and re-running the command then, that works just as well.

derHugo
  • 3,376
  • 5
  • 34
  • 52
David Parks
  • 2,586