Upstream mesa removal of AVC/HEVC/VC-1 hardware acceleration (AMD GPUs)

Soft-flushed, but still far too cheap. A disappointment.

Can anyone imagine a more elegant way to pull the necessary mesa files from the official Arch repository, instead of fetching package after package?

EDIT: In case you reached here thanks to your search engine of choice, I wrote a python script that manages to do that in an unattended way. I’m calling it MESA Unattended Recovery (MUR) and it is provided as is.

EDIT: Omitted unnecessary bash verbose.

Yes. First step is to download archlinux iso image. :smiley:

6 Likes

Yes, sounds a bit weired but you can use the downgrade tool to do this
Identify wich mesa and vulkan packages are installed on your system:

pacman -Q | grep mesa
pacman -Q | grep vulkan

upgrade all mesa and vulkan packages with downgrade:

sudo downgrade mesa mesa-* vulkan-*

hint:
needs to be the explicite package name (replace *) from first 2 commands.
And you have to re doing this step after a system upgrade so simply grep the last command again after system upgrade.

3 Likes

Nice :+1: I have to test this - later

EDIT

For anyone interested in building mesa with h2xx - I have fidlled the pkgbuild to build oob on Manajro - my pkgbuild is at wonky/mesa-with-h2xx - mesa-with-h2xx - Codeberg.org

The result can be fetched from Index of /mesa-h2xx a tar.gz’d archive of all packages.

3 Likes

this line is simply removed on our end as it is the part of code switch which defines if that software part is enabled for given codecs or not to get hardware acceleration possible for AMDGPU and other drivers using mesa to achieve that.

Many developers did a research, sponsored by Red Hat, to get to the point on how to move forward legally. Freedesktop-sdk used by flatpak also disables the codecs by default. However for some software developers this might reduce the appeal of Linux in general as discussed here. So they introduced the “extra” release. This approach should allow distributors and users to make use of the appropriate extension given their legal position. So they go for: I provide you the Lego-Bricks and you decide how to build with them.

Red Hat decided not to distribute such an option at all. You can install mesa-freeworld from RPM-Fusion, which is not accessioned with Red Hat company at all. As Fedora is officially affiliated with Red Hat, Inc. in the Fedora Project, Fedora is effectively bound by the same legal restrictions as Red Hat, as a US company, is bound by. This means in particular that software encumbered with US patents cannot be included in Fedora.

Now you may say: Hey Manjaro is a German company so by EU laws software patents you should give a fish about it, right? Well there are plenty of fish in the sea and Germany sadly applies to US patents somehow by our laws. France would be a country which don’t give a fish about software patents. Creating a legal entity just for that would be a little too much. So ya license fees are always something, even if you use alternatives: Royalty-free codec still needed despite no-cost h264 license | Ars Technica

6 Likes

So why don’t you care about the other infringing packages?

1 Like

what packages are those?

intel-media-driver, libva-intel-driver, intel-media-sdk and nvidia-utils are in the Manjaro repos. They use hardware video acceleration.

3 Likes

In addition to the drivers mentioned above, all h264 and h265 encoding and decoding requires a license. This means software implementations too.

Take a look in Fedora’s repository, do you see x264 or x265? They are in RPM Fusion. They have OpenH264, but it isn’t even hosted on their servers, it must come from Cisco since they pay the license fees. Their FFmpeg build is even stripped and patched. They sorted all of that out years ago, the Mesa thing was just previously overlooked.

Ubuntu has all of this in “community maintained” repositories that are disabled by default, seems to keep the lawyers happy enough. It is just a checkbox to enable the Universe and Multiverse repositories. It shouldn’t be difficult for you to take this approach.

1 Like

Unfortunately there no way around it without paying for them this is not about how hard is to implement it but it has to do with the legal aspect of it, as much as I would like to have them we cannot, if the company is not liable then the person ho ships them to the public is, personally that is not a risk I want to take, and is not a risk any of team should take. People are unhappy I am also.

3 Likes

It’s like two parties are talking, each in its own dimension. :joy:

I would also like to congratulate Manjaro on 100 posts without an answer.

2 Likes

Why should they, when you’ve given the answer.

The current solution is still unsatisfactory. What we actually need is an automated implementation.
Maybe a script on github/gitlab, requested by the user himself.
I have now for the second time mesa self-built, I do not think that I like it in the long run.

1 Like

Hello Manjaro,

First, thank you for the work you do providing this distribution. I’m not an experienced Linux user ; Manjaro has been my first real Linux daily driver for a little bit. However, I’d like to share my perspective on the subject, if you bear with me.

I understand that for very valid legal reasons, GPU accelerated decoding of some codecs has been dropped out. Installing another mesa from Aur seems to me to be a poor solution, because it is a risk of unforeseen complications with things breaking.

It matters to me because I choose my hardware avoiding nvidia for gpu, precisely because they are not cooperative in the opensource space ; they have made my previous machine unable to run stable in Linux and because they’re known for being closed source trolls. So, I have an amd cpu, and an amd gpu, bought in the idea that hardware could be better supported in Linux, and I stopped relying on closed source drivers.

Perhaps one better suited way around this unsatisfactory outcome would be to have an extra community package available to restore the lost capabilities, where you could put the bits that you can’t ship in the default distribution.

I think many distributions have this problem solved in a very similar way - providing what’s necessary through an optional package - so it should be ok legally.

EDIT. : if even distribution of an optional community package puts too much liability risk on Manjaro, perhaps an Aur package that won’t ever break, customized for Manjaro, that will not imply downgrade or future special problems. There has to be a reasonable and simpler way than the current solution…

You’re not familiar with the AUR, are you? This is unacceptable, the AUR is ARCH User Repository, not MANJARO User Repository. This will be wiped in a minute there.

You are right, I’m not very familiar with many things in Linux, and what you say makes sense. It should be in Manjaro community packages.

Great idea. And while at it, make every package like that. I don’t understand why this hasn’t been done already.

Manjaro is ~94% same as arch. And I mean literally.

Well, there are some manjaro specific packages there, so they aren’t so strict I guess.


Point is none of this has anything to do with this topic. :stuck_out_tongue:

They don’t know about it then (or the uploader has his entries into some Arch circles). I have seen packages not distribution specific being removed because… still don’t know to this day…

indeed.

here the same problem. If I have to install outside official repos something so importand and used like libva to use some codecs I would probably leave manjaro … unless this is something everyone goes to do…
I hope it’s not because it’s a ■■■■ that at the end, with firefox shiping vaapi h264 decoding you are droping this. It’s like shooting in your foot

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.