search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
532 stars 46 forks source link

Graphical corruptions in some GTK4 apps due to mesa 24.1.4 regressions. #9389

Open aronowski opened 1 month ago

aronowski commented 1 month ago

How to file a helpful issue

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:

Screenshot_2024-08-03_15-15-39

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).

alimirjamali commented 1 month ago

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.

alimirjamali commented 4 weeks ago

@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):

pavucontrol

vulkan

marmarek commented 4 weeks ago

@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.

Yes, already fixed in main: https://github.com/QubesOS/qubes-core-agent-linux/commit/a6c95ffd7fcfc1343d62355137688c2c7e6010ef

marmarek commented 4 weeks ago

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...

DemiMarie commented 1 week ago

Does Mesa 24.2.x fix this?

DemiMarie commented 1 week ago

@marmarek: Can you reproduce with latest Mesa? If so, please file a bug report on https://gitlab.freedesktop.org/mesa/mesa.

aronowski commented 1 week ago

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.

alimirjamali commented 1 week ago

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.

DemiMarie commented 1 week ago

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.

Time to file a bug in Fedora bugzilla?

okias commented 1 week ago

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.

DemiMarie commented 1 week ago

@alimirjamali Can you force GDK (used by GTK) to fall back to GLX?

alimirjamali commented 1 week ago

@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

DemiMarie commented 1 week ago

@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

So this is (presumably) a GTK bug.