Wayland backend not working in Plots.jl GR backend

[VarLad]

In Julia 1.7.0beta3, Plots v1.20.1, GR.jl v0.58.1
I realized that the default (GR) backend uses XWayland for the plotting window
Anyway I can use Wayland instead?
I usually get:
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.

After doing
ENV["QT_QPA_PLATFORM"]="wayland" in Julia, or starting julia with QT_QPA_PLATFORM=wayland julia
I get the same error, the error being,

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: linuxfb, minimal, offscreen, vnc, xcb.

connect: Connection refused
GKS: can't connect to GKS socket application

[IngoMeyer441]

Hey @VarLad, thanks for reporting this issue. I can reproduce this behavior on Ubuntu 20.04 with Wayland enabled.

GR itself does not depend on X when the Qt output driver is used. I looked at the ~/.julia/artifacts directory and there is no Qt plugin for wayland. Probably, the Qt5Base_jll package needs to be changed to include the wayland output plugin.

[VarLad]

@barche any idea?

[VarLad]

After some searching around, I think, to achieve a wayland backend, we'll have to build Qt5Base_jll with https://github.com/qt/qtwayland

I've no idea how viable that is though! 😅

[mkitti]

If you do ENV["JULIA_GR_PROVIDER"] = "GR" and then using Pkg; Pkg.build("GR"), do you have the same issue? This will get the sciapp tarball rather than the BinaryBuilder.org one

cc: @jheinen

[VarLad]

@mkitti Thanks! Correct, that uses the Wayland version!

[mkitti]

Great, so we have a workaround.

You may want to file an issue on this build script then:
https://github.com/JuliaPackaging/Yggdrasil/blob/master/Q/Qt5Base/build_tarballs.jl

[wheeheee]

I'm seeing this again on GR.jl v0.69.5 at least. The workaround doesn't seem to work anymore :(

[ggebbie]

I confirm that the workaround is not working for me on:
ubuntu 22.04, Plots v1.35.6, GR v0.69.5, julia 1.8.2

it did work with: Plots v1.33.0, GR v0.66.2, julia 1.8.2

[jheinen]

The GR binaries thing has never been established in the Julia community, unfortunately - so all the logic was removed in favor of BinaryBuilder. The origin of the problem is that Wayland is not compiled into the Qt5Base_jll BinaryBuilder binaries.

[mkitti]

Err... time for me to review the recent changes.

[mkitti]

Looks like we removed support as GR.jl v0.68.0:

jheinen/GR.jl#465

[mkitti]

jheinen/GR.jl#471 may provide an alternate work around.

@t-bltg could you help me formulate what a new work around might be?

Loosely,

1. One would need to download the appropriate tarball from https://github.com/sciapp/gr/releases
2. Extract the tarball
3. Execute the following.

using GR
GR.GRPreferences.use_system_binary("/path/to/extracted/gr/tarball")

Frankly, I think we could probably recover the build script, but just integrate this with the new Preferences.jl mechanism:
https://github.com/jheinen/GR.jl/blob/e7940105f3594e3c8ed0c1d75f846d7358a35b3f/deps/build.jl

[t-bltg]

Untested, but looks good.

You can either use GR.GRPreferences.use_system_binary to make the changes persistent, or set the env variable GRDIR to the extracted tarball path before starting julia.

No need to ] build GR, we use dlopen in GR.

[jheinen]

At first glance, this seems to work. But under Linux, a simple 3D plot (using GR; surface(peaks())) fails - tests do not run through either.

I had to pre-load most of the GR libraries before starting Julia:

export GRDIR=/usr/local/gr
export LD_PRELOAD="/usr/local/gr/lib/libGR.so /usr/local/gr/lib/libGR3.so /usr/local/gr/lib/libGR3platform.so /usr/local/gr/lib/libGRM.so /usr/local/gr/lib/libGKS.so /usr/local/gr/lib/aggplugin.so /usr/local/gr/lib/cairoplugin.so /usr/local/gr/lib/gsplugin.so /usr/local/gr/lib/pgfplugin.so /usr/local/gr/lib/svgplugin.so /usr/local/gr/lib/videoplugin.so"
julia ...

I'm still trying to understand why the preload mechanism is required.

[t-bltg]

Sometimes some segfaults are observed in 3d plots (jheinen/GR.jl#480), what I usually do is re-download and extract the artifacts, quite odd.

[mkitti]

I created a pull request which restores the build script as a module under GRPreferences: jheinen/GR.jl#483

Mostly this is to restore the download logic.