Vulkan not working under Wayland: 2117 - 2118.2 AppImage versions only.

[TutorialsOnDeck]

Is there an existing issue for this?

• [X] I have searched the existing issues

Affected Build(s)

2117 - 2118.2

Description of Issue

Summary: Vulkan is greyed out and provides error when using officially provided AppImages under Wayland. Versions 2117 to 2118.2 affected. EndeavourOS + AMD 6900 XT GPU.

Not Working: Versions 2117-2118.2 AppImage on Wayland.

Working: Tested on EndeavourOS with AMD 6900 XT / vulkan-radeon Versions 2115 to 2118.2 AppImages on X11. Version 2115 to 2116 AppImage on Wayland. Building 2118.2 from source on Wayland. Flatpak 2118.1 on Wayland.

I will liveboot other distros (ex Ubuntu, Fedora) in case it's Arch exclusive when I get some free time.

Expected Behavior

Open program Use Vulkan

Reproduction Steps

Using an AMD card with GPU passthrough to a VM or on bare metal. Use Arch linux, or a derivative (EndeavourOS will give you KDE + Wayland out of the box.) Ensure Wayland and KDE are used. Attempt to run Any AppImage between version 2117-2118.2 and observe

Log File

ERRORS:

From GUI: No Suitable Vulkan Drivers found. Vulkan initialization failed. From Lime3ds Log file: <Error> lime_qt/util/graphics_device_info.cpp:GetVulkanPhysicalDevices:45: Error occured while querying for physical devices: vk::createInstanceUnique: ErrorIncompatibleDriver From Terminal running the AppImage: qt.qpa.wayland: EGL not available

System Configuration

CPU: AMD 5900X GPU/Driver: AMD 6900 XT / Vulkan-Radeon RAM: 32GB DDR4 OS: Linux - EndeavourOS (Arch based) KDE Plasma + Wayland

[rtiangha]

Does it also not work on PabloMK7's fork?

And could you try my testing fork too? https://github.com/rtiangha/bravely-offline-citra/releases

Edit: I've also started to try making AppImages based off of different LTS versions of Ubuntu. Do any of these work? https://github.com/rtiangha/bravely-offline-citra/actions/runs/11215948291

[TutorialsOnDeck]

Just Tested: Endeavour OS - KDE Wayland. AMD 6900 XT / Vulkan-Radeon. All Lime3DS AppImage versions from 2115 to 2118.2 on both Fedora 40.1.4 KDE / Wayland and Kubuntu LTS 24.04 KDE / Wayland. No Vulkan issues.

Both your GCC and CLANG AppImages linked above. No Vulkan Issues.

PabloMk7's AppImage ver r608383e. No Vulkan Issues.

I am having a friend test 2115 to 2118.2 on their Steamdeck in a couple hours. I will also test across more arch based distros (Manjaro, Garuda, Arco) If there is a general Arch issue with the recent AppImages, its worth looking into as many Steamdeck (SteamOS) users could be affected.

[rtiangha]

So just to clarify: It's only Endeavour OS that's having issues with 2117 and 2118.2?

Just curious: What version of QT is installed locally on that distro right now? And X/Wayland? I'm not sure if it makes a difference right now; just looking to see if there are any patterns.

[TutorialsOnDeck]

wayland 1.23.1-1 xorg-xwayland 24.1.2-1 xorg-server 21.1.13-1 vulkan-radeon 1:24.2.3-1 qt6-wayland 6.7.3-1 qt5-wayland 5.15.15+kde+r59-1 If I missed a specific package, let me know and i'll update this comment.

[OpenSauce04]

I can replicate this issue on my machine using Sway, so I don't believe that this is an issue with your setup. The error does not occur under X11 using XFCE.

2117 introduced native Wayland support for the AppImage, so it appears that something is missing from the AppImage to allow Vulkan to function correctly under Wayland.

I definitely tested that the AppImage worked correctly under Wayland before introducing that change and I don't remember seeing this error, so I am unsure of what has changed. I believe that I built the AppImage locally when I tested it rather than using the CI build, so perhaps that caused the error to not appear?

[rtiangha]

Might be missing some libraries, then? Perhaps it'd be worthwhile to unzip AppImages that work vs AppImages that don't and see what gets pulled into the AppImage's /usr/lib (and compare what your local setups that work have installed vs what's installed on the docker build image in terms of dev and graphics libraries; might give some hints too).

Edit 1: What I don't understand is why those AppImages would work on Wayland before the change that included the two QT Wayland libraries. That doesn't make sense to me, unless it were running in some X11 compatibility mode (unless it was local builds all along and the ci build never worked in the first place, in which case it's probably missing libraries on the build runner).

Edit 2: Wait, if Wayland is working properly on my testing fork of PabloMK7's Citra, then it's probably the Lime3DS build runner that's missing things and it's just a matter of figuring out what it might be and it shouldn't be too hard to fix this. Here's most of the stuff that gets pulled into my Ubuntu 22.04 runner (which is the default Github Actions Ubuntu 22.04 runner plus my own additions):

ubuntu22.04pkgs.txt

Edit 3: Working off the premise that my custom AppImage is working properly, comparing the Lime3DS ci build with mine shows that the Lime3DS build has a lot more libraries than mine, lol. However, here are the different ones that mine has that the Lime3DS one doesn't, which isn't that many:

[reg@PROBOOK430-G4 temp]$ ls
libapparmor.so.1     libicui18n.so.73         libQt6Qml.so.6
libbz2.so.1          libicuuc.so.73           libQt6Quick.so.6
libFLAC.so.8         libpcre.so.3             libQt6Svg.so.6
libgthread-2.0.so.0  libpulsecommon-15.99.so  libxcb-cursor.so.0
libicudata.so.73     libQt6QmlModels.so.6     libXrandr.so.2

So hopefully that's a clue; otherwise, it's something that is statically built and included on my end, which will be trickier to figure out.

Edit 4: And for completeness, here's PabloMK7's differences:

[reg@PROBOOK430-G4 temp]$ ls
libapparmor.so.1     libjpeg.so.8            libsndio.so.7
libavcodec.so.61     libjxl_cms.so.0.10      libssh2.so.1
libavformat.so.61    libjxl.so.0.10          libssh.so.4
libavutil.so.59      libjxl_threads.so.0.10  libSvtAv1Enc.so.2
libcodec2.so.1.2     liblber.so.2            libswresample.so.5
libcurl-gnutls.so.4  libldap.so.2            libswscale.so.8
libdav1d.so.7        libnghttp2.so.14        libunistring.so.5
libduktape.so.207    libpsl.so.5             libvpl.so.2
libdvdnav.so.4       libpxbackend-1.0.so     libvpx.so.9
libdvdread.so.8      librav1e.so.0.7         libx265.so.209
libicudata.so.74     librtmp.so.1            libxcb-cursor.so.0
libicui18n.so.74     libsasl2.so.2           libxcb-xinput.so.0
libicuuc.so.74       libsharpyuv.so.0        libXrandr.so.2

I'm doubtful it's the libicu stuff, so perhaps it's the libxcb or libXrandr stuff? I hope this is the right track...

Edit 5: Now that I think about it, maybe it'd be easier just to look at PabloMK7's docker file and see what's different with the Lime3DS one, lol.

[OpenSauce04]

Looked into this further:

1. For whatever reason I can't get this issue to happen on my desktop despite having a nearly identical software setup compared to my laptop (which does experience the issue)
2. I found that mGBA had nearly the exact same issue that we are having here and had to use a manually patched version of qtwayland to get it to work. I found another somewhat similar issue from PCSX2 which resulted in them simply removing Wayland support from the AppImage because they couldn't make it work

I am starting to think that native Wayland support in the AppImage was a mistake.

[OpenSauce04]

I am also noticing that combining the users here and on mGBA we are 4 for 4 on users with AMD GPUs experiencing the issue. My laptop uses Intel integrated graphics and my desktop uses a modern Nvidia GPU. Perhaps this issue doesn't happen on Nvidia GPUs which is how it slipped by me in the first place?

[OpenSauce04]

I think I've spent enough time on this at this point. For now I will just revert the change and make the AppImage run through xwayland once again. Someone can come back to this at a later date if they wish to do so.