Mouse jumps monitors on middle button release #50383

New Issue

Matt Jenkins · 2017-01-06T22:02:51+01:00

Matt Jenkins commented

2017-01-06 22:02:51 +01:00

System Information
Ubuntu 16.10 amd64
2x GT-610 with CUDA (4 monitors)

Blender Version
Broken: 2.78a
Worked: 2.77

When manipulating the 3D view with the middle mouse button, upon releasing the middle button the mouse jumps to a different screen than where I was working. Which screen the mouse jumps to is dependant on which screen Blender is running in. It only seems to happen on monitors connected to GPU-0 - if I run Blender on the other monitors on GPU-1 it is fine.

Exact steps for others to reproduce the error
I guess to replicate it you will need a dual-card quad display NVidia system. No special .blend file is needed - the default startup file is enough.

**System Information** Ubuntu 16.10 amd64 2x GT-610 with CUDA (4 monitors) **Blender Version** Broken: 2.78a Worked: 2.77 When manipulating the 3D view with the middle mouse button, upon releasing the middle button the mouse jumps to a different screen than where I was working. Which screen the mouse jumps to is dependant on which screen Blender is running in. It only seems to happen on monitors connected to GPU-0 - if I run Blender on the other monitors on GPU-1 it is fine. **Exact steps for others to reproduce the error** I guess to replicate it you will need a dual-card quad display NVidia system. No special .blend file is needed - the default startup file is enough.

Matt Jenkins commented

2017-01-06 22:02:51 +01:00

Changed status to: 'Open'

Matt Jenkins commented

2017-01-06 22:02:51 +01:00

Added subscriber: @majenko

blender-admin commented

2017-01-06 22:02:51 +01:00

#61507 was marked as duplicate of this issue

blender-admin commented

2017-01-06 22:02:51 +01:00

#50870 was marked as duplicate of this issue

chris commented

2017-01-09 22:03:56 +01:00

Added subscriber: @ch2155

chris commented

2017-01-09 22:03:56 +01:00

Just signed up to confirm this bug.

Also happens while grab/release objects with right-click

System: Debian Stretch amd64
1x GeForce GTX 770 (3-monitor setup)

tested on LXDE and XFCE

Just signed up to confirm this bug. Also happens while grab/release objects with right-click System: Debian Stretch amd64 1x GeForce GTX 770 (3-monitor setup) tested on LXDE and XFCE

Julian Eisel was assigned by Aaron Carlisle

2017-02-02 07:18:23 +01:00

Aaron Carlisle commented

2017-02-02 07:18:23 +01:00

Added subscriber: @mont29

CoryG commented

2017-04-16 21:33:11 +02:00

Added subscriber: @CoryG

CoryG commented

2017-04-16 21:33:11 +02:00

This also occurs on FreeBSD running KDE.

Julian Eisel removed their assignment 2017-04-21 00:56:44 +02:00

Julian Eisel commented

2017-04-21 00:56:44 +02:00

Added subscribers: @ideasman42, @brecht, @JulianEisel

Julian Eisel commented

2017-04-21 00:56:44 +02:00

I wasn't able to recreate this (tried with GNOME 3 and LXDE) but I also only got a single GPU system to test. @ideasman42 or @brecht would be other candidates for fixing this, maybe you can recreate it?

Just to be clear, this happens with factory settings too? And it's fine with 2.77 (report says so, but would be good to get it confirmed by others)?

Un-assigning myself as I'm not able to recreate the issue.

I wasn't able to recreate this (tried with GNOME 3 and LXDE) but I also only got a single GPU system to test. @ideasman42 or @brecht would be other candidates for fixing this, maybe you can recreate it? Just to be clear, this happens with factory settings too? And it's fine with 2.77 (report says so, but would be good to get it confirmed by others)? Un-assigning myself as I'm not able to recreate the issue.

Brecht Van Lommel commented

2017-04-21 23:46:16 +02:00

Added subscribers: @benny, @TheOnlyJoey

CoryG commented

2017-04-21 23:50:46 +02:00

@JulianEisel Yes, this worked on 2.77 and stopped working as of 2.78a (also fails in 2.78c.) My configuration if it matters for testing: 2 adapters, 3 monitors, first card drives center monitor and second card drives left+right monitors. All my tests used factory settings, it has to be something which changed for 2.78.

Brecht Van Lommel commented

2017-04-22 00:04:48 +02:00

I don't have multiple monitors to test this, but some notes.

If it broke between 2.77 and 2.78, then 7065022f7a might be the cause.

This libXi bug report may also be related. The man page say that "XIWarpPointer is identical to XWarpPointer but specifies the device explicitly", but perhaps there is a bug in the implementation?

I don't have multiple monitors to test this, but some notes. If it broke between 2.77 and 2.78, then 7065022f7a might be the cause. This [libXi bug report ](https://bugs.freedesktop.org/show_bug.cgi?id=91223) may also be related. The man page say that "XIWarpPointer is identical to XWarpPointer but specifies the device explicitly", but perhaps there is a bug in the implementation?

CoryG commented

2017-04-22 00:11:35 +02:00

@brecht I tend to suspect it couldn't be an implementation issue in the OS but within Blender (the first guy who reported it was using Ubuntu, another experienced it on Debian and I'm seeing it on FreeBSD.)

CoryG commented

2017-04-22 00:26:40 +02:00

Paging @ideasman42 - please fix.

Brecht Van Lommel commented

2017-04-22 02:22:03 +02:00

The libxi/xorg implementation is the same on all those operating systems. We'll have to see if there is actually a bug there, it's just something we have to consider given how simple change the from XWarpPointer to XIWarpPointer is and the fact that this is a rarely used function which will not have been tested much.

The libxi/xorg implementation is the same on all those operating systems. We'll have to see if there is actually a bug there, it's just something we have to consider given how simple change the from `XWarpPointer` to `XIWarpPointer` is and the fact that this is a rarely used function which will not have been tested much.

CoryG commented

2017-04-22 05:19:21 +02:00

@brecht What operating systems use the implementation it works on?

Brecht Van Lommel commented

2017-04-22 05:56:09 +02:00

I don't know if works anywhere, just that all the OSes tested use the same xorg-server code. In the implemention of XIWarpPointer we find this comment, indicating Xinerama (a.k.a. Panoramix) multi-monitor support is missing.

/* FIXME: panoramix stuff is missing, look at ProcWarpPointer */

Not sure what the right solution is on the Blender side, if there is another way to fix #48901 without using XIWarpPointer, perhaps by applying the transform manually. If we can't solve both then multi-monitor support seems more important to me.

I don't know if works anywhere, just that all the OSes tested use the same xorg-server code. In the [implemention ](https://cgit.freedesktop.org/xorg/xserver/tree/Xi/xiwarppointer.c#n89) of `XIWarpPointer` we find this comment, indicating Xinerama (a.k.a. Panoramix) multi-monitor support is missing. ``` /* FIXME: panoramix stuff is missing, look at ProcWarpPointer */ ``` Not sure what the right solution is on the Blender side, if there is another way to fix #48901 without using `XIWarpPointer`, perhaps by applying the transform manually. If we can't solve both then multi-monitor support seems more important to me.

Bernd Schmidt commented

2017-08-23 19:15:21 +02:00

Added subscriber: @bernds

Bernd Schmidt commented

2017-08-23 19:15:21 +02:00

In #50383#429876, @brecht wrote:
I don't have multiple monitors to test this, but some notes.

If it broke between 2.77 and 2.78, then 7065022f7a might be the cause.

Just in case there's still any doubt: I can confirm this. I had the same issue with the mouse pointer jumping out of the Blender window, and I commented out the new piece of code so that it just does XWarpPointer, and with that change it's working again.

> In #50383#429876, @brecht wrote: > I don't have multiple monitors to test this, but some notes. > > If it broke between 2.77 and 2.78, then 7065022f7a might be the cause. Just in case there's still any doubt: I can confirm this. I had the same issue with the mouse pointer jumping out of the Blender window, and I commented out the new piece of code so that it just does XWarpPointer, and with that change it's working again.

CoryG commented

2018-02-05 17:46:27 +01:00

Is the fix going to make it's way into the release version? It's up to 2.79 now and it still happens.

CoryG commented

2018-03-15 22:35:33 +01:00

Pinging again in the hope that this gets changed back so the default port on FreeBSD will work without destroying my computer by trying to build from the ports tree with modified source for Blender.

Benjamin J. commented

2018-06-08 06:08:06 +02:00

any ETA on a fix? This also affects latest 2.8 builds and makes using blender on setups with multiple screens almost impossible.

J. Alonzo commented

2019-01-15 03:59:34 +01:00

Added subscriber: @pix

J. Alonzo commented

2019-01-15 03:59:34 +01:00

I have the same problem. Middle mouse button stops working on random actions. For a reproduction, pressing Z to show the pie-menu and right after press Escape to cancel it, without moving the mouse. Right after that, the middle mouse button stops working. Scroll-function works well.

A quick workaround I found is by pressing the Shift-key on the keyboard several times. But also this workaround seems randomly, as it's not always working. Also going in and out of Edit-mode will fix it, but again not always.

To me, this looks like the button-action becomes blocked somehow and it needs some (usb)-input to unblock it. I noticed the middle-mouse click does actually pass to Blender, as the feedback at the lower screen changes. But somehow when it's blocked, the feedback shows the 3 mouse icons, but without hints behind it. When the middle-mouse button is working well, it shows a different feedback, namely the Axis Snap-icon (See attached pic)

Systemconfig:
MacBook Pro 15" Retina with OSX High Sierra 10.13.6
27" monitor attached w/ HMDI
Logitech Performance MX Mouse, Apple Pro Keyboard and a Wacom Draw Tablet which is currently disconnected

Edit: I just noticed the issue might be related to Walk/Fly navigation. When the MMB becomes blocked, pressing the Shift-key once while still holding the MMB, will take you into Walk/Fly-mode.

I have the same problem. Middle mouse button stops working on random actions. For a reproduction, pressing Z to show the pie-menu and right after press Escape to cancel it, without moving the mouse. Right after that, the middle mouse button stops working. Scroll-function works well. A quick workaround I found is by pressing the Shift-key on the keyboard several times. But also this workaround seems randomly, as it's not always working. Also going in and out of Edit-mode will fix it, but again not always. To me, this looks like the button-action becomes blocked somehow and it needs some (usb)-input to unblock it. I noticed the middle-mouse click does actually pass to Blender, as the feedback at the lower screen changes. But somehow when it's blocked, the feedback shows the 3 mouse icons, but without hints behind it. When the middle-mouse button is working well, it shows a different feedback, namely the Axis Snap-icon (See attached pic) Systemconfig: MacBook Pro 15" Retina with OSX High Sierra 10.13.6 27" monitor attached w/ HMDI Logitech Performance MX Mouse, Apple Pro Keyboard and a Wacom Draw Tablet which is currently disconnected ![MB-issue.png](https://archive.blender.org/developer/F6290842/MB-issue.png) Edit: I just noticed the issue might be related to Walk/Fly navigation. When the MMB becomes blocked, pressing the Shift-key once while still holding the MMB, will take you into Walk/Fly-mode.

blender-admin commented

2019-01-15 06:44:08 +01:00

This issue was referenced by 165caafb99

This issue was referenced by 165caafb99c6846e53d11c4e966990aaffc06cea

blender-admin commented

2019-01-15 06:44:08 +01:00

This issue was referenced by 9461af299c

This issue was referenced by 9461af299ca937ff36048f9198670eab6a6b233b

Campbell Barton commented

2019-01-15 06:49:15 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2019-01-15 06:49:15 +01:00

Campbell Barton commented

2019-01-15 06:59:57 +01:00

Initially I wasn't able to redo this bug because of nvidia has Xinerama disabled by default.

Once enabled the bug happens.

As Brecht notes, XIWarpPointer doesn't support multi-head.

Checked on workarounds (passing in root window for eg), but this always clamps to the screen bounds associated with the xinput device - and there doesn't look to be a way to change the screen via the xinput API.

Reverted use of XIWarpPointer, we can add it back if https://gitlab.freedesktop.org/xorg/lib/libxi/issues/5 is fixed.

Initially I wasn't able to redo this bug because of nvidia has Xinerama disabled by default. Once enabled the bug happens. As Brecht notes, `XIWarpPointer` doesn't support multi-head. Checked on workarounds (passing in root window for eg), but this always clamps to the screen bounds associated with the xinput device - and there doesn't look to be a way to change the screen via the xinput API. Reverted use of `XIWarpPointer`, we can add it back if https://gitlab.freedesktop.org/xorg/lib/libxi/issues/5 is fixed.

J. Alonzo commented

2019-01-15 09:49:40 +01:00

I've tried to work on something in Blender 2.8 but this bug happens multiple times in a minute and it's pretty hard to work with, so I jumped back to Blender 2.79. But guess what? 2.79 is acting the same way now. Constantly a block of this MMB. I've never had this problem before, but I noticed it's similar to when I for instance wanted to rotate view by MMB but the focus was on a non-Blender window. Normally with a left or right click, it would activate the window of the application you "touch", even when in another application. But the MMB typically does not activate it, while the scroll-wheel keeps working as long you hover over a Blender-window.

Because Blender 2.79 is affected too now (didn't reinstall it), could it be something more generic? Like a lib or extension both applications are using?

I've tried to work on something in Blender 2.8 but this bug happens multiple times in a minute and it's pretty hard to work with, so I jumped back to Blender 2.79. But guess what? 2.79 is acting the same way now. Constantly a block of this MMB. I've never had this problem before, but I noticed it's similar to when I for instance wanted to rotate view by MMB but the focus was on a non-Blender window. Normally with a left or right click, it would activate the window of the application you "touch", even when in another application. But the MMB typically does not activate it, while the scroll-wheel keeps working as long you hover over a Blender-window. Because Blender 2.79 is affected too now (didn't reinstall it), could it be something more generic? Like a lib or extension both applications are using?

Campbell Barton commented

2019-01-15 14:46:53 +01:00

@pix, the issue reported is for Linux/X11, not OSX, best open a new report if its not a duplicate of #47224

Brecht Van Lommel commented

2019-02-13 13:28:18 +01:00

Added subscriber: @ygs

Steven Laczko commented

2020-08-05 05:25:52 +02:00

Added subscriber: @Fate_Diddler

Steven Laczko commented

2020-08-05 05:25:52 +02:00

I can confirm that this is still happening on 2.83.3 on Ubuntu 20.04.1 LTS. Makes Blender pretty much unusable on this OS. I'm not sure why this is marked as resolved, it's not. I guess I should make a new post for this...

Gustav Andersson commented

2020-10-20 16:37:31 +02:00

Added subscriber: @Ridir

Gustav Andersson commented

2020-10-20 16:37:31 +02:00

I have the same issue on Arch with Blender 2.90.1-2. The issue seems to have to do with altering mouse sensitivity via the TransformationMatrix option in xinput. A temporary solution is simply not using the TransformationMatrix option to change mouse speed, and instead setting mouse speed some other way. I used gnome settings in budgie and it seems to be working fine.

Chris Bare commented

2020-12-25 21:00:43 +01:00

Added subscriber: @chrisbare

Chris Bare commented

2020-12-25 21:00:43 +01:00

I can confirm @Ridir's observation. I recently installed Ubuntu 20.10 and used the xinput Transformation Matrix to set my mouse speed:
xinput list-props $MOUSEID | grep -i matrix

      Coordinate Transformation Matrix (158): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000

xinput --set-prop $MOUSEID 158 1.9 0 0 0 1.9 0 0 0 1

With the matrix at 1 0 0 0 1 0 0 0 1, middle mouse works fine, but at other values, the mouse warps to the right when the middle button is released.
I used to use xinput --set-ptr-feedback, but that has no effect in Ubuntu 20.10

I see this issue with Blender 2.91.0 and 2.83.5.

I can confirm @Ridir's observation. I recently installed Ubuntu 20.10 and used the xinput Transformation Matrix to set my mouse speed: xinput list-props $MOUSEID | grep -i matrix ``` Coordinate Transformation Matrix (158): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 ``` xinput --set-prop $MOUSEID 158 1.9 0 0 0 1.9 0 0 0 1 With the matrix at 1 0 0 0 1 0 0 0 1, middle mouse works fine, but at other values, the mouse warps to the right when the middle button is released. I used to use xinput --set-ptr-feedback, but that has no effect in Ubuntu 20.10 I see this issue with Blender 2.91.0 and 2.83.5.

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 jumps monitors on middle button release #50383