Wishlist: modularized mesa, so that non free codecs can be installed via additional (plugin) packages


Nice as it is, Manjaro is most certainly suffering from the relatively recent video codecs debacle. If I understand it correctly, the distro had to take a different path with respect to arch and other arch derivatives disabling video encoding/decoding in mesa for some patent encumbered popular formats while arch & other derivatives can leave it enabled.

I also understand that AMD users are particularly frustrated because of an inconsistent take on video encoding and decoding. While they cannot use their hardware for video encoding/decoding, the usage of patent encumbered codecs remains 100% possible if you use intel, nvidia or software-based codecs, leaving them wonder why only doing encoding/decoding on AMD hardware creates a legal threat to the distribution.

I see that a reaction to the current situation has resulted in the set up of community repo, not connected to Manjaro at nonfree.eu. I have tried that solution and unfortunately found it rather user-unfriendly. Because there is no coordination between that site and Manjaro, when a Manjaro update comes out, that repo is not syncronously updated. As a consequence, due to package dependencies and constraints in the nonfree.eu packages being evidently not appropriately managed, everything can easily break (and the system may remain completely unable to get to the desktop environment). For this reason I think that Manjaro should not “push” users to enable repos that replace the whole of mesa just to get video encoding/decoding. This may also become the source of an endless stream of false positives in the reporting of issues with Manjaro updates.

Finally, I understand (correct me if I am wrong) that the legal problem is with readily usable binaries. Distributing encoders and decoders or entry points for the corresponding functionalities in the hardware in a non-readily-usable form (e.g. source) is OK (indeed this is what the mesa project still does).

From these premises, I wonder if it might be possible to distribute mesa in a modularized way, so that the non-free codecs can be isolated in one or more “plugin” packages containing only them. With this:

  • sites such as non-free.eu would not need to distribute the whole of mesa, but only the packages with the non free codecs. This already would prevent breakage on manjaro updates because at this point it would be simple to make those packages automatically removed as manjaro installs a more modern or anyway version-misaligned mesa. With this the worst that may happen on a Manjaro update is that one remains temporarily without the non-free codecs (i.e. no full system breakage anymore).

  • maybe manjaro itself would be able to ship a non-free-codecs package containing some source code, rather than a readily usable binary, so that on install the source gets compiled. Possibly this would be enough to get in compliance.

Could any of this be feasible, maybe with some coordination with mesa upstream?

You touch upon something that genuinely makes me wonder whether all of this was necessary. But in order to delve into this, we must first distinguish between patents and copyrights.

In the software world, a copyright pertains to code, artwork, logos, branding, et al. A patent on the other hand refers to a way of doing things. So the first thing that needs to be identified is whether we are dealing with software that is deemed non-free because of patents or because of copyrights.

If we are dealing with actual copyrights, then I will bow out now and leave it to the developer team to discuss whether they can implement your suggestion or not. But if we are dealing with patents — which is the term you use in your message above — then I really don’t see the problem with including mesa-nonfree in the official repositories, and here’s why…

Correctly or incorrectly, you posit that Arch is somehow exempt from having to bother with this segregation between the free and non-free versions of mesa. But unless I am mistaken, Arch was created by a US American, while Manjaro was created by Europeans. And while software patents carry legal weight in the USA, the European Union does not recognize software patents.

Therefore, if even Arch doesn’t have to bother, then I don’t see why Manjaro should have to. Unless of course it’s not a matter of patents but of copyrights. Copyrights on software do carry legal weight in Europe, and thus Manjaro must take all action to avoid any litigation regarding copyright infringement.

But if it’s a matter of patents, then Manjaro has nothing to worry about if we include the non-free version of mesa in our repositories.



It’s funny how Arch is actually easier to maintain than Manjaro. :joy:


I thought the distinction between Arch and Manjaro in this matter is that Arch is a non-commercial entity while Manjaro has a commercial division.

1 Like

UPDATE: apparently there is some coordination between Manjaro and nonfree.eu on updates, in the sense that the maintainers of the latter actively monitor Manjaro for update and whenever there is a Manjaro update they try to follow up with it with an update of mesa on nonfree.eu whenever this is necessary. Ideally, this should leave a window of at most a few hours where updating Manjaro can create a misalignment with the mesa packages from nonfree.eu. Evidently I had been unlucky and too hasty when I tried an update with nonfree enabled the last time.

Nonfree is entirely a manjaro project. It is separate to fly below the radar (because of the reasons listed above) and if it can’t and burns, to burn alone without the rest of manjaro. The maintainers are the manjaro developers. But being a “side/addon” project, it has somewhat lower priority and sometimes lags a bit behind with being up to date.

1 Like

Are you shure ?
When i look at mesa-nonfree stable release 23.1.6-3 the list shows mesa 23.1.7-1 (lets forget epoch 1 for a moment).

If this is intended and working fine, why is official mesa-stable-branch still at 23.1.6-3 ?

Furtheron, if someone has no trust in this mess, and is willing to compile mesa 23.1.6-3, and is looking into gitlab mesa branches, what will be found is an outdatet PKGBUILD. One has to fizzle out via commits.

Note that Fedora has exactly the same issues with the non-free version of mesa being supplied by a community repo which sometimes doesn’t update in sync with the main distro. Not sure how openSUSE are handling it right now.

Yeah, it’s a mess, but splitting the non-free codecs into a separate module would be a lot of work, and Manjaro is a tiny player compared to e.g. Red Hat (who contributed this change in the first place). It would require their kind of resources to get this done upstream.

Yup. Patent trolls aren’t going to sue anyone who doesn’t have money.


I highly doubt there is any difference in redistributing codecs in this regard. Anyway, even if it is, it makes it even funnier.

Manjaro users get everything from Arch repo basically, but because $$$, they get rebuilt mesa and have to jump through additional hoops to get the same user experience.
Combining this with inexperienced users Manjaro likes to attract, this seems a bit counterintuitive, to say it lightly.

I had forgotten all about this, since I was an Nvidia user until yesterday.
Guess it’s time to build my own mesa, with Blackjack and -D video-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc.