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

Closed
opened 2017-10-05 17:09:09 +02:00 by Carlos Garnacho · 28 comments

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.

Changed status to: 'Open'

Changed status to: 'Open'

Added subscriber: @garnacho

Added subscriber: @garnacho

#52556 was marked as duplicate of this issue

#52556 was marked as duplicate of this issue

Added subscribers: @JakubSteiner, @jadahl

Added subscribers: @JakubSteiner, @jadahl

Added subscriber: @Sergey

Added subscriber: @Sergey

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Sergey Sharybin self-assigned this 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.

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.

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.

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!

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.

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

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

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

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

Added subscriber: @TravLR

Added subscriber: @TravLR

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.

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.

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

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

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.

Changed status from 'Archived' to: 'Open'

Changed status from 'Archived' to: 'Open'
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

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.

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.

@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

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).

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.

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.

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.

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

This issue was referenced by 2103194f79

This issue was referenced by 2103194f794c9c5260583ceb7d7bbaf73f783f48

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

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

Fixes apply to master and 2.8.

Fixes apply to master and 2.8.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#53004
No description provided.