[KAMI911]

Summary

• meta_renderer_is_hardware_accelerated() relied only on the cogl GPU architecture, which is resolved only after GL_VENDOR matched a known Mesa vendor string. Mesa has reported "Mesa Project", "Mesa/X.org" and plain "Mesa", so llvmpipe/softpipe/swrast ended up as ARCHITECTURE_UNKNOWN, which counts as hardware accelerated.
• Commit 1 implements option 2 from llvmpipe is reported as hardware accelerated since 5.4, so software rendering is never detected #879: check GL_RENDERER (llvmpipe, softpipe, software rasterizer) directly, as muffin 5.2 and mutter (d133f94f) do. This no longer depends on the vendor string. The architecture switch stays as a fallback.
• Commit 2 also adds "Mesa/X.org" and "Mesa" to check_mesa_vendor() (option 1 from llvmpipe is reported as hardware accelerated since 5.4, so software rendering is never detected #879, same change as cogl-gpu-info: Recognize newer Mesa GL_VENDOR strings #889), so the cogl architecture info is accurate too. The vendor only selects the architecture table, so hardware drivers are unaffected.

The two commits are independent; either one fixes the detection on current Mesa. This supersedes #889 if you prefer the combined approach.

Fixes #879

Test plan

• The GL_RENDERER matching helper was compiled and checked standalone (llvmpipe, softpipe, "Software Rasterizer", NULL, and Radeon/Intel strings).
• Not built in the full tree here (missing graphene-gobject), so please check CI.
• On a VM without 3D (llvmpipe), Meta.get_backend().is_rendering_hardware_accelerated() should be false and software_rendering true.
• Hardware Intel/AMD/NVIDIA are unaffected.

🤖 Generated with Claude Code

[mtwebster]

You need to figure how to test this stuff yourself. "Ran in xvfb" is not enough either. I can plug the same prompts into claude and come up with the same solutions, probably better because I can provide better context than you. You're not doing anything but spending tokens and dumping it on me to test.

Install a distro you can test on. Learn to build the cinnamon stack. It's not that difficult. Install Ubuntu 26.04 and build cinnamon on it.

You're not the only one doing this but you're generating enough work for us I feel obliged to say something.

Does this one supercede #889 or what?

[KAMI911]

I will find a way to test it on real hardware.

At the moment, I am under considerable time pressure, as we are busy preparing several events dedicated to open-source software and promoting Linux Mint.

These include a retro gaming event [1] and a community-organized Linux Install Fest [2], where we aim to introduce visitors to free and open-source software and encourage them to give Linux Mint a try.

From time to time, we also participate in other events with our own booth, such as SysAdminDay [3] and Fantasy Expo [4]. These are great opportunities to meet people, talk about free software and Linux, demonstrate Linux Mint, and introduce it to new users.

Promoting open-source software and helping people discover Linux is something we are passionate about, but organizing and attending these events also takes a significant amount of time and effort.

[1] https://linuxmint.hu/hir/2026/11/ket-nap-retro-videojatekos-idoutazas-budapesten-es-mi-is-ott-leszunk
[2] https://linuxmint.hu/hir/2026/10/ismerd-meg-a-szabad-szoftvereket-es-vidd-is-oket-haza

[3] https://linuxmint.hu/hir/2025/08/sysadminday-2025-egy-nap-ami-csak-roluk-szolt\

report form last year, but we did it in 2026 too

[4] https://linuxmint.hu/hir/2026/08/linux-mint-es-barataink-a-fantasy-expo-2026-on-gyere-onkentesnek-es-hozz-pendrive-ot-a

[KAMI911]

You can decide whether to use #889 or #892. I created #892 because @Fantu expressed a preference for this approach in this comment.

I'm sorry if I'm creating any extra work for you. I'm simply very enthusiastic about contributing, improving existing solutions, fixing issues, and developing new features. My intention is always to help find the best possible solution.

[Fantu]

LLMs, even though they are called "AI", are not, so the results can vary a lot depending on several factors. First of all, I would recommend having at least some experience with what you are contributing to, so you can guide and correct the LLM better, and always testing. Unfortunately, as mtwebster said, there are too many people without experience who get LLMs to do a lot of things in a short time, but who end up causing mostly wasted time with poor or wrong results.

I have already given some advice to other people and I don't want to spend too much time rewriting everything, so I'll just mention a few things:

• set in the LLM's main instructions and memory that it must state clearly when parts of the result are doubtful, not sufficiently verified, or based only on training data (often outdated), so you know what to check more carefully, even when it looks correct at first glance;
• give it more context, for example upstream and dependency repositories and documentation: in my experience this can change the quality of the output a lot;
• always test, both by having the LLM run tests and by testing manually.

Here is a public post with more information that might be useful: https://bugs.debian.org/1121872#64
It isn't enough to explain everything that's needed, and in any case, as with any tool, you also learn through experience.

[mtwebster]

Went with this instead: f504625

It was an easy backport, and resolves the issue. Also 700 lines of code removed in a follow-up commit (8221e86)