PS uses XWayland and ignores GDK_BACKEND on Wayland

[gudvinr]

Description of the bug

When used in Wayland session, PS uses XWayland.
It does so by explicitly overriding GDK_BACKEND environment variable.
It is stated here that wxGTK doesn't support Wayland, which it does since 2013.

There were some issues with wxWidgets not working properly under Wayland over the years so this stance should be revisited at least.

In any case, "fixing" this by overriding user-defined environment variables can be considered a bad programming practice.

Here's proof of it being run under XWayland.

From practical standpoint, that leads to blurry fonts when fractional scaling is used:

Project file & How to reproduce

Issue isn't related to any particular project.

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.4.2

Operating system

Linux (Arch Linux, KDE Plasma 5.24, GTK3 3.24.33)

Printer model

Not applicable

[lukasmatena]

The override was added as a response to #4691, #2515. The combination of wxWidgets+GTK3+Wayland crashed, which also some consider to be a bad practice. And those issues are not that old.

Did you compile PrusaSlicer yourself? With what wxWidgets version? It is possible that just a certain combination is affected. It is also possible that the situation has a better fix.

[gudvinr]

I just tried to build PS without GDK_BACKEND override and wxgtk3 3.1.6 (which is kinda sorta stable-ish but not included in any distributive).

It doesn't break while calling X11 methods anymore as in #4691 but now I see segfault that comes somewhere from PS when it calls SetLanguage:

                #0  0x00005632572770d5 _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_assignERKS4_ (prusa-slicer + 0xa540d5)
                #1  0x00007f1e53f0f2eb _ZN14wxTranslations11SetLanguageE10wxLanguage (libwx_baseu-3.1.so.6 + 0x18b2eb)
                #2  0x0000563257267856 n/a (prusa-slicer + 0xa44856)
                #3  0x00005632572696ac n/a (prusa-slicer + 0xa466ac)
                #4  0x000056325726c27b n/a (prusa-slicer + 0xa4927b)
                #5  0x00007f1e53eb3412 _Z7wxEntryRiPPw (libwx_baseu-3.1.so.6 + 0x12f412)
                #6  0x00005632572506be n/a (prusa-slicer + 0xa2d6be)
                #7  0x0000563256b2b812 n/a (prusa-slicer + 0x308812)
                #8  0x0000563256b0fb0a n/a (prusa-slicer + 0x2ecb0a)
                #9  0x00007f1e526f0310 __libc_start_call_main (libc.so.6 + 0x2d310)
                #10 0x00007f1e526f03c1 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2d3c1)
                #11 0x0000563256b23e55 n/a (prusa-slicer + 0x300e55)

[lukasmatena]

@gudvinr I believe that @YuSanka has also seen the SetLanguage segfault when she attempted to build against wxWidgets 3.1.6, it is related to something that has changed in wxWidgets between 3.1.5 and 3.1.6. Not related.

If we knew when the Wayland issue disappeared (with which wxWidgets version), maybe we could do the env variable override conditionally. The two issues were reported by package maintainers who link against 3.0.x.

[gudvinr]

I believe that related issue was fixed in 3.1.5, according to their changelog:

• Implement EGL-based wxGLCanvas for Wayland (Scott Talbert).

I believe so because issues were related to call from wxGLCanvasX11.

3.1.6 has some changes related to locale:

• Add wxUILocale: CompareStrings(), GetLocalizedName() etc.
• Update and extend list of known locales (Ulrich Telle).

This is likely fixable on PS side though unless it is an upstream issue.

[lukasmatena]

@gudvinr We are currently in the process of updating from 3.1.4 to 3.1.6. We will test whether the override is still necessary. There may be other issues, even if the crash is gone. If all is fine, we would do something like this: 3080289

[lukasmatena]

@gudvinr We tried to remove the override after upgrading to wxWidgets 3.1.6. It is true that the application no longer crashes. However, it is also practically unusable:

It may or may not have a simple fix. As of now, we are not investing time into it, there are higher priority issues. If someone knows how to fix it, let us know. Thanks.

When these issues are fixed (providing it is not caused by a bug in wxWidgets), we will disable the GDK_BACKEND override for wxWidgets 3.1.5, as shown below:

Click to expand!

--- a/src/PrusaSlicer.cpp
+++ b/src/PrusaSlicer.cpp
@@ -57,6 +57,10 @@
     #include "slic3r/GUI/GUI_Init.hpp"
 #endif /* SLIC3R_GUI */

+#ifdef __WXGTK__
+    #include <wx/version.h>
+#endif
+
 using namespace Slic3r;

 static PrinterTechnology get_printer_technology(const DynamicConfig &config)
@@ -71,10 +75,13 @@ int CLI::run(int argc, char **argv)
     set_current_thread_name("slic3r_main");

 #ifdef __WXGTK__
+    #if !wxCHECK_VERSION(3, 1, 5)
     // On Linux, wxGTK has no support for Wayland, and the app crashes on
     // startup if gtk3 is used. This env var has to be set explicitly to
     // instruct the window manager to fall back to X server mode.
+    // This was supposedly fixed in wxWidgets 3.1.5 (https://github.com/prusa3d/PrusaSlicer/issues/8284)
     ::setenv("GDK_BACKEND", "x11", /* replace */ true);
+    #endif
 #endif

        // Switch boost::filesystem to utf8.

</details>

[gudvinr]

@lukasmatena thanks for investigation. Do you see these issues only if Wayland backend is used or is it an issue you see in X11 too with wx 3.1.6?

[lukasmatena]

@gudvinr As far as I know, the issue is on Wayland only. @tamasmeszaros will correct me if not.

[mangado]

read this!
gtk4 reference - migrating from gtk3 to gtk4:
"Stop using grabs
GTK 4 no longer provides the gdk_device_grab() or gdk_seat_grab() apis"

Not only, there is no any notification when you move window.

Not only in GTK4!
In session wayland+gtk+3 also, no grab, no move notifications...

Codeblocks uses wxAui... and you can't move undocked widgets!
Probably thats (no grab, no move notification) are source of your issues...

[bubnikv]

@tamasmeszaros investigated the Wayland / OpenGL context issue. It took him multiple days to produce a simple reproducible code snippet to reproduce the issue.
wxWidgets/wxWidgets#22580

Until this issue is resolved, we will have to resort to X11 emulation.

[gudvinr]

Thank you guys for doing a research and even going beyond that and creating high quality issue report. I hope now since wx released 3.2 now it will get some traction there.

[mijoharas]

Hi, I'm also getting a segfault that appears to be at wxTranslations::SetLanguage(wxLanguage) (running prusa-slicer on wayland). Is there any further debugging help needed?

It sounds like you've got a repro and everything, but let me know if there's anything I can do to help.

Is there any workaround for this? I immediately get a segfault whether I run with GDK_BACKEND=x11 or not.

[lukasmatena]

@mijoharas what build are you using and where you got it?

[gudvinr]

I have this issue with arch build but I assume that is because they switched to wx 3.2 and this is exact same issue as we discussed before which happens on wx 3.1.6.
So either PS should be hotfixed through patch in arch build system or via minor PS release to make it work or it'll just remain broken until 2.5.0 arrives in repo.

[mijoharas]

Yep, I'm also using the arch build and having this problem.

[lukasmatena]

@gudvinr @mijoharas Your issues have nothing to do with Wayland or PrusaSlicer. They are caused by Arch packaging: #8299 (comment)

[gudvinr]

Yeah, that is basically what we were talking about in may

I believe that YuSanka has also seen the SetLanguage segfault when she attempted to build against wxWidgets 3.1.6, it is related to something that has changed in wxWidgets between 3.1.5 and 3.1.6. Not related.

What they should've done instead is package new release as wxgtk and old one as wxgtk30 or something similar as it is done regularly with electron packages. That way it is possible to link all packages to 3.0 release and gradually switch over to 32 as it is more widely adopted. But they decided to push it next day after release.

In any case it is completely separate topic which has nothing to do with Wayland support as you already said

[gudvinr]

@lukasmatena issue was possibly fixed in wxWidgets/wxWidgets@952de60

Also it's in https://www.wxwidgets.org/news/2023/10/wxwidgets-3.2.3-released/