Closed DarkArc closed 1 year ago
At the risk of starting a wave of spam on this topic; I wish to express my support for a mesa-full
package.
But where do I come from? Well, for start I'm a Flahub contributor, where I help with CD-rippers and converters. I also maintain a select list of productivity software, and many of the classical Id Software titles.. Besides, I'm a contributor to Fedora Magazine. I've written such beautiful works as "Restarting and Offline Updates" and "Gaming on Fedora".
This last article I wrote about a year ago, when Fedora was really in a great position; Many pieces were falling together, there was enthusiasm in the market, and Linux was going through a wave of press coverage (Thanks Valve and LTTT). But the article also had an interesting problem: It was flying really close to the sun because everything written in it is in the presumption that the user enables RPM Fusion. I could never say so outright, and I chatted with the team behind-the-scenes to find the perfect balance.* Long story short; RPM Fusion is a core of the whole Fedora Desktop experience and as an author I've tried to promote it as much as possible.
That's also why I think it's very important to have an RPM-Fusion edition of the mesa driver stack. I would never ask somebody to do work that I myself would not be willing to do, and I hope that I don't come of as some random person voicing his frustrations. RPM Fusion is an integral part of the thing that makes Fedora worthwhile, and I hope that you have the time and resources to embrace a mesa-full
package.
Honestly, if I had the time I would gladly contribute, but In the past three years i mostly focused on Flatpaks so I know little about packaging with RPM, Mock, and the whole Fedora stack. Therefore, allow me to ask first, before I embark on another 3-year journey learning all the ins and outs of a packaging format.
* It did also prompt the whole discussion about Flathub and that pit of legal snakes. In that case, everything worked out and Flathub is now cleared from any legal hurdles. How much one article can do.
I can't read such "literacy", but to sum-up: anyone is free to contribute to RPM Fusion with a mesa-freeworld package. See also https://rpmfusion.org/Contributors I'm personally not interested in it, myself.
But even more relevant would be a solution that would ask mesa upstream to be able to provide vaapi-backends as a separate dlopenable shared objects instead of building a full mesa package IMO.
As I understand, only AMD users are concerned by this change as Intel users are using a separate userspace backend. Nouveau users aren't relevant as they lack proper firmware support.
But even more relevant would be a solution that would ask mesa upstream to be able to provide vaapi-backends as a separate dlopenable shared objects instead of building a full mesa package IMO.
We can't provide the full mesa package anyway as it would conflict with fedora mesa. I don't think we need to provide the full package, maybe just replacement *_drv_video.so
$ rpm -ql mesa-dri-drivers-22.2.0-3.fc37.x86_64 |grep drv_video.so
/usr/lib64/dri/nouveau_drv_video.so
/usr/lib64/dri/r600_drv_video.so
/usr/lib64/dri/radeonsi_drv_video.so
Also I don't think nouveau worth to be enabled, so only having radeonsi/r600 can make it (for x86_64 and eventually aarch64).
Edit: and i686 !
Does nouveau not have decode support for 9xx cards and h264 -- that sounds like the right vintage where that would still be relevant?
Does nouveau not have decode support for 9xx cards and h264 -- that sounds like the right vintage where that would still be relevant?
Right, but then that support is more than buggy. (understand, the bugs could be in the outdated firmware).
Fair enough
Some additional information:
Intel video driver is already handled by rpmfusion.
rpm -qf /usr/lib64/dri/i965_drv_video.so
shows libva-intel-driver-2.4.1-8.fc36.x86_64
, which is already in rpmfusion-free.
However i965 video driver file is not shipped by the mesa-dri-drivers
package as well.
The current way of avoiding overwriting video driver files from mesa-dri-drivers
is to set LIBVA_DRIVERS_PATH
environment variable to override the search path.
I would like to repeat @kwizart's point on the IRC regarding https://github.com/rpmfusion/ffmpeg/pull/3 for a complement solution. It seems to be a split out of the relevant freeworld libraries into a separate (new) sub-package which ensures via library loading to be preferred over the Fedora package (if I get it correct).
As I understand, only AMD users are concerned by this change as Intel users are using a separate userspace backend. Nouveau users aren't relevant as they lack proper firmware support.
Wouldn't this also affect Raspberry Pi 4/00's? The effect there might be more significant given the less powerful CPU to fall back on. I imagine Fedora Mobility initiative might be similarly impacted as well.
I just want to leave a comment hoping that, however it's implemented, a one click Fedy solution is found and would be very much appreciated.
How would this interact with secure boot?
Secure Boot shouldn't affect this since these aren't kernel modules, but user-space drivers.
Ah I was wondering if this would cause the whole mess with nvidia
As I understand, only AMD users are concerned by this change as Intel users are using a separate userspace backend. Nouveau users aren't relevant as they lack proper firmware support.
Wouldn't this also affect Raspberry Pi 4/00's? The effect there might be more significant given the less powerful CPU to fall back on. I imagine Fedora Mobility initiative might be similarly impacted as well.
IIRC the v3d
drivers don't yet support video decoding, so it would be an issue anyways. I also think they were using the proprietary Broadcom drivers previously, before v3d
came into the picture? Could be wrong on that last part.
This comment is just for googleability, not strictly related to fedy
but to help anyone who sees this
Here is a solution that works on Fedora 37.
First, set up RPM Fusion repos:
sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
# nonfree repository is not needed, you can skip this command
sudo dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
Then install mesa-va-drivers-freeworld
and mesa-vdpau-drivers-freeworld
sudo dnf install mesa-va-drivers-freeworld mesa-vdpau-drivers-freeworld
Alternatively, if mesa-va-drivers
or mesa-vdpau-drivers
are already installed, use swap
instead:
sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld
sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld
Optional: Installing additional non-hardware codecs
sudo dnf groupupdate multimedia --setop="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin
sudo dnf groupupdate sound-and-video
sudo dnf install @multimedia @sound-and-video ffmpeg-libs gstreamer1-plugins-{bad-\*,good-\*,base} gstreamer1-plugin-openh264 gstreamer1-libav lame\*
flatpak install flathub org.freedesktop.Platform.ffmpeg-full
Here's a little FYI for Fedora Silverblue 37 users.
This is what I did to make the totem-video-thumbnailer
work for my videos on AMD hardware:
1) Set up RPM Fusion repos:
sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
2) Swap the mesa-va-drivers
with mesa-va-drivers-freeworld
:
rpm-ostree override remove mesa-va-drivers --install mesa-va-drivers-freeworld
3) Install additional packages:
rpm-ostree install gstreamer1-plugin-libav gstreamer1-plugins-bad-free-extras gstreamer1-plugins-bad-freeworld gstreamer1-plugins-ugly gstreamer1-vaapi
I've created a dedicated page for OSTree at https://rpmfusion.org/Howto/OSTree Also updated
As fedy is concerned, we should still be able to add a swap module for mesa...
This comment is just for googleability, not strictly related to
fedy
but to help anyone who sees thisHere is a solution that works on Fedora 37.
First, set up RPM Fusion repos:
sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm # nonfree repository is not needed, you can skip this command sudo dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
Then install
mesa-va-drivers-freeworld
andmesa-vdpau-drivers-freeworld
sudo dnf install mesa-va-drivers-freeworld mesa-vdpau-drivers-freeworld
Alternatively, if
mesa-va-drivers
ormesa-vdpau-drivers
are already installed, useswap
instead:sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld
Optional: Installing additional non-hardware codecs
sudo dnf groupupdate multimedia --setop="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin sudo dnf groupupdate sound-and-video sudo dnf install @multimedia @sound-and-video ffmpeg-libs gstreamer1-plugins-{bad-\*,good-\*,base} gstreamer1-plugin-openh264 gstreamer1-libav lame\* flatpak install flathub org.freedesktop.Platform.ffmpeg-full
Just to add to this, folks may want to also exclude mesa-va-drivers
explicitly in their /etc/dnf/dnf.conf
file as well. I just had my mesa driver update error out until I did so because it couldn't install this package due to the conflict with the freeworld packages. You can also manually exclude the package in an update command by appending --exclude=mesa-va-drivers
to the dnf update command.
Just to add to this, folks may want to also exclude
mesa-va-drivers
explicitly in their/etc/dnf/dnf.conf
file as well. I just had my mesa driver update error out until I did so because it couldn't install this package due to the conflict with the freeworld packages. You can also manually exclude the package in an update command by appending--exclude=mesa-va-drivers
to the dnf update command.
That shouldn't be necessary at all (and could cause you headaches down the road -- it's a big red flag you've done something wrong as well). If you use the swap command as the other commenter (that you're quoting) stated, the meas-va-drivers
package should be uninstalled and replaced by the freeworld package.
Hey, I did the swap but the latest mesa update keep asking me to upgrade mesa-va-drivers package, did I miss something ?
De : Wyatt Childers @.> Envoyé : Tuesday, January 3, 2023 4:19:14 PM À : rpmfusion-infra/fedy @.> Cc : Gregory Duhamel @.>; Manual @.> Objet : Re: [rpmfusion-infra/fedy] [Fedora 37] Mesa w/ h264, h265, and vc1 decoding support (Issue #110)
Just to add to this, folks may want to also exclude mesa-va-drivers explicitly in their /etc/dnf/dnf.conf file as well. I just had my mesa driver update error out until I did so because it couldn't install this package due to the conflict with the freeworld packages. You can also manually exclude the package in an update command by appending --exclude=mesa-va-drivers to the dnf update command.
That shouldn't be necessary at all (and could cause you headaches down the road). If you use the swap command as the other commenter (that you're quoting) stated, the meas-va-drivers package should be uninstalled and replaced by the freeworld package.
— Reply to this email directly, view it on GitHubhttps://github.com/rpmfusion-infra/fedy/issues/110#issuecomment-1369890022, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABBHXXFWLEBMLQEHO4UXTCDWQQ7PFANCNFSM6AAAAAAQXKGPTI. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hey, I did the swap but the latest mesa update keep asking me to upgrade mesa-va-drivers package, did I miss something ?
@GregDuhamel @JustPlainGarak the latest sudo dnf update --refresh -y
goes through without fanfare for me (as it should for you). If you're having this problem, dnf
should tell you what package is trying to require mesa-va-drivers
, which is important information. It's possible you have something -- somewhat obscure -- that's explicitly requiring mesa-va-drivers
.
what happens is that on the update repository we now have:
Available Packages
mesa-va-drivers.i686 22.3.2-1.fc37 updates
mesa-va-drivers.x86_64 22.3.2-1.fc37 updates
whereas on @rpmfusion-free-updates is still at:
mesa-va-drivers-freeworld.i686 22.3.1-1.fc37 @rpmfusion-free-updates
mesa-va-drivers-freeworld.x86_64 22.3.1-1.fc37 @rpmfusion-free-updates
thus, doing an dnf upgrade
pulls in mesa-va-drivers
as weak dependencies:
============================================================================================================================================================
Paket Architektur Version Paketquelle Größe
============================================================================================================================================================
Updates:
mesa-dri-drivers i686 22.3.2-1.fc37 updates 18 M
mesa-dri-drivers x86_64 22.3.2-1.fc37 updates 17 M
mesa-filesystem i686 22.3.2-1.fc37 updates 18 k
mesa-filesystem x86_64 22.3.2-1.fc37 updates 18 k
mesa-libEGL i686 22.3.2-1.fc37 updates 142 k
mesa-libEGL x86_64 22.3.2-1.fc37 updates 131 k
mesa-libEGL-devel x86_64 22.3.2-1.fc37 updates 21 k
mesa-libGL i686 22.3.2-1.fc37 updates 187 k
mesa-libGL x86_64 22.3.2-1.fc37 updates 176 k
mesa-libGL-devel x86_64 22.3.2-1.fc37 updates 35 k
mesa-libOSMesa i686 22.3.2-1.fc37 updates 3.4 M
mesa-libOSMesa x86_64 22.3.2-1.fc37 updates 3.2 M
mesa-libgbm i686 22.3.2-1.fc37 updates 47 k
mesa-libgbm x86_64 22.3.2-1.fc37 updates 45 k
mesa-libglapi i686 22.3.2-1.fc37 updates 55 k
mesa-libglapi x86_64 22.3.2-1.fc37 updates 57 k
mesa-vulkan-drivers i686 22.3.2-1.fc37 updates 8.1 M
mesa-vulkan-drivers x86_64 22.3.2-1.fc37 updates 7.5 M
weak dependencies will be installed:
mesa-va-drivers i686 22.3.2-1.fc37 updates 3.6 M
mesa-va-drivers x86_64 22.3.2-1.fc37 updates 3.4 M
The right answer is to wait for mesa-va-drivers-freeworld
to be of version 22.3.2-1.fc37
as well. Same for mesa-vdpau-drivers-freeworld
Oh nevermind, when i attempt it the first time the two packages (freeworld) from RPM Fusion where not there and so one of the package tried to pull mesa-va-drivers.
It's ok now, thanks for your answer !
On mar., janv. 3 2023 at 08:09:30 -0800, Wyatt Childers @.***> wrote:
Hey, I did the swap but the latest mesa update keep asking me to upgrade mesa-va-drivers package, did I miss something ?
@GregDuhamel https://github.com/GregDuhamel @JustPlainGarak https://github.com/JustPlainGarak the latest sudo dnf update --refresh -y goes through without fanfare for me (as it should for you). If you're having this problem, dnf should tell you what package is trying to require mesa-va-drivers, which is important information. It's possible you have something -- somewhat obscure -- that's explicitly requiring mesa-va-drivers.
— Reply to this email directly, view it on GitHub https://github.com/rpmfusion-infra/fedy/issues/110#issuecomment-1369949566, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBHXXHEYR3OIANCEYC7ZVDWQRFLVANCNFSM6AAAAAAQXKGPTI. You are receiving this because you were mentioned.Message ID: @.***>
Error: Transaction test error: file /usr/lib64/dri/nouveau_drv_video.so from install of mesa-va-drivers-freeworld-22.3.3-2.fc38.1.x86_64 conflicts with file from package mesa-va-drivers-22.3.3-3.fc38.x86_64 file /usr/lib64/dri/r600_drv_video.so from install of mesa-va-drivers-freeworld-22.3.3-2.fc38.1.x86_64 conflicts with file from package mesa-va-drivers-22.3.3-3.fc38.x86_64 file /usr/lib64/dri/radeonsi_drv_video.so from install of mesa-va-drivers-freeworld-22.3.3-2.fc38.1.x86_64 conflicts with file from package mesa-va-drivers-22.3.3-3.fc38.x86_64 file /usr/lib64/dri/virtio_gpu_drv_video.so from install of mesa-va-drivers-freeworld-22.3.3-2.fc38.1.x86_64 conflicts with file from package mesa-va-drivers-22.3.3-3.fc38.x86_64
Fixed by removing mesa-va-drivers then installing mesa-va-drivers-freeworld and mesa-va-drivers-freeworld.i686.
I guess it needs mesa-freeworld. I will wait until it get to stable.
vainfo Trying display: wayland libva info: VA-API version 1.17.0 libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so libva info: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit
Please describe why this package is not eligible for Fedora ?
Mesa is eligible in Fedora, however recent changes in the ecosystem have prompted Fedora to remove accelerated support for h264, h265, and vc1.
Is this software redistributable ?
Yes
Is this software an alternate version of a Fedora provided package ?
Yes, see above.
Additional context
An exact copy of the Fedora RPM spec but with
-Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec
included seems like the "ideal solution" here.