Mesa drivers freeworld and original drivers

Whilst trying to update the system, I’ve come across conflicts, probably related to the fact freeworld packages most likely haven’t been updated yet (very similar to this issue) . If I understand correctly, I should just wait a couple of days for all the repos to get synced?

However, while troubleshooting this, I became unsure whether my initial “swap” of the mesa drivers was done correctly. After the initial install I switched to freeworld packages, following the RPM fusion HOWTO, but only ran the second set of commands for the i686 version of the mesa-va and mesa-vdpau, as I was mostly focused on ensuring Steam would be running correctly. This left a mix of original and freeworld drivers.

After noticing this during the update issue, I figured that I should have probably ran the initial commands as well to swap all of the package versions. Running this deleted the original x86_64 mesa-va-drivers without replacing them with the free world version. I added the package manually and rebooted. Everything seems fine.

Since I’m not that familiar with all of the different GPU drivers and the intricacies of mixing and matching them, I’d just like to double check if my current configuration is reasonable so it doesn’t come back to bite me later :smiley:

Here is the output of dnf list mesa*.As can be seen, mesa-va and mesa-vdpauare freeworld in both i686 and x86_64 versions. Other drivers are from the original repos. Does this seem OK?

Installed packages
mesa-dri-drivers.i686               23.3.1-4.fc39                         @updates               
mesa-dri-drivers.x86_64             23.3.1-4.fc39                         @updates               
mesa-filesystem.i686                23.3.1-4.fc39                         @updates               
mesa-filesystem.x86_64              23.3.1-4.fc39                         @updates               
mesa-libEGL.i686                    23.3.1-4.fc39                         @updates               
mesa-libEGL.x86_64                  23.3.1-4.fc39                         @updates               
mesa-libGL.i686                     23.3.1-4.fc39                         @updates               
mesa-libGL.x86_64                   23.3.1-4.fc39                         @updates               
mesa-libGLU.x86_64                  9.0.3-1.fc39                          @fedora                
mesa-libOSMesa.i686                 23.3.1-4.fc39                         @updates               
mesa-libOSMesa.x86_64               23.3.1-4.fc39                         @updates               
mesa-libgbm.i686                    23.3.1-4.fc39                         @updates               
mesa-libgbm.x86_64                  23.3.1-4.fc39                         @updates               
mesa-libglapi.i686                  23.3.1-4.fc39                         @updates               
mesa-libglapi.x86_64                23.3.1-4.fc39                         @updates               
mesa-libxatracker.x86_64            23.3.1-4.fc39                         @updates               
mesa-va-drivers-freeworld.i686      23.3.1-1.fc39                         @rpmfusion-free-updates
mesa-va-drivers-freeworld.x86_64    23.3.1-1.fc39                         @rpmfusion-free-updates
mesa-vdpau-drivers-freeworld.i686   23.3.1-1.fc39                         @rpmfusion-free-updates
mesa-vdpau-drivers-freeworld.x86_64 23.3.1-1.fc39                         @rpmfusion-free-updates
mesa-vulkan-drivers.i686            23.3.1-4.fc39                         @updates               
mesa-vulkan-drivers.x86_64          23.3.1-4.fc39                         @updates     

Steam pulls in all the needed packages when it is installed from rpmfusion so very little (if any) needs to be done manually. In fact, doing things manually may have a negative effect.

I use steam and have never found a need to change anything that was automatically installed when I installed steam.

As long as you do not experience negative results what you have is probably good.

Do you have Steam installed as an rpm package or as a Flatpack? As Flatpacks bundle their required dependencies while normal packages rely on system libraries - would an application installed via a normal package still be able to pull the required drivers without the swap?

The freeworld drivers offer hardware video acceleration that isn’t available in the core drivers from the standard repo, if I understand correctly. As far as I’ve read, this then affects other applications as well, if they are not installed as Flatpacks.

I installed it as rpm from rpmfusion and things work very well. I have an nvidia gpu, with the nvidia driver from rpmfusion and hardware acceleration works.

I have never tried the flatpak, though some seem to do well with it. I do suggest that you never mix the two different forms.

Yes, you’re definitely better off switching both multilib versions or neither, rather than mixing and matching. I don’t know that it would cause any conflicts in particular, but it’s a less-tested configuration (and kind of nonsensical).

This is correct. mesa-freeworld only contains those two packages. The rest should come from Fedora.

BTW, this is only for hardware support for patented video codecs, and it only applies to AMD GPUs (and possibly nouveau).

Thanks for the clarification. I forgot to mention that I have an AMD processor and GPU, which is why I implemented these swaps initially.

I’ve updated the system but excluded any mesa* packages for now (some would update without conflicts, like the vulcan drivers, but I just thought it best to update either all or none :smile:) . I hope the rpmfusion repos get updated soon… Does it usually take a long time for them to catch up?

In the end, if the sync doesn’t happen soon or if there are any other issues, I can just revert back to the original drivers by inverting the arguments in the dnf swap command? This will restore the original drivers and what I would lose is the ability for hardware acceleration for some video codecs, right?

The package is already built, but RPM Fusion doesn’t use bodhi for updates, so it’s hard to say exactly when it will be published. I don’t expect it will be very long.

And yes, you can swap back, and you’d only lose hardware acceleration for codecs like H.264 and H.265.

Great! Thanks for the information!