Moving objects (G key) has broken behavior on linux/wayland #53004

New Issue

Carlos Garnacho · 2017-10-05T17:09:09+02:00

Carlos Garnacho commented

2017-10-05 17:09:09 +02:00

System Information
Fedora 27, GNOME wayland

Blender Version
Any

Description of error (can't be short, sorry)
Blender relies on pointer warping to implement infinite motion on certain features (eg. Moving an object, keyboard shorcut: G). This shows broken behavior on Linux systems running Wayland sessions (with Blender running through Xwayland). The pointer warp request won't be honored under the circumstances Blender does them, as a result the pointer moves outside the viewport and every motion event is interpreted as a full turn around, making the moved object go away really really fast.

Xwayland is meant to make X11 clients work seamlessly, this is however a 1% case that may require some compromise.

Due to stricter security principles in Wayland, Xwayland can only "honor" X(I)WarpPointer requests whenever the pointer cursor is hidden (like it seems blender already does in other modes like shift-F, which work with Xserver >= 1.19.4), hiding the cursor would likewise make these cases work. Another plausible option is confining the cursor (confineTo argument to XGrabPointer) and obtaining relative pointer motion.

Background:
https://bugs.freedesktop.org/show_bug.cgi?id=100740

Exact steps for others to reproduce the error
On a wayland session, move an object past the viewport edge.

**System Information** Fedora 27, GNOME wayland **Blender Version** Any **Description of error (can't be short, sorry)** Blender relies on pointer warping to implement infinite motion on certain features (eg. Moving an object, keyboard shorcut: G). This shows broken behavior on Linux systems running Wayland sessions (with Blender running through Xwayland). The pointer warp request won't be honored under the circumstances Blender does them, as a result the pointer moves outside the viewport and every motion event is interpreted as a full turn around, making the moved object go away really really fast. Xwayland is meant to make X11 clients work seamlessly, this is however a 1% case that may require some compromise. Due to stricter security principles in Wayland, Xwayland can only "honor" X(I)WarpPointer requests whenever the pointer cursor is hidden (like it seems blender already does in other modes like shift-F, which work with Xserver >= 1.19.4), hiding the cursor would likewise make these cases work. Another plausible option is confining the cursor (confineTo argument to XGrabPointer) and obtaining relative pointer motion. Background: https://bugs.freedesktop.org/show_bug.cgi?id=100740 **Exact steps for others to reproduce the error** On a wayland session, move an object past the viewport edge.

Carlos Garnacho commented

2017-10-05 17:09:09 +02:00

Changed status to: 'Open'

Carlos Garnacho commented

2017-10-05 17:09:09 +02:00

Added subscriber: @garnacho

blender-admin commented

2017-10-05 17:09:09 +02:00

#52556 was marked as duplicate of this issue

Carlos Garnacho commented

2017-10-05 17:10:25 +02:00

Added subscribers: @JakubSteiner, @jadahl

Sergey Sharybin commented

2017-10-06 10:18:57 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2017-10-06 10:18:57 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2017-10-06 10:18:57 +02:00

Sergey Sharybin self-assigned this 2017-10-06 10:18:57 +02:00

Sergey Sharybin commented

2017-10-06 10:18:57 +02:00

Thanks for the report, but this isn't a Blender bug, all the X11 servers are working fine. The issue is in Waylan'd emulation of X11 protocol, which we can not fix from our side.

Carlos Garnacho commented

2017-10-06 11:37:15 +02:00

Very sad to see this resolution without any further consideration. FWIW, Xwayland is an X11 server on its own, so clearly not all X11 servers work fine. Furthermore, it's becoming the de-facto X11 server as many distros are switching to Wayland sessions by default. Blender will look broken on all of them.

Wayland developers will state not leaving apps in control of the pointer position "is not a bug, but a feature", and you may keep saying "it is an emulation problem", as long as nobody takes action on the problem, it will stay there forever.

There is something you can do, the patterns I suggested (using relative pointer motion, hiding the pointer crusor and/or confining it with a grab) can be made to work with Xwayland and every other X11 server.

Very sad to see this resolution without any further consideration. FWIW, Xwayland is an X11 server on its own, so clearly not all X11 servers work fine. Furthermore, it's becoming the de-facto X11 server as many distros are switching to Wayland sessions by default. Blender will look broken on all of them. Wayland developers will state not leaving apps in control of the pointer position "is not a bug, but a feature", and you may keep saying "it is an emulation problem", as long as nobody takes action on the problem, it will stay there forever. There is something you can do, the patterns I suggested (using relative pointer motion, hiding the pointer crusor and/or confining it with a grab) can be made to work with Xwayland and every other X11 server.

Sergey Sharybin commented

2017-10-06 11:53:29 +02:00

I do not see any issues in the continuous grab implementation in Blender, and fact that none of X11 servers showed the issue in the past decades backs up theory that we don't abuse anything.

If Wayland implements part of X11 protocol differently, it is it a problem on Wayland side. Sure, it is possible to add some work around, but why Wayland expects developers of ALL software to hack their code just to support buggy behavior of Wayland? Just fix Wayland in one place and all the software will be running just fine!

I do not see any issues in the continuous grab implementation in Blender, and fact that none of X11 servers showed the issue in the past decades backs up theory that we don't abuse anything. If Wayland implements part of X11 protocol differently, it is it a problem on Wayland side. Sure, it is possible to add some work around, but why Wayland expects developers of ALL software to hack their code just to support buggy behavior of Wayland? Just fix Wayland in one place and all the software will be running just fine!

Jonas Ådahl commented

2017-10-06 15:43:11 +02:00

I agree that this is not really a Blender bug. This is rather a limitation of how much of X11's behavior we can emulate without turning X11 into too much of a a backdoor into a Wayland based desktop environment. For example, we can of course not make it possible to allow X11 clients to became global key loggers, and in the same way, we cannot just make it possible to allow X11 clients to completely take over your mouse cursor.

I think the most reasonable thing here, until Blender has a fully featured Wayland backend, is to change the behavior of Blender, as it seems to be the only way to provide users with a workable experience in the mean time. While at it, it will make the user experience of Blender using X11 the same as a future Blender using Wayland, which I believe is a good thing.

I agree that this is not really a Blender bug. This is rather a limitation of how much of X11's behavior we can emulate without turning X11 into too much of a a backdoor into a Wayland based desktop environment. For example, we can of course not make it possible to allow X11 clients to became global key loggers, and in the same way, we cannot just make it possible to allow X11 clients to completely take over your mouse cursor. I think the most reasonable thing here, until Blender has a fully featured Wayland backend, is to change the behavior of Blender, as it seems to be the only way to provide users with a workable experience in the mean time. While at it, it will make the user experience of Blender using X11 the same as a future Blender using Wayland, which I believe is a good thing.

Sergey Sharybin commented

2017-10-06 16:59:33 +02:00

For workable experience you can simply disable "Continuous Grab" in User Preferences -> Input on a systems which are running Wayland.

Jakub Steiner commented

2017-10-06 17:30:27 +02:00

Long time blender cloud subscriber is quite disappointed by this resolution. ;)

TravLR commented

2017-10-16 06:54:49 +02:00

Added subscriber: @TravLR

TravLR commented

2017-10-16 06:54:49 +02:00

Back in April 20th, I reported a bug to the Wayland team regarding this issue (as instructed by the Ubuntu Google+ community -- long-time Ubuntu user). After the news of the switch to GNOME & Wayland session by default in their newest upcoming release and beyond, I immediately began testing Blender in the Ubuntu 17.10 default session. There were three major issues which made Blender rather unusable in many circumstances (See the bug I posted in Wayland bugtracker: https:*bugs.freedesktop.org/show_bug.cgi?id=100740 ). The three issues are:

(1) Using fly-mode in viewport (Shift+f) causes the camera to move drastically and sporadically when the mouse reaches the edge of the Viewport and wraps around it.
(2) Moving an object (g) and pushing the mouse past the edge of the viewport window causes the object to move sporadically and wildly.
(3) Screen flickers pretty bad during both instances (1) and (2).

As of yesterday, issue #1 seems to have been resolved in Ubuntu 17.10 (beta 2 iso release) on an intel-graphics laptop running Wayland. Issues 2 and 3 still remain.

Users of Nvidia proprietary graphics (at this moment) are bumped to a Xorg/X11 session by default, with no possibility of a Wayland session... but who knows what will happen in 18.04.

I would definitely encourage that this issue be pursued and not closed, as there will literally be thousands of users on Ubuntu-based PC's running Wayland, and will run into these three issues. To have to tweak a user preference setting just for basic behavior to work out of the box (no guarantee if that fixes the frequent and annoying screen flickering) seems pretty disappointing.

No criticism intended at all by this comment; I have the utmost respect for Blender, Wayland and Ubuntu developers for their respective products. Just hoping a resolve can be found that's more seamless than the current proposal for the sake of myself and the large number of user who do (and possibly will) use this combination of Blender, Ubuntu (& other distros using Wayland by default), and Wayland. Appreciate everybody reading.

Back in April 20th, I reported a bug to the Wayland team regarding this issue (as instructed by the Ubuntu Google+ community -- long-time Ubuntu user). After the news of the switch to GNOME & Wayland session by default in their newest upcoming release and beyond, I immediately began testing Blender in the Ubuntu 17.10 default session. There were three **major** issues which made Blender rather unusable in many circumstances (See the bug I posted in Wayland bugtracker: [https:*bugs.freedesktop.org/show_bug.cgi?id=100740 ](https:*bugs.freedesktop.org/show_bug.cgi?id=100740)). The three issues are: (1) Using fly-mode in viewport (Shift+f) causes the camera to move drastically and sporadically when the mouse reaches the edge of the Viewport and wraps around it. (2) Moving an object (g) and pushing the mouse past the edge of the viewport window causes the object to move sporadically and wildly. (3) Screen flickers pretty bad during both instances (1) and (2). As of yesterday, issue #1 seems to have been resolved in Ubuntu 17.10 (beta 2 iso release) on an intel-graphics laptop running Wayland. Issues 2 and 3 still remain. Users of Nvidia proprietary graphics (at this moment) are bumped to a Xorg/X11 session by default, with no possibility of a Wayland session... but who knows what will happen in 18.04. I would definitely encourage that this issue be pursued and not closed, as there will literally be thousands of users on Ubuntu-based PC's running Wayland, and will run into these three issues. To have to tweak a user preference setting just for basic behavior to work out of the box (no guarantee if that fixes the frequent and annoying screen flickering) seems pretty disappointing. No criticism intended at all by this comment; I have the utmost respect for Blender, Wayland and Ubuntu developers for their respective products. Just hoping a resolve can be found that's more seamless than the current proposal for the sake of myself and the large number of user who do (and possibly will) use this combination of Blender, Ubuntu (& other distros using Wayland by default), and Wayland. Appreciate everybody reading.

Carlos Garnacho commented

2017-10-16 11:25:18 +02:00

In #53004#465803, @TravLR wrote:
(1) Using fly-mode in viewport (Shift+f) causes the camera to move drastically and sporadically when the mouse reaches the edge of the Viewport and wraps around it.

Yes, this is not too dissimilar from what games and other locked 3D views do so Xwayland could be fixed to work for this case too.

(2) Moving an object (g) and pushing the mouse past the edge of the viewport window causes the object to move sporadically and wildly.

This is the bug being "debated" here. Because Wayland shall only allow confining/locking the pointer, Xwayland can't emulate pointer warps while the cursor is visible.

(3) Screen flickers pretty bad during both instances (1) and (2).

This is most likely a Xwayland or compositor issue.

I appreciate you being vocal, I too am concerned about wide user bases and frequently used features being broken on Wayland. But please let's stay on topic, that will increase our (rather slim AFAICS...) chances to reach to an agreement.

> In #53004#465803, @TravLR wrote: > (1) Using fly-mode in viewport (Shift+f) causes the camera to move drastically and sporadically when the mouse reaches the edge of the Viewport and wraps around it. Yes, this is not too dissimilar from what games and other locked 3D views do so Xwayland could be fixed to work for this case too. > (2) Moving an object (g) and pushing the mouse past the edge of the viewport window causes the object to move sporadically and wildly. This is the bug being "debated" here. Because Wayland shall only allow confining/locking the pointer, Xwayland can't emulate pointer warps while the cursor is visible. > (3) Screen flickers pretty bad during both instances (1) and (2). This is most likely a Xwayland or compositor issue. I appreciate you being vocal, I too am concerned about wide user bases and frequently used features being broken on Wayland. But please let's stay on topic, that will increase our (rather slim AFAICS...) chances to reach to an agreement.

Campbell Barton commented

2017-10-24 14:45:08 +02:00

Added subscribers: @Tooniis, @ideasman42, @jubjub, @mont29

Campbell Barton commented

2017-10-24 14:52:38 +02:00

While this isn't technically a bug, re-opening since I think it's working getting a fix.
Especially since the latest stable Ubuntu defaults to wayland.

I looked into locking the cursor so it could be warped, it's not working in the latest weston (3.0.0)
both gnome-shell and weston.

Attached a diff on master that should fix the issue based on the information from https://bugs.freedesktop.org/show_bug.cgi?id=100740 but this still fails.

wayland.diff

Uses grab and constrains the cursor to a window.

Will post on the freedesktops tracker and check if there is any info on how this could be made to work.

While this isn't technically a bug, re-opening since I think it's working getting a fix. Especially since the latest stable Ubuntu defaults to wayland. I looked into locking the cursor so it could be warped, it's not working in the latest weston (3.0.0) both gnome-shell and weston. Attached a diff on master that should fix the issue based on the information from https://bugs.freedesktop.org/show_bug.cgi?id=100740 but this still fails. [wayland.diff](https://archive.blender.org/developer/F1062827/wayland.diff) Uses grab and constrains the cursor to a window. Will post on the freedesktops tracker and check if there is any info on how this could be made to work.

Campbell Barton commented

2017-10-24 14:59:44 +02:00

Changed status from 'Archived' to: 'Open'

Campbell Barton reopened this issue

2017-10-24 14:59:44 +02:00

Sergey Sharybin was unassigned by Campbell Barton

2017-10-24 14:59:44 +02:00

Campbell Barton self-assigned this 2017-10-24 14:59:44 +02:00

Jonas Ådahl commented

2017-10-24 15:04:50 +02:00

Note that the pointer warping emulation inside Xwayland needs special Xwayland specific hand holding in the compositor. I think weston only has support for the plain Wayland client part of pointer locking, meaning that it wont work. I only know about gnome-shell (or rather mutter) that does the extra Xwayland hand holding.

I briefly looked at the wayland.diff. Checking whether there is a WAYLAND_DISPLAY is unreliable, since that variable is optional. Sadly I don't know of any reliable way for a X11 client to detect what type of X server it is connected to, so I don't have a better alternative at hand.

Note that the pointer warping emulation inside Xwayland needs special Xwayland specific hand holding in the compositor. I think weston only has support for the plain Wayland client part of pointer locking, meaning that it wont work. I only know about gnome-shell (or rather mutter) that does the extra Xwayland hand holding. I briefly looked at the wayland.diff. Checking whether there is a WAYLAND_DISPLAY is unreliable, since that variable is optional. Sadly I don't know of any reliable way for a X11 client to detect what type of X server it is connected to, so I don't have a better alternative at hand.

Jonas Ådahl commented

2017-10-24 15:19:29 +02:00

In #53004#467156, @ideasman42 wrote:
I looked into locking the cursor so it could be warped, it's not working in the latest weston (3.0.0)
both gnome-shell and weston.

The issue is that the cursor cannot be warped as long as it is visible. The way things work currently is, if a cursor is hidden and it is warped, we lie to X11 clients and say it is actually warped. While doing so, we lock the pointer via the available Wayland protocols. When the cursor is made visible or that for some other reason the lock is broken (for example the user Alt-tab:ed away), we stop lying and where the visible cursor is displayed is the position we tell the clients about. This works for the majority of use cases we have run into (including Blender uses, excluding the one discussed in this report).

We handle confinement in a more direct way.

In other words, if the patch implements a behavior where the pointer cursor is warped while visible, it wont work. If the pointer cursor is confined using X11 protocol, or hidden then warped, and it doesn't work, it could very much be an Xwayland issue.

> In #53004#467156, @ideasman42 wrote: > I looked into locking the cursor so it could be warped, it's not working in the latest weston (3.0.0) > both gnome-shell and weston. The issue is that the cursor cannot be warped as long as it is visible. The way things work currently is, if a cursor is hidden and it is warped, we lie to X11 clients and say it is actually warped. While doing so, we lock the pointer via the available Wayland protocols. When the cursor is made visible or that for some other reason the lock is broken (for example the user Alt-tab:ed away), we stop lying and where the visible cursor is displayed is the position we tell the clients about. This works for the majority of use cases we have run into (including Blender uses, excluding the one discussed in this report). We handle confinement in a more direct way. In other words, if the patch implements a behavior where the pointer cursor is warped while visible, it wont work. If the pointer cursor is confined using X11 protocol, or hidden then warped, and it doesn't work, it could very much be an Xwayland issue.

Campbell Barton commented

2017-10-24 15:52:52 +02:00

@jadahl, AFAICS X11 doesn't have the concept of a hidden cursor, so not sure this is possible?

See: https://stackoverflow.com/a/660705/432509

@jadahl, AFAICS X11 doesn't have the concept of a hidden cursor, so not sure this is possible? See: https://stackoverflow.com/a/660705/432509

Jonas Ådahl commented

2017-10-24 16:01:57 +02:00

In #53004#467186, @ideasman42 wrote:
@jadahl, AFAICS X11 doesn't have the concept of a hidden cursor, so not sure this is possible?

See: https://stackoverflow.com/a/660705/432509

There are various tricks. I'd check SDL and GLFW since they can hide the cursor, and so far games that uses SDL or GLFW via X11 and the use warp-hidden-cursor technique should be handled properly (was at least last time I checked).

> In #53004#467186, @ideasman42 wrote: > @jadahl, AFAICS X11 doesn't have the concept of a hidden cursor, so not sure this is possible? > > See: https://stackoverflow.com/a/660705/432509 There are various tricks. I'd check SDL and GLFW since they can hide the cursor, and so far games that uses SDL or GLFW via X11 and the use warp-hidden-cursor technique should be handled properly (was at least last time I checked).

Carlos Garnacho commented

2017-10-24 16:31:46 +02:00

FWIW cursor hiding is a feature of Xfixes, see XFixesHideCursor/XFixesShowCursor, although AFAICT the setWindowCursorVisibility/getEmptyCursor trick in GHOST_WindowX11.cpp should work? at least other features like shift-F seem to get away with it.

Campbell Barton commented

2017-10-25 10:48:11 +02:00

Looked into this furher:

Hiding the cursor while grabbing allows it to warp.

While this works. I don't think this is reasonable since users need to see the cursor in these cases. (while grabbing for example). We could draw a cursor in software but this seems like too much overhead for for what _should_ be able to be handled with some small workaround.

Hiding the cursor only for the moment it's warped.

Also a hack, but at least gives more usable results. Problem is - hiding the cursor requires the window, which we don't have in `SystemX11::setCursorPosition`. I checked on accessing it from `XQueryPointer` return windows but the windows given didn't match up to ghost windows.

Using XFixes seems like it can be made to work, see: D2898
Another option is to disable grabbing when XWayland is detected.

Looked into this furher: - Hiding the cursor while grabbing allows it to warp. ``` While this works. I don't think this is reasonable since users need to see the cursor in these cases. (while grabbing for example). We could draw a cursor in software but this seems like too much overhead for for what _should_ be able to be handled with some small workaround. ``` - Hiding the cursor only for the moment it's warped. ``` Also a hack, but at least gives more usable results. Problem is - hiding the cursor requires the window, which we don't have in `SystemX11::setCursorPosition`. I checked on accessing it from `XQueryPointer` return windows but the windows given didn't match up to ghost windows. ``` - Using XFixes seems like it can be made to work, see: [D2898](https://archive.blender.org/developer/D2898) - Another option is to disable grabbing when XWayland is detected.

Campbell Barton commented

2017-10-25 11:11:02 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2017-10-25 11:11:02 +02:00

blender-admin commented

2017-10-25 11:12:12 +02:00

This issue was referenced by 2103194f79

This issue was referenced by 2103194f794c9c5260583ceb7d7bbaf73f783f48

TravLR commented

2017-10-29 19:46:49 +01:00

Will these commits hit the 2.8 builds of Blender when it gets released, or will it be available in sooner builds for testing?