5

I want to disable the mouse movement, controlled by a bash-script, so xdotool can take over and bumping the mouse or otherwise won't be an issue.

However, I need the buttons to remain working, so simply disabling the mouse is not an option.

This is the same question as this one, but the solutions there do not work for me. My mouse does not appear to have these properties.

xinput list shows the mouse 3 times. ID 10 has the most properties, with the other two having a subset of options.

Output of xinput list-props 10:

Device 'Logitech Gaming Mouse G502':
Device Enabled (152):   1
Coordinate Transformation Matrix (154): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Accel Speed (290): 0.000000
libinput Accel Speed Default (291): 0.000000
libinput Accel Profiles Available (292):    1, 1
libinput Accel Profile Enabled (293):   1, 0
libinput Accel Profile Enabled Default (294):   1, 0
libinput Natural Scrolling Enabled (295):   0
libinput Natural Scrolling Enabled Default (296):   0
libinput Send Events Modes Available (275): 1, 0
libinput Send Events Mode Enabled (276):    0, 0
libinput Send Events Mode Enabled Default (277):    0, 0
libinput Left Handed Enabled (297): 0
libinput Left Handed Enabled Default (298): 0
libinput Scroll Methods Available (299):    0, 0, 1
libinput Scroll Method Enabled (300):   0, 0, 0
libinput Scroll Method Enabled Default (301):   0, 0, 0
libinput Button Scrolling Button (302): 2
libinput Button Scrolling Button Default (303): 2
libinput Middle Emulation Enabled (304):    0
libinput Middle Emulation Enabled Default (305):    0
Device Node (278):  "/dev/input/event2"
Device Product ID (279):    1133, 49277
libinput Drag Lock Buttons (306):   <no items>
libinput Horizontal Scroll Enabled (307):   1

I tried messing with the Coordinate Transformation Matrix, but as far as I can tell, it doesn't do a thing.

None of the other properties seem like they could help me - is there some other way I can solve this problem?

Edit: Output of xinput list:

⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Logitech Gaming Mouse G502                id=11   [slave  pointer  (2)]
⎜   ↳ Logitech Gaming Mouse G502                id=10   [slave  pointer  (2)]
⎣ Virtual core keyboard                     id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Power Button                              id=7    [slave  keyboard (3)]
    ↳ Logitech G510 Gaming Keyboard             id=8    [slave  keyboard (3)]
    ↳ Logitech G510 Gaming Keyboard             id=9    [slave  keyboard (3)]
    ↳ Eee PC WMI hotkeys                        id=12   [slave  keyboard (3)]
    ↳ Logitech Gaming Mouse G502                id=13   [slave  keyboard (3)]

Using xinput test <ID> I noticed only the device with the ID 10 responded with any events.

Improve this question
4
  • If you have one of those Logitech Unifying Receivers, please edit question with complete output of xinput list, because this receiver seems to do funny things. In particular, it doesn't always route events to where one would think it does. Also have a look at evtest.
    – dirkt
    Commented Jul 4, 2017 at 14:08
  • I only use wired devices, so no receiver whatsoever,
    – Xandaros
    Commented Jul 4, 2017 at 14:45
  • 1
    Then that's even weirder, because a single mouse should not show up three times. So add output of xinput list, test all three devices with xinput --test <ID> to find out which device(s) react to movement/button events, and also run evtest as root to do the same for (all) underlying input descriptors (and edit question with findings). If you change properties on the wrong device, you can change them until you are blue in the face, and nothing will happen. So first step is to find out what's what. And if it's a misconfiguration, that should be fixed first.
    – dirkt
    Commented Jul 4, 2017 at 15:13
  • Amended and I also solved the problem. If you can provide a better answer, I will, of course, accept yours over mine.
    – Xandaros
    Commented Jul 4, 2017 at 15:29

1 Answer 1

Reset to default
3

Apparently, changing the coordinate transformation matrix does work, I just did it the wrong way around.

Setting it to an all-0 matrix does not do anything at all. Changing random values may or may not have an effect.

In the end, I noticed that making the bottom-right entry of the matrix larger, slowed down my mouse. So, changing this value to something large has the desired effect.

For example: xinput set-prop 10 154 1 0 0 0 1 0 0 0 1000000

This only worked with the mouse device with the ID 10.

Edit: Setting the other 1-values to something small - say, 0 - also makes it slower. So this works, too: xinput set-prop 10 154 0 0 0 0 0 0 0 0 1

Even better, xinput test 10 does not output anything with this.

However, when used together with xdotool, I notice my cursor jumping to the top-left corner of the screen. I'm not sure if this is still in scope of this question, but it is still an issue.

Edit2: It appears the jumping to the top-left screen corner is caused by xdotool mousemove. If you move the mouse after issuing such a command with the matrix settings as above, the mouse pointer jumps to the top-left.

To prevent this from happening, you can simply follow it up by a relative movement. For example like this: xdotool mousemove X Y mousemove_relative 1 1 mousemove_relative -- -1 -1. This will move the pointer to the supplied X and Y coordinates and be unaffected by further mouse movements.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .