Thanks for getting this done, everyone. FWIW, the <releases> section is needed in order for Flathub to display a version number. Without it, the version shows up as "Stable", which isn't very informative to users.

Committed rB611712fcc89100c4f0084d0d4c6b9392367c4c64

• Use new url for screenshots

In D3025#72176, @Brecht Van Lommel (brecht) wrote:

@Dan McGrath (dmcgrath), could you help us and upload these 4 screenshots somewhere they are not likely to get lost? I don't have access to the right servers.

Maybe something like blender_screenshot1/2/3/4.jpg, in download.blender.org/demo/screenshots/, with a README in the folder explaining that these are used by appdata.xml.

@Dan McGrath (dmcgrath), could you help us and upload these 4 screenshots somewhere they are not likely to get lost? I don't have access to the right servers.

• Change project license to GPL 3

• Remove copyright message

• Remove releases section
• Fix summary
• Fix bugtracker url
• Change description
• Use screenshots from blender.org

Maybe we could use the images in blender.org's homepage, under the title "Everything You Need"? As for who will maintain it, this should be a part of the linux release process so whoever is in charge of that or a volunteer. I don't mind submitting patches to keep this up to date.

The images should be official blender.org images, e.g. from open movies, and included from a blender.org source. Also, who is going to be responsible to keep this file up to date? We need to at least document this as part of the release process if we are going to include information about new releases.

Fixes apply to master and 2.8.

Ok, will consider this as resolved for now with a workaround, will be properly addressed in 2.8.

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

@Brecht Van Lommel (brecht) Thanks, now everything is ok after I changed the selection method.

Changing the Selection Method to Occlusion Queries under User Preferences > System may work around the issue. In Blender 2.8 this will likely become the default (and only) method.

Its highly likely that this bug is specific to your hardware/driver configuration. These kinds of display issues are often caused by OpenGL driver bugs.

Looked into this furher:

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.

In T53004#467186, @Campbell Barton (campbellbarton) wrote:

@Jonas Ådahl (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 (jadahl), AFAICS X11 doesn't have the concept of a hidden cursor, so not sure this is possible?

In T53004#467156, @Campbell Barton (campbellbarton) 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.

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.

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.

In T53004#465803, @TravLR (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.

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:

There's no un-merged patches on our side.

Well, that's exactly what I wrote.

Hi, original purpose of Blender was to produce images from 3D scene.
Historically, there was an audio sequencer decoupled from video sequencer. They were merged by 2.5 re-design.
If you take attention to Edit Strip panel in Metastrip properties, you can see that they are based on Scene, Movie, Image strips properties with a blend mode dedicated to image blending.

The back trace in report indicates crash somewhere inside of Mesa/LLVM. We can not fix that or patch from Blender side, the driver itself is to be brought to a state when it can handle complexity of Cycles kernels.

I understand this is not a Blender issue, however six months after the various bugs were filed, Blender 2.79 still crashes on compilation under Ubuntu 17.10 Beta 2 with LLVM 5.0 and Mesa 17.2.2, even though it appears to me that all reported bugs were fixed.

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

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

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

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.

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.