Regressions of first flathub release compared to AppImage

[Mershl]

Hi @liushuyu,

Thank you very much for pushing this flatpak. I've been running some tests with this first release on flathub.com.

Tested on:

• Kernel 5.12.9
• AMD RX6800 (mesa 21.1.1, radv)
• Gnome 40.2 (wayland session)

Things I've noticed in direct comparison to the AppImage:

• Vulkan Devices are not listed when choosing Vulkan API
• Compatibility column is set to "Not Tested" and does not refresh
  • Maybe this? Qt: Session management error: None of the authentication protocols specified are supported
• The default Light Theme is actually Dark. (Tested on Gnome 40 with Yaru Theme)
• Starting a game with Vulkan crashes yuzu with Unhandled SIGSEGV at rip 0x0055a5cfe49000
• Running a game with OpenGL boots, but immeditaly turns the window fully transparent. The log fills with:
  • Wayland specific. Running the flatpak without wayland socket fixes this issue.

dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension
dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension
QWaylandGLContext::makeCurrent: eglError: 3002, this: 0x7f0a2b7163a0 

I'll continue testing to find the sources of these issues.

[liushuyu]

Thank you very much for your feedback! Some of the issues are currently known and we are working to fix them.

Things I've noticed in direct comparison to the AppImage:

At the moment, we do not plan to replace AppImage with Flatpak, so we can fix the issues while a more feature-complete distribution is around.

• Vulkan Devices are not listed when choosing Vulkan API

Which graphics card are you using? If your answer is NVIDIA, then the issue is tricky, you need to check if you have the NVIDIA proprietary driver portal system installed by examining the output of flatpak list command. You should see something similar as follows:

Name                                    Application ID                                       Version                   Branch           Installation
Citra                                   org.citra_emu.citra                                  nightly-1711              stable           user
Mesa                                    org.freedesktop.Platform.GL.default                  21.1.1                    20.08            system
Mesa                                    org.freedesktop.Platform.GL.default                  21.1.1                    20.08            user
nvidia-465-31                           org.freedesktop.Platform.GL.nvidia-465-31                                      1.4              system
nvidia-465-31                           org.freedesktop.Platform.GL.nvidia-465-31                                      1.4              user
openh264                                org.freedesktop.Platform.openh264                    2.1.0                     2.0              system
openh264                                org.freedesktop.Platform.openh264                    2.1.0                     2.0              user
Breeze Gtk theme                        org.gtk.Gtk3theme.Breeze                                                       3.22             system
Adwaita theme                           org.kde.KStyle.Adwaita                                                         5.15             system
KDE Application Platform                org.kde.Platform                                                               5.15             system
KDE Application Platform                org.kde.Platform                                                               5.15             user
KDE Software Development Kit            org.kde.Sdk                                                                    5.15             system
Yuzu                                    org.yuzu_emu.yuzu                                    mainline-0-655            stable           user

As you can see, the items begin with nvidia- are driver portals, if you don't have them installed, you need to install them (with the correct version matching the ones on your host system).

• Compatibility column is set to "Not Tested" and does not refresh

This is because the Flatpak version of Yuzu is built using FlatHub CI and their CI system forbids connecting to the Internet while building. Our current build system will fetch a compatibility list via the network during build time, so the compatibility list will be missing. We are currently working to fix this in a similar fashion as Citra did.

• The default Light Theme is actually Dark. (Tested on Gnome 40 with Yaru Theme)

This is likely due to an interoperability issue with themes. Default themes are handled by the host system and will always match the colors and styles with the themes you are currently using on the host system.

• Starting a game with Vulkan crashes yuzu with Unhandled SIGSEGV at rip 0x0055a5cfe49000

This is likely due to the first issue you mentioned with unable to select Vulkan devices. I can't reproduce this issue on my device:

• Running a game with OpenGL boots, but immediately turns the window fully transparent. The log fills with:

Again, the last two issues are probably the byproduct of the first one you mentioned. We need you to upload a copy of the log to verify the issue.

[Mershl]

Added my specs to the main post.

Vulkan Devices are not listed when choosing Vulkan API

Found the culprit for that. mesa provides 2 ICD loaders for AMDGPU - radeon and lavapipe (lvp). Setting VK_ICD_FILENAMES to only include radeon will result in the Vulkan device selection of Yuzu being empty, and the crash. Leaving the VK_ICD_FILENAMES unset will make the device selection of Yuzu working as intended.
Unfortunatly due to an upstream mesa issue it's currently necessary to restrict the available ICDs to radeon (e.g. https://gitlab.freedesktop.org/mesa/mesa/-/issues/4828).

• This behaviour is different to the AppImage (which works with VK_ICD_FILENAMES restricted to radeon).
• Workaround for now: ensure VK_ICD_FILENAMES is unset.

Starting a game with Vulkan crashes yuzu with Unhandled SIGSEGV at rip 0x0055a5cfe49000

This issue is resolved while VK_ICD_FILENAMES is unset. Tested with mesa 21.1.1.

Running a game with OpenGL boots, but immeditaly turns the window fully transparent. The log fills with:
Wayland specific. Running the flatpak without wayland socket fixes this issue.

This issue remains and also applies to Vulkan, now that is boots and runs. Games start (Audio is playing, but the window turns fully transparent). Log still fills with dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension and QWaylandGLContext::makeCurrent: eglError: 3002, this: 0x7f51f1d55200. Tested with Gnome 40.2 (wayland session).

• Workaround for now: Removing socket=wayland from the apps permission makes Yuzu fallback to Xwayland.

With both workarounds in place games boot and run as expected using OpenGL and Vulkan.

[liushuyu]

Thanks for your investigation!

Found the culprit for that. mesa provides 2 ICD loaders for AMDGPU - radeon and lavapipe (lvp). Setting VK_ICD_FILENAMES to only include radeon will result in the Vulkan device selection of Yuzu being empty, and the crash. Leaving the VK_ICD_FILENAMES unset will make the device selection of Yuzu working as intended.
Unfortunatly due to an upstream mesa issue it's currently necessary to restrict the available ICDs to radeon (e.g. https://gitlab.freedesktop.org/mesa/mesa/-/issues/4828).

I am afraid this is not something I could workaround at the moment. I will however ask Flatpak folks for ideas (if they ever reply to my messages that is).

This issue remains and also applies to Vulkan, now that is boots and runs. Games start (Audio is playing, but the window turns fully transparent). Log still fills with dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension and QWaylandGLContext::makeCurrent: eglError: 3002, this: 0x7f51f1d55200. Tested with Gnome 40.2 (wayland session).

I have removed socket=wayland starting version mainline-0-657 as suggested.

[liushuyu]

Sorry for the ping, are there any other issues since mainline-0-667?

[Mershl]

Hi @liushuyu, I've went on a testing spree yesterday with yuzu 667 and all games I own.

• I've not found a single new regression compared to the AppImage. The Flatpak is now my daily driver.
• The "window turns completly transparent" bug is still present if socket=wayland is locally forced. I'm not quite sure what is breaking here. Thanks for disabling it per default for now - this fixes it.
• The "VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.i686.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json resulting in 0 Vulkan devices in Flatpak Yuzu" bug is still present. This is a regression of Flatpak Yuzu compared to AppImage Yuzu. AppImage Yuzu will still find the correct Vulkan device as expected, but Flatpak Yuzu will list 0 Vulkan devices with the env var set.
• I've successfully used the new GPU cache garbage collection, which allowed SSBU to run for longer than 2 hours when running with 1 player (see below).
• Besides that I'm currently hunting a ghost bug (have seen this for at least 10 mainline releases): Playing SSBU with two players (a DS4 + a XboxOne controller) the control scheme sometimes scrambles completly for the XboxOne controller - A turns B, X turns Y etc. - complete chaos. I was only able to reproduce it with this controller combination, and it only happens to the XboxOne controller. There are no errors visible in the log and jstest shows the correct buttons pressed as expected. I'll continue to look into it.
• Also... SSBU runs really stable with 1 player but is really crash prone with 2 players. I'll test it with different controllers later today to ensure the Xbox One controller isn't the root cause here.
• No regressions found for Links Awakening, Pokemon and MK8.

[liushuyu]

Thank you very much for your report!

I also received some reports from other members of the community, I will document the findings here as well:

• "Open yuzu folder" function does not work: confirmed to be a combination of several Flatpak bugs:
  • Flatpak: directories mounted via --filesystem=xdg-data/<app_name>:create not handled by OpenURI flatpak/xdg-desktop-portal#594
  • Flatpak: file paths in /var/data, etc. not handled by OpenURI portal flatpak/xdg-desktop-portal#592
  • Directories mounted to flatpak sandbox via --persist can't be opened in other apps flatpak/xdg-desktop-portal#591
• On KDE, the folder picker is showing a file picker dialog: confirms to be an UI design issue with KDE's XDP implementation (it's a folder picker, but incorrectly labeled as file picker): https://invent.kde.org/plasma/xdg-desktop-portal-kde/
• Yuzu can't be launched correctly on certain Desktop Environment + Distribution combinations (known problematic combination: Xfce + Arch Linux): this seems to be an interoperability issue between XDP (xdg-desktop-portal) and Arch Linux packaged Xfce suites. Tested on some other Linux distributions with Xfce and found no issue.
• Discord Rich Presence seems to be broken: flags not enabled.

[iMonZ]

Added my specs to the main post.

Vulkan Devices are not listed when choosing Vulkan API

Found the culprit for that. mesa provides 2 ICD loaders for AMDGPU - radeon and lavapipe (lvp). Setting VK_ICD_FILENAMES to only include radeon will result in the Vulkan device selection of Yuzu being empty, and the crash. Leaving the VK_ICD_FILENAMES unset will make the device selection of Yuzu working as intended.
Unfortunatly due to an upstream mesa issue it's currently necessary to restrict the available ICDs to radeon (e.g. https://gitlab.freedesktop.org/mesa/mesa/-/issues/4828).

• This behaviour is different to the AppImage (which works with VK_ICD_FILENAMES restricted to radeon).
• Workaround for now: ensure VK_ICD_FILENAMES is unset.

Starting a game with Vulkan crashes yuzu with Unhandled SIGSEGV at rip 0x0055a5cfe49000

This issue is resolved while VK_ICD_FILENAMES is unset. Tested with mesa 21.1.1.

Running a game with OpenGL boots, but immeditaly turns the window fully transparent. The log fills with:
Wayland specific. Running the flatpak without wayland socket fixes this issue.

This issue remains and also applies to Vulkan, now that is boots and runs. Games start (Audio is playing, but the window turns fully transparent). Log still fills with dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension and QWaylandGLContext::makeCurrent: eglError: 3002, this: 0x7f51f1d55200. Tested with Gnome 40.2 (wayland session).

• Workaround for now: Removing socket=wayland from the apps permission makes Yuzu fallback to Xwayland.

With both workarounds in place games boot and run as expected using OpenGL and Vulkan.

Is there a reason why Wayland is not working?

Oh and please set this variable instead of removing the wayland socket: QT_QPA_PLATFORM=xcb

[Mershl]

Oh and please set this variable instead of removing the wayland socket: QT_QPA_PLATFORM=xcb

Hi @iMonZ, can you please elaborate on this? From a Gnome LookingGlas point of view (ALT+F2 -> lg) both ways seem to have the same effect. Yuzu will run through XWayland on Wayland, instead of native.

This issue remains and also applies to Vulkan, now that is boots and runs. Games start (Audio is playing, but the window turns fully transparent). Log still fills with dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension and QWaylandGLContext::makeCurrent: eglError: 3002, this: 0x7f51f1d55200. Tested with Gnome 40.2 (wayland session).

Tested on Gnome 41.0 (wayland) and latest yuzu flatpak. This issue still shows once native Wayland (--socket=wayland) is enabled. The following warning is logged when run with --socket=wayland:

dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension