- Mesa is now maintained by Manjaro and won’t ship with patent encumbered codecs .
Do I see this right, that it is not worth to install manjaro on my freshly ordered amd thinkpad ?
1 Like
That’s a very loaded and opinionated question — specifically, your use of the word “worth”. 
Besides, if you have a (slightly) older install image laying around, then you can still install Manjaro with all of those codecs ready-to-use out-of-the-box. And if you don’t, then I’m sure the AUR will offer solace.
The only thing that has changed is that those codecs will no longer be installed by default in a new Manjaro installation.
In a way, you can liken it to Debian, where non-free (as in “freedom”) packages are not installed by default, but whereby the user can always opt to install them later by adding a non-free repository. Mageia has also already long been doing the same thing.
5 Likes
Or Fedora, or openSUSE, based on the articles.
3 Likes
It is a 1500€ question. Is it worth relying on AUR or whatever workaround ?
Up to this day I have, but do not need AUR packages for my system.
Yes, but this is about manjaro, or am I wrong here ?
…up to the next update.
1 Like
No, because Manjaro will not uninstall any codecs you already have on your machine. That would be ridiculous.
1 Like
I already downloaded the latest release review, so I can scratch that . But that is new hardware, and probably needs a new kernel.
Bad timing.
1 Like
Why would it?
1 Like
Your word in god’s ear. I Don’t want to change , I am so used to it. Maybe that is why I am so upset.
1 Like
As the codecs where included in a previous version of an installed package (mesa) and no longer included in present version of said package, the codec support will go away when updating that package.
So yes, older systems will also loose the support, when the Mesa update reaches their branch.
The codecs are only for hardware accelerated decoding on AMD systems though (as far as I’ve read), meaning that video will still play, it will just use the CPU instead of the GPU to do it.
2 Likes
From the linked article:
Before we go on to the problem-solving choices, the users should clearly understand one thing. The removal of Mesa support for H.264, H.265, and VC-1 does not imply that you would be unable to play videos that use any of these codecs.
Of course, these videos will play; however, they will be decoded by the CPU rather than accelerated by your graphics card (GPU).
Also, neither article mentions Manjaro.
…and we have to rely on 3rd party , AUR or pull it from arch repos… a frankenjaro ? This is against all my rules having a clean system.
…it will play better on my 10 years old intel notebook.
So my question still stands, ,does the existence of the manjaro company affect codec support ?
No answer is also an answer.
While @winnie stated it is the same on Fedora or openSUSE (as an excuse,maybe), those and also Debian have their non-free repos.
We are let alone with cryptic excuses. Since two days my fresh ordered thinkpad P16s amd is waiting, and I fear manjaro is no longer a good option .
1 Like
Well, isn’t it obvious yet? 
There is so many distros and so many options I don’t see how what any distro does should be of any concern. Just install whatever serves you best.
Perhaps I fundamentally don’t understand something here
but isn’t openh264 from the normal repos a solution for at least this format?
Or is hardware de/encoding then missing (I don’t think so)?
Intel and Nvidia GPUs use their own hardware-accelerated video decoders for AVC, HEVC, etc.
AMD supposedly relies on mesa for hardware-acceleration of AVC, HEVC, etc.
This means that AMD GPUs will not support hardware-accelerated video decoding for AVC, HEVC, etc, if the version of mesa was compiled without said decoder support. (Fedora, openSUSE, Manjaro, among others?) Thus, such systems will fallback to using the CPU to decode the videos (which is more taxing and can drain more battery for laptop owners.)
1 Like
Thank you very much for that summary!
There more than likely will be a version of mesa with these enabled in the AUR.
I’d not have a problem with that.
I will not have the “problem” anyway, since my hardware is Intel.
I don’t think it’s likely, for two reasons:
- Arch’s repository already has
mesawith support for these decoders, even in their latest staging branch.
So it looks like Arch Linux will continue to support these decoders via mesa (by their very nature of being “as vanilla as possible” in regards to upstream.) CORRECTION: Looks like Arch is straying from upstream in this case. 
Upstream Mesa is disabling support by default.
The mesa package for Manjaro is intentionally compiled without such decoder support.
There are two versions of mesa in play: Arch and Manjaro
- Even if an AUR version is created (to guarantee continued support of these decoders) it would be redundant and possibly introduce breaks in the future if it’s not properly maintained, let alone tested to work with the official repository libraries, dependencies, etc.
Arch Linux users would vehemently oppose such a package in the AUR[1], while Manjaro users would just request their already existing package (in the Manjaro repository) to revert back to how it used to be with full decoder support.
[1] Such a mesa PKGUILD in the AUR would violate their policies. You cannot say it’s a “patched version with extra features” when in fact it’s the exact same version with the exact same features, but you want to submit it for the sake of convenience for Manjaro users.
2 Likes
Why would you want the same PKGBUILD twice anyway? You can download it from arch repo and build that. Or install already built package. If you guys went through so much trouble to have some old 5.24 plasma, this won’t be much of a problem.
Why can’t manjaro not have 2 mesa packages:
- First one is default and does not support patented codecs
- Second one in repos with support for all codecs
As far as I can see, its just a single line difference in pkgbuild, but it would save the effort to recompile for a lot of users, and reduce risk of crashes or bugs with git package and manually compiled packages.
Since the mesa package with codec support is manually installed by user, manjaro is not liable for any of the legal troubles. This would be kind of like what ubuntu does (in terms of making users install the codecs and not including them by default)
4 Likes
excuse my tinkering, but from what i see ATM(important) manjaro in its repo has only custom/overlay build for package ‘mesa’ only out of the entire mesa stack (which is still inherited as is from arch). which makes me think ATM replacing manjaro ‘mesa’ package with arch’s would just work fine, which is very easy.
all this could be very short-lived if more sprodiac changes are introduced in the mesa stack after.