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

Possibly - if it is documented that it is Manjaro maintainers which are doing so willfully

Because upstream disabled the usage - and thus made it known downstream - that there is a problem.

If you continue despite knowing better then it is against better knowledge - and then it is a problem.

Please read my comment above more closely.

A good solution would be to provide two versions of mesa - the one without acceleration support would be installed by default, and the user could decide for himself which version he wants to use.

You have that - it is called mesa-git - it is a DIY - which you likely do with other functionality you require.

Please read my comment above more closely.

The problem does not apply to me personally, because I have an intel card, but mesa-git is with AUR, and I am concerned that there is no precompiled package in the Manjaro repository.

1 Like

The messaging is giving me mixed signals, as alluded by others earlier.

We’re told the AUR is not officially supported, but then we’re also being pointed to the AUR to resolve a very important deal-breaker for AMD GPU users.


It’s one thing to say “The AUR is not officially supported, but if you want to use an application that has XYZ features, check out blahblah-bin from the AUR.”

It’s another thing to say “In order to keep using your computer normally, and to leverage your hardware’s acceleration, switch to the AUR for these important system packages.” :cold_sweat:


Can you imagine if an official package removes AES hardware acceleration, which brings LUKS encrypted systems to a sluggish performance, but then you’re told you should build and install the kernel package linux62-aes from the AUR?


I would 100% switch to Endeavor or Arch at that point. I’m not an AMD GPU user (Nvidia and Intel myself), so I’m luckily not affected by these recent changes.


EDIT: I’ll be the first to admit that the thread title might not be well suited for the discussion. :laughing:

It reminds me of the loaded question: “Do you still beat your wife?”

Perhaps a more apt thread titled would be:

Discussion about Manjaro’s removal of AVC/HEVC/VC-1 hardware acceleration in Mesa (AMD GPUs)

1 Like

I didn’t want to hear about the legal stuff again, I get it, but this is not the point.

Whatever. Continue on the good decision making path, the good communication, the will to provide users with viable solution (and of course telling them to do something you also told them not to do in the process, talking about AUR here), this is great! I’m sure it is making Manjaro more popular!! And no one will use this debacle you poorly try to avoid to :poop: on Manjaro more than they already do, suuuuuurrreee.

Keep on keeping on!

i’m not new, it’s all done (better, faster, easier). I have my codecs with mesa 22.2.4-1 , but this is not about me.
It’s the way the issue is handled (dead-swept, sat out).
What should the many new users think, first demonize third-party and the AUR (I just remember the pamac disaster), and now refer to it.

Good point - I changed to topic title to reflect.

Slightly adjuste - because Manjaro is not the only distribution but one in a list.

https://mesa.freedesktop.org/


And it is not - yet Pamac support building packages from AUR - originally per request from the community to simplify the amount of utilities.

And yet the AUR scripts is so popular because they enable functionality you could not have so easily otherwise - e.g. google-chrome and xcode.

There has been a heap of AUR helpers over time - some better than others - that doesn’t make AUR supported.

Don’t make this about the option everyone use - even it is unsuopported - in the sense your build you fix it.

I understand that some is frustrated - even annoyed - but that doesn’t change a fact.

sudo pacman-mirrors -aS unstable
sudo pacman -Syyu
pamac build mesa-something

Pick yours from 41 different scripts

Or build from Arch recipe

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