Dear Maintainer, I've just upgraded to Trixie and none of the applications running on the GNOME runtime work any more. A white colour window without any widgwet is displayed and the following error is printed in the console: $ flatpak run de.haeckerfelix.Shortwave MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete (shortwave:2): Gdk-WARNING **: 17:45:42.079: Vulkan: ../src/amd/vulkan/radv_physical_device.c:2041: Device '/dev/dri/renderD128' is not using the AMDGPU kernel driver: Invalid argument (VK_ERROR_INCOMPATIBLE_DRIVER) MESA-INTEL: warning: ../src/intel/vulkan_hasvk/anv_formats.c:759: FINISHME: support YUV colorspace with DRM format modifiers MESA-INTEL: warning: ../src/intel/vulkan_hasvk/anv_formats.c:790: FINISHME: support more multi-planar formats with DRM modifiers My computer has two graphic cards available: $ DRI_PRIME=0 glxinfo | grep "OpenGL renderer" OpenGL renderer string: Mesa Intel(R) HD Graphics 4000 (IVB GT2) $ DRI_PRIME=1 glxinfo | grep "OpenGL renderer" OpenGL renderer string: AMD TURKS (DRM 2.50.0 / 6.12.30-amd64, LLVM 19.1.7) However the environment variable seems to be ignored by Flatpak when I try to switch to the other graphic card: $ flatpak run --env=DRI_PRIME=1 de.haeckerfelix.Shortwave MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete (shortwave:2): Gdk-WARNING **: 17:49:57.143: Vulkan: ../src/amd/vulkan/radv_physical_device.c:2041: Device '/dev/dri/renderD128' is not using the AMDGPU kernel driver: Invalid argument (VK_ERROR_INCOMPATIBLE_DRIVER) MESA-INTEL: warning: ../src/intel/vulkan_hasvk/anv_formats.c:759: FINISHME: support YUV colorspace with DRM format modifiers MESA-INTEL: warning: ../src/intel/vulkan_hasvk/anv_formats.c:790: FINISHME: support more multi-planar formats with DRM modifiers The same applications work well in the desktop environment (GNOME and Wayland) when they have been installed from a Debian package.
Control: retitle -1 flatpak: Vulkan not working on dual-GPU system after upgrade to trixie
Control: tags -1 + moreinfo help
Dual-GPU has traditionally been a disaster area. I don't have a dual-GPU
system myself and am not familiar with the necessary workarounds.
Note that DRI_PRIME affects OpenGL, not Vulkan, but the error and
warning messages that you quoted would indicate use of Vulkan. There are
other mechanisms for selecting a preferred GPU for Vulkan, but I'm not
familiar with what the preferred/least-hackish of those mechanisms is.
Listing available GPUs with `switcherooctl list`, then comparing the
output of `switcherooctl launch --gpu=GPU env` for each one, might be
helpful?
Note that upstream GTK (as found in the GNOME runtime and used by
Flatpak apps) defaults to rendering using Vulkan, but Debian's GTK has
been patched to keep its old default of rendering using OpenGL.
A more apples-to-apples comparison would be to use environment variable
GSK_RENDERER=vulkan or GSK_RENDERER=gl to force a specific renderer:
GSK_RENDERER=gl gnome-recipes
flatpak run --env=GSK_RENDERER=gl org.gnome.Recipes
GSK_RENDERER=vulkan gnome-recipes
flatpak run --env=GSK_RENDERER=vulkan org.gnome.Recipes
If you can reproduce this with a GTK app that is small, simple and
doesn't have extraneous permissions, that would help to concentrate
debugging effort onto one specific scenario. GNOME Recipes is usually
the one I use for debugging if the specific app doesn't matter.
flatpak(1) and Debian don't have control over the content, choice or
precise behaviour of the graphics drivers inside the Flatpak container:
those are chosen by the runtime maintainer. In the case of the GNOME
runtime, they're inherited from the freedesktop SDK,
<https://gitlab.com/freedesktop-sdk/freedesktop-sdk/>
(more precisely, the 'org.freedesktop.Platform.GL.default' extension).
The exact behaviour of Vulkan rendering is likely to be an interaction
between:
* the kernel drivers, which were previously from bookworm but are now
from trixie (but you could potentially try installing a bookworm
kernel and rebooting back into it in order to check whether this is
relevant)
* the Wayland compositor, in your case GNOME Shell, which was previously
from bookworm but is now from trixie, and the libraries it depends on
* the app itself and the libraries and user-space graphics drivers it
depends on, which in the case of GNOME apps under Flatpak come from
org.gnome.Platform and org.freedesktop.Platform.GL.default
Running Flatpak as, for example, `flatpak run -vv org.gnome.Recipes`
would give more information about precisely what app, runtimes and
drivers are in use, and how Flatpak is sharing device nodes with the
container.
smcv
Hi Simon, thanks for your reply. Today I have tested running flatpak applications again on the same computer, and it looks like they are displayed without any issue now (no more white windows). I can still see the same warning messages I mentioned earlier, when I start the applications from the console but the applications are displayed as expected. On the other hand, these messages can be avoided by setting the environment variable GSK_RENDERER=gl, as you pointed out. Thank you very much for your help. I don't know why these applications are properly displayed now and not before. Maybe this has been fixed after rebooting the computer, although I am pretty sure that I rebooted the computer just after upgrading to Trixie. I think that I even rebooted it once again, when I found this issue, just to see if the it remained the same. Maybe the reason why it works now is that today I have installed some package updates, although I can't see any relation between this issue and the packages that have been updated today: Start-Date: 2025-06-16 09:19:10 Commandline: apt upgrade Upgrade: coreutils:amd64 (9.7-2, 9.7-3), busybox:amd64 (1:1.37.0-5, 1:1.37.0-6), libslf4j-java:amd64 (1.7.32-1, 1.7.32-2), libcommons-logging-java:amd64 (1.3.0-1, 1.3.0-2), fonts-wine:amd64 (10.0~repack-4, 10.0~repack-5), libnautilus-extension4:amd64 (48.1-2, 48.2-3), gnome-control-center-data:amd64 (1:48.1-2, 1:48.2-2), gnome-control-center:amd64 (1:48.1-2, 1:48.2-2), nautilus:amd64 (48.1-2, 48.2-3), nautilus-data:amd64 (48.1-2, 48.2-3) Thank you very much for your support. If I face the same issue again then I think that I could let you know about it, but for now I suppose that you can close the bug. Regads, David. El vie, 13 de jun de 2025 a las 20:04:05 P. M., Simon McVittie <smcv@debian.org> escribió: