Mouse cursor moves after mouse middle button up if xinput coordinate transformation matrix is used #85014

New Issue

Nikita Lisitsa · 2021-01-24T11:04:23+01:00

Nikita Lisitsa commented

2021-01-24 11:04:23 +01:00

System Information
Operating system: Gentoo Linux, kernel version 5.4.72
Graphics card: GeForce GFX 1060 6GB

Blender Version
Broken: 2.90.1, 2.91.0, 2.92.0-alpha
I'm normally using a blender version from the cg overlay to have newer versions & richer feature support, but the problem reproduces exactly with blender version from the official portage repositories.

Short description of error
I'm using xinput coordinate transformation matrix to make the mouse cursor move faster (my mouse seems to be slower on Y that on X, so I used it to fix that). While using this, I noticed that blender erroneously moves the mouse cursor: after the mouse wheel (middle button) is clicked and the cursor is moved just a bit (i.e. one pixel), the cursor gets teleported to a different location, usually about a few hundered pixels to the right and down.

If e.g. only the Y-axis diagonal value of the transformation matrix differs from the default of 1.0 (as in the identity matrix), the cursor gets moved exactly down. After experimenting with different values I noticed that if the Y-axis diagonal value of the matrix is set to 2.0, the Y mouse position (in screen pixels) after click is about 2 times the previous position; if set to 3.0, the Y mouse position after click is about 3 times the previous position, etc. So, it appears as if the transformation matrix was applied once to the mouse cursor after the mouse middle button is pressed, which to my understanding shouldn't be happening.

The effect reproduces even is xinput transformation matrix is applied while blender is already running.

Exact steps for others to reproduce the error
On a system that uses X window system,

Run xinput to find out the exact relevant device id (mine is Logitech USB Receiver Mouse id=10)
Run xinput --list-props <device-id> to find the property id of the matrix (mine is Coordinate Transformation Matrix (157))
Run xinput --set-prop <device-id> <propery-id> 1.0 0.0 0.0 0.0 2.0 0.0 0.0 0.0 1.0
Open blender and try rotating the camera with the middle mouse button, or simply click the middle mouse button and move the cursor a little

**System Information** Operating system: Gentoo Linux, kernel version 5.4.72 Graphics card: GeForce GFX 1060 6GB **Blender Version** Broken: 2.90.1, 2.91.0, 2.92.0-alpha I'm normally using a blender version from the [cg ](https://github.com/brothermechanic/cg) overlay to have newer versions & richer feature support, but the problem reproduces exactly with blender version from the official portage repositories. **Short description of error** I'm using xinput coordinate transformation matrix to make the mouse cursor move faster (my mouse seems to be slower on Y that on X, so I used it to fix that). While using this, I noticed that blender erroneously moves the mouse cursor: after the mouse wheel (middle button) is clicked and the cursor is moved just a bit (i.e. one pixel), the cursor gets teleported to a different location, usually about a few hundered pixels to the right and down. If e.g. only the Y-axis diagonal value of the transformation matrix differs from the default of 1.0 (as in the identity matrix), the cursor gets moved exactly down. After experimenting with different values I noticed that if the Y-axis diagonal value of the matrix is set to 2.0, the Y mouse position (in screen pixels) after click is about 2 times the previous position; if set to 3.0, the Y mouse position after click is about 3 times the previous position, etc. So, it appears as if the transformation matrix was applied once to the mouse cursor after the mouse middle button is pressed, which to my understanding shouldn't be happening. The effect reproduces even is xinput transformation matrix is applied while blender is already running. **Exact steps for others to reproduce the error** On a system that uses X window system, - Run `xinput` to find out the exact relevant device id (mine is `Logitech USB Receiver Mouse id=10`) - Run `xinput --list-props <device-id>` to find the property id of the matrix (mine is `Coordinate Transformation Matrix (157)`) - Run `xinput --set-prop <device-id> <propery-id> 1.0 0.0 0.0 0.0 2.0 0.0 0.0 0.0 1.0` - Open blender and try rotating the camera with the middle mouse button, or simply click the middle mouse button and move the cursor a little

Nikita Lisitsa commented

2021-01-24 11:04:23 +01:00

Added subscriber: @lisyarus

Falk David commented

2021-01-25 16:37:50 +01:00

Added subscriber: @filedescriptor

Falk David commented

2021-01-25 16:37:50 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Falk David commented

2021-01-25 16:37:50 +01:00

I can reproduce this on 2.92.0 Beta, branch: master, commit date: 2021-01-25 06:40, hash: 7f9ed0178a. The jump happens after the middle mouse button is released.

I can reproduce this on 2.92.0 Beta, branch: master, commit date: 2021-01-25 06:40, hash: `7f9ed0178a`. The jump happens after the middle mouse button is released.

Julian Eisel commented

2021-01-27 20:32:57 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2021-01-27 20:32:57 +01:00

This would probably be an issue in X specific event handling then. It is a rather obscure issue and I'd guess it's there for a long time.

I can't check this currently but personally also wouldn't prioritize this. Marking as known issue.

This would probably be an issue in X specific event handling then. It is a rather obscure issue and I'd guess it's there for a long time. I can't check this currently but personally also wouldn't prioritize this. Marking as known issue.

Bastien commented

2021-03-07 10:56:15 +01:00

Added subscriber: @Pik-1

Bastien commented

2021-03-07 10:56:15 +01:00

I'm also affected, commit 8618c4159c.

It seems to happen whenever the mouse is grabbed (the --debug option disables that and "fixes" the issue). So the mouse jumps when performing pretty much any action, making the software unusable. Of course the low priority is justified (we can just revert to the identity matrix in xinput when using Blender), but it took me a while to figure it out. If it's not too much of a hack maybe there could be a warning in the meantime?

If I can find the time I'll investigate it further.

I'm also affected, commit 8618c4159c7b0c9bddf6b86522dee383de7207cf. It seems to happen whenever the mouse is grabbed (the --debug option disables that and "fixes" the issue). So the mouse jumps when performing pretty much any action, making the software unusable. Of course the low priority is justified (we can just revert to the identity matrix in xinput when using Blender), but it took me a while to figure it out. If it's not too much of a hack maybe there could be a warning in the meantime? If I can find the time I'll investigate it further.

Bastien commented

2021-03-07 21:30:37 +01:00

Alright so after a bit of debugging and git-blaming, I realized I'm bad at looking for existing bug reports.

The issue was already raised and fixed in #48901, then the fix was reverted in #50383 because it messed with Xinerama, due to this 6-year-old bug in libX (which may be NVidia's fault according to a comment). I thought Xinerama was obsolete but apparently RandR doesn't perfectly handle multiple graphics cards(?).

So until Wayland takes over the (Linux desktop) world, I guess we have to choose between xinput transformation matrix and proper multi-GPU.

Could the macro used in Ghost to control this (USE_X11_XINPUT_WARP) be exposed in the CMake config? This way we can easily choose at compile-time.

Alright so after a bit of debugging and git-blaming, I realized I'm bad at looking for existing bug reports. The issue was already raised and fixed in #48901, then the fix was reverted in #50383 because it messed with Xinerama, due to [this 6-year-old bug in libX ](https://gitlab.freedesktop.org/xorg/lib/libxi/-/issues/5) (which may be NVidia's fault according to a comment). I thought Xinerama was obsolete but apparently RandR doesn't perfectly handle multiple graphics cards(?). So until Wayland takes over the (Linux desktop) world, I guess we have to choose between xinput transformation matrix and proper multi-GPU. Could the macro used in Ghost to control this (`USE_X11_XINPUT_WARP`) be exposed in the CMake config? This way we can easily choose at compile-time.

Nikita Lisitsa commented

2021-03-10 07:42:38 +01:00

Bastien, thank you a lot for investigation! I agree that it is an obscure and minor issue. I'd personally be fine if it was closed as a duplicate, but as a Gentoo user I would highly appreciate a compile-time flag as well :)

shaheer commented

2022-04-17 05:53:55 +02:00

Added subscriber: @sh6heer

Campbell Barton commented

2022-06-27 08:53:50 +02:00

Closed as duplicate of #48901

Campbell Barton closed this issue

2022-06-27 08:53:50 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Mouse cursor moves after mouse middle button up if xinput coordinate transformation matrix is used #85014