<div id="geary-body" dir="auto"><div><div>Hi Simon, thanks for your reply.</div><div><br></div><div>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.</div><div><br></div><div>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: </div><div><br></div><div>Start-Date: 2025-06-16 09:19:10</div><div>Commandline: apt upgrade</div><div>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)</div><div><br></div><div>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.</div></div><div><br></div><div>Regads,<br>David.</div></div><div id="geary-quote" dir="auto"><br>El vie, 13 de jun de 2025 a las 20:04:05 P. M., Simon McVittie <smcv@debian.org> escribió:<br><blockquote type="cite"><div class="plaintext" style="white-space: break-spaces;">Control: retitle -1 flatpak: Vulkan not working on dual-GPU system after upgrade to trixie
Control: tags -1 + moreinfo help
On Fri, 13 Jun 2025 at 18:42:57 +0100, David Hoces Pérez wrote:
<blockquote>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
</blockquote>
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?
<blockquote>The same applications work well in the desktop environment (GNOME and
Wayland) when they have been installed from a Debian package.
</blockquote>
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, <<a href="https://gitlab.com/freedesktop-sdk/freedesktop-sdk/">https://gitlab.com/freedesktop-sdk/freedesktop-sdk/</a>> (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
</div></blockquote></div>