qubes-issues
qubes-issues copied to clipboard
QubesOS
Graphical corruptions in some GTK4 apps due to mesa 24.1.4 regressions.
Qubes OS release
4.2.2
Brief summary
Graphical corruptions in certain applications like Nautilus or Loupe (potentially affecting others that use libgtk-4.so.1) when doing resizing-related operations on their windows after upgrading mesa from 24.1.3 to 24.1.4.
Steps to reproduce
In an archlinux template-based AppVM install nautilus and download the good and problematic mesa packages:
$ wget https://archive.archlinux.org/repos/2024/07/18/extra/os/x86_64/mesa-1%3A24.1.3-1-x86_64.pkg.tar.zst https://archive.archlinux.org/repos/2024/07/18/extra/os/x86_64/mesa-1%3A24.1.4-1-x86_64.pkg.tar.zst
Install the bad one, as a future proof that the bug is present between it, and its predecessor:
$ sudo pacman -U mesa-1\:24.1.4-1-x86_64.pkg.tar.zst --noconfirm
Open up Nautilus and do some resize-related operations on its window, like resizing, maximizing, etc. The window should get corrupted, like in the screenshot below:
Close Nautilus, install the good mesa package:
$ sudo pacman -U mesa-1\:24.1.3-1-x86_64.pkg.tar.zst --noconfirm
Reopen Nautilus and again do some resize-related operations on its window. No graphical corruptions should occur.
This bug is also present when having a fedora-40 template up to date. However, the report accounts for using archlinux as the difference between the mesa releases in Fedora 40 are much bigger for a precise report. In Fedora 40, downgrading its mesa release to 24.0.5 fixes the same issue:
$ sudo dnf install mesa-dri-drivers-24.0.5-1.fc40.x86_64 -y
Expected behavior
Windows of apps like Nautilus or Loupe don't receive graphical corruptions when being resized.
Actual behavior
Windows of apps like Nautilus or Loupe get graphical corruptions when being resized, making e.g. managing files or previewing images hard, if not impossible (e.g. when an image is rendered only to about half the size of the screen).
Most probably related to #9374
Since the workaround for 9374 (using the deprecated Cairo renderer) is a temporal solution and the support for Cairo might be dropped in GTK5, keeping this issue open is recommended as it provides better details on the exact problematic package version.
@marmarek I believe the patch for #9268 (cairo software-rendering by default) should be applied to all (DEFAULT_ENABLED_NETVM, DEFAULT_ENABLED_PROXYVM, DEFAULT_ENABLED_APPVM, DEFAULT_ENABLED_TEMPLATEVM). Not just DEFAULT_ENABLED.
I am testing fedeora-41 templates and the default renderer for gtk4.15.5 is now Vulkan. It is horribly broken at the moment. Even worse than OpenGL. This happened to pavucontrol on my sys-audio (which has provide_network property set to make the servicevm feature enabled. So it ends up in SERVICE tab of Appmenu with ServiceVM icons):
@marmarek I believe the patch for #9268 (cairo software-rendering by default) should be applied to all (
DEFAULT_ENABLED_NETVM, DEFAULT_ENABLED_PROXYVM, DEFAULT_ENABLED_APPVM, DEFAULT_ENABLED_TEMPLATEVM). Not justDEFAULT_ENABLED.
Yes, already fixed in main: https://github.com/QubesOS/qubes-core-agent-linux/commit/a6c95ffd7fcfc1343d62355137688c2c7e6010ef
This happened to pavucontrol on my sys-audio
This BTW I observe also on F41 running natively (with access to the GPU), not in a VM. So, something is very broken there...
@marmarek: Can you reproduce with latest Mesa? If so, please file a bug report on https://gitlab.freedesktop.org/mesa/mesa.
Does Mesa 24.2.x fix this?
Initial tests in an archlinux template-based AppVM show that things look OK:
$ pacman -Q mesa
mesa 1:24.2.2-1
Though I'd still keep this ticket open at least until Fedora 40 starts shipping Mesa 24.2.x.
Does Mesa 24.2.x fix this?
Just tested this on R4.3Alpha with Fedora 41 testing templates which has Mesa 24.2.2 installed. The bug still persists. I wonder what else is updated in Archlinux which is missing in Fedora.
Does Mesa 24.2.x fix this?
Initial tests in an
archlinuxtemplate-based AppVM show that things look OK:$ pacman -Q mesa mesa 1:24.2.2-1Though I'd still keep this ticket open at least until Fedora 40 starts shipping Mesa 24.2.x.
Time to file a bug in Fedora bugzilla?
Beware important difference: Mesa 24.1 let GDK to fallback to GLX on X11, while Mesa 24.2 let GDK use EGL. So for 24.1 and 24.2 it is potentially different bug.
@alimirjamali Can you force GDK (used by GTK) to fall back to GLX?
Forcing GDK_DEBUG=gl-glx solves the issue on Fedora 41 templates with Mesa 24.2.2
@alimirjamali Can you force GDK (used by GTK) to fall back to GLX?
Forcing
GDK_DEBUG=gl-glxsolves the issue on Fedora 41 templates with Mesa 24.2.2
So this is (presumably) a GTK bug.
On Fedora 41 wtih Mesa 24.2.4, the problem appears to be fixed with GDK_DEBUG= GSK_RENDERER=auto App. Which reverts to Vulkan. Also setting the GSK_RENDERER to gl works fine. I could not find the exact fixed culprit in Mesa 24.3.4 release notes (or GTK release notes).
This BTW I observe also on F41 running natively (with access to the GPU), not in a VM. So, something is very broken there...
After installing F41 updates from updates-testing (including https://bodhi.fedoraproject.org/updates/FEDORA-2024-8b18ef8dfb) in dom0, things improved. pavucontrol works okay now. I'm not sure what specifically helped, as there was a lot of packages updated including Mesa 24.2.4 (and also updated to 6.11.2 kernel at the same time). I need to do some more testing to confirm it solves all issues (including Fedora 41 template, different hardware etc).