It has been brought to the SRU team’s attention that mutter has landed a significant new feature in the 46.1 point release¹.
The GNOME MicroReleaseException policy historically exists on the basis that the GNOME release and testing process broadly matches SRU policy, so duplicating that process by performing a full SRU review on GNOME point releases would be unnecessary work. Since mutter no longer appears to have the same understanding of that process as we do, mutter SRUs will not be covered by the GNOME MRE going forward.
Mutter & GNOME Shell point releases may still be acceptable under the normal micro release process; this can be checked on a case-by-case basis.
¹: Specifically, explicit sync support from this PR.
Reading that was surprising as an outsider, as I think one would naturally assume that gnome-shell and mutter would be the most foundational parts of a “GNOME release”, and would be under more limitations for what is allowed in for what would appear to most folks as a “minor” release.
Does this change mean that the explicit sync patches needed to make Nvidia drivers usable on Wayland and stop the flickering will not land in 24.04? From an end-user perspective, I don’t think this is a new feature so much as a bug fix for one of the largest issues using Nvidia on Linux.
It means that such code landing in 24.04 would depend on being submitted to, and going through, the Stable Release Update process linked to in the original post of this thread.
As I would see it (not an Ubuntu dev, but from an outsider perspective, and I’m sure way oversimplifying), it’s a new feature, not a bug fix, because it’s not that there’s existing code that tries to do something but doesn’t work correctly - it’s new code for a new way of pushing graphics to the screen, which didn’t previously exist in GNOME/Mutter/Wayland/etc.
That carries with it new opportunities for things to go wrong, and the LTS model would generally be opposed to introducing new functionality that breaks things that already work - so it has to be evaluated a lot more strictly.
I’ve been tasked with looking into this, and I don’t want to preempt my own findings.
Currently I am testing 46.1 on four systems (two Intel, two AMD) to get some personal confidence that it is not breaking anything obvious. Though I don’t run any Nvidia systems full time.
Later this month I will analyse the code changes in more detail to better inform my opinion.
I am hoping we can get the full 46.1 46.2 into Noble without dropping anything, but it will take more time, analysis and discussion.
I’ve now had the time to look into the offending change, why it exists and how Ubuntu wants to release it. The change exists, currently, in support of Xwayland 24.1 to get legacy apps rendering correctly in Nvidia Wayland sessions. That’s something Ubuntu plans to do in 24.10 but no sooner. Not just because of the recency of Xwayland 24.1, but because it also doesn’t work correctly without Nvidia driver 555 which is still in beta and not even in Oracular yet.
So it’s a yes for 24.10 and a no for 24.04. That is unless some day in 24.04.x we find ourselves with Xwayland >= 24.1 and nvidia-graphics-drivers-[>=555] in Noble. Then we might reconsider.
For now I would like to propose a small modification to Mutter 46.2 that I hope will allow it to flow into Noble updates:
This prevents the new logic from being initialised, advertised or usable by Wayland clients including Xwayland. And crucially it would be a trivial patch we can put on top of Mutter 46.2 paving the way for Noble to receive all future Mutter point releases without risk of conflict.
@raof, since you’re the SRU team member with this particular domain knowledge I am proposing this to you first before commencing any work in Salsa. Edit: Also @tjaalton in case you’re interested
If removing the syncobj_init is sufficient to cause Mutter to fall back to the existing codepaths, then that seems like a good way forward. (I’ve not verified that myself yet ). My concern would be that this diverges testing away from upstream GNOME releases, but from a look at the various open-source stacks, only Vulkan clients are currently likely to use syncobj when it is available, so the non-syncobj codepath should still be well tested.
Mutter internally also checks for driver support and will disable the feature itself if unsupportable. So not having it available is very much a supported upstream use case.
I’m reporting informations I remember being given from a KWin maintainer, but memory may serve me wrong…
Native Wayland apps do not experience jankiness because nvidia has implemented hacks that prevent the issue while trading some performance. So the wayland-client ↔ wayland-compositor path “works” even without explicit sync, including for XWayland acting as a wayland-client.
). My concern would be that this diverges testing away from upstream GNOME releases, but from a look at the various open-source stacks, only Vulkan clients are currently likely to use syncobj when it is available, so the non-syncobj codepath should still be well tested.