Nvidia proprietary and open source kernel modules

With the latest bunch of updates to the Nvidia and Multimedia repositories, I’ve added the ability to switch to the two implementations of the kernel modules currently available in the Nvidia driver for Linux.

Since almost a year, the Nvidia driver ships with two different implementations of the kernel modules, one proprietary and one open source. The open source one as of drivers 545.x is now considered beta quality also for the workstations, so it seems a good moment to start shipping it.

The open source one is supposed to be the only one that will be kept in the future, but at the moment both are available and both differ in terms of functionality. You can read about the main differences in terms of functionality and what chips they support in the official documentation.

I did not want to introduce another variation of the kernel modules beside akmods, kABI and DKMS, this would have created even more confusion and lots of dependencies in the SPEC files for the variations. The new akmod and DKMS packages ship both sources (MIT/GPL and proprietary kernel modules) and allow you to switch between one or the other through a configuration file.

Considering that in the long run only the open source variant will remain, I wanted to make this as transparent as possible for the users. Basically, if you don’t care and just want something that works, nothing has changed for you.

The two sources get referenced as they are referenced inside the Nvidia run file, namely “kernel” for the original proprietary kernel modules and “kernel-open” for the new open source variation.

The following instructions show you how to switch between one implementation or the other.

DKMS

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

Change the type of modules you want to use and trigger a rebuild and a reinstall:

# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# dkms build -m nvidia/545.29.02 --force
# dkms install -m nvidia/545.29.02 --force

Now check again the license and you should see that it has changed to MIT/GPL:

# modinfo -l nvidia
Dual MIT/GPL
# reboot

To switch back, change the configuration again and then trigger the same process for rebuilding installing:

# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# dkms build -m nvidia/545.29.02 --force
# dkms install -m nvidia/545.29.02 --force
# reboot

akmods

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

Change the type of modules you want to use and trigger a rebuild and a reinstall:

# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# akmods --rebuild

Now check again the license and you should see that it has changed to MIT/GPL:

# modinfo -l nvidia
Dual MIT/GPL
# reboot

To switch back, change the configuration again and then trigger the same process for rebuilding installing:

# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# akmods --rebuild
# reboot

Xbox Series X|S Wireless controller in Fedora/Steam

I recently had to replace a chep quality Xbox-like controller with a proper one, so I decided to get an Xbox controller. This gives me the proper experience in Steam and games which support Xbox controllers in the various configuration options.

I’ve decided to purchase an Xbox Series X|S Wireless controller, which is USB / USB-C or BLE (Bluetooth Low Energy). No issues with USB, the controller is recognized properly, including vibration, but to get it working via Bluetooth it requires a bit of extra software.

image

So here are the packages and how to connect it.

USB / USB-C connection

Just plug it in, it will instantly be recognized. Nothing else to do in this case.

usb 1-3: new full-speed USB device number 12 using xhci_hcd
usb 1-3: New USB device found, idVendor=045e, idProduct=0b12, bcdDevice= 5.07
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3: Product: Controller
usb 1-3: Manufacturer: Microsoft
usb 1-3: SerialNumber: 3039373133333431323636313230
input: Generic X-Box pad as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/input/input31
usb 1-3: USB disconnect, device number 12

Bluetooth Low Energy connection

Requirements:

  • An up to date 5.13 kernel (already available in Fedora updates)
  • A Bluetooth Low Energy adapter in your system
  • Updated firmware on the controller (5.7 at the time of writing this)
  • Packaged xpadneo software

Firmware update

First of all, make sure your firmware is up to date on the device. Before updating the firmware, I had some issues with Bluetooth constantly cycling with pairing. To update the firmware, unfortunately you have to use a Windows system.

Install the Xbox Accessories app, plug in the controller and follow the wizard to update the controller.

If you already attempted to pair the controller without updating the firmware and then you try again with the new firmware, you might have issues pairing. To fix this, delete all cache files of the Bluetooth stack in Fedora before attempting the connection again:

find /var/lib/bluetooth/ -name cache -exec rm -fr {} \;

Bluetooth Low Energy Adapter

Just run this command, if it shows the setting “le” then it means you have Low Energy support:

$ btmgmt info
Index list with 1 item
hci0:	Primary controller
	addr 00:0A:CD:3B:E0:A5 version 6 manufacturer 10 class 0x7c0104
	supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy static-addr phy-configuration 
	current settings: powered connectable discoverable ssp br/edr le secure-conn 
	name workstation.localdomain
	short name 

Packaged xpadneo software

The necessary packages are both in the Steam repository and the Multimedia repository.

Execute one of the following commands to install the appropriate packages.

With akmod:

# dnf -y install akmod-xpadneo
# akmods --force

With DKMS:

# dnf -y install dkms-xpadneo
# dkms build -m xpadneo/0.9.1 
# dkms install -m xpadneo/0.9.1

If you don’t want to trigger the builds manually you can just reboot the system, both DKMS and akmods will take care of rebuilding the necessary kernel modules.

Checking that everything works in BLE mode

Open the GNOME Bluetooth settings, then:

  • Keep the wireless button on the controller pressed for a few seconds until the Xbox logo blinks fast
  • Click on the Xbox Wireless Controller - Not set up entry

After pairing, you will see the following entry in the Bluetooth settings panel:

xbox-bt-paired

And in the Power settings panel you can also see the battery status:

xbox-bt-battery

Finally, in the kernel messages you should see a message like the following:

xpadneo 0005:045E:0B13.0004: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x02E0)
xpadneo 0005:045E:0B13.0004: working around wrong SDL2 mappings (changed version from 0x00000507 to 0x00000903)
xpadneo 0005:045E:0B13.0004: report descriptor size: 283 bytes
xpadneo 0005:045E:0B13.0004: fixing up Rx axis
xpadneo 0005:045E:0B13.0004: fixing up Ry axis
xpadneo 0005:045E:0B13.0004: fixing up Z axis
xpadneo 0005:045E:0B13.0004: fixing up Rz axis
xpadneo 0005:045E:0B13.0004: fixing up button mapping
xpadneo 0005:045E:0B13.0004: enabling compliance with Linux Gamepad Specification
input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.0004/input/input32
xpadneo 0005:045E:0B13.0004: input,hidraw2: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on 00:0a:cd:3b:e0:a5
xpadneo 0005:045E:0B13.0004: controller quirks: 0x00000050
xpadneo 0005:045E:0B13.0004: Xbox Wireless Controller [f4:6a:d7:72:3c:ef] connected

If everything is good, then let’s check how Steam reports the controller:

xbox-bt-steam-bp

Voilá, you have an Xbox controller running over Bluetooth LE without any extra dongle.

Powering on / off the controller

After a bit of time without using the controller, it will turn off on its own. To bring it up again and quickly re-pair it, just press the Xbox logo on it.

Wayland/modesetting on Nvidia

With the latest Nvidia drivers it seems that modesetting and Wayland work fine for Gnome and GDM.

Console text is still a normal console, but upon boot you get the native screen resolution in Plymouth and then you can login under both X.org and Wayland sessions.

Screenshot-from-2020-07-11-08-06-56

How to test? Make sure that you have the following line enabled for the nvidia-drm module:

# cat /usr/lib/modprobe.d/nvidia.conf | grep drm
options nvidia-drm modeset=1

And then make sure to comment out the following line in the udev rules supplied by GDM:

# cat /usr/lib/udev/rules.d/61-gdm.rules | grep -i nvidia
# disable Wayland when using the proprietary nvidia driver
#DRIVER=="nvidia", RUN+="/usr/libexec/gdm-disable-wayland"

Then reboot, and you will login with a Wayland session by default:

# cat /sys/module/nvidia_drm/parameters/modeset 
Y
# cat /sys/module/nvidia_drm/version 
450.57
$ lsmod | grep nvidia
nvidia_drm             57344  4
nvidia_modeset       1187840  3 nvidia_drm
nvidia_uvm           1130496  0
nvidia              19726336  208 nvidia_uvm,nvidia_modeset
drm_kms_helper        249856  1 nvidia_drm
drm                   618496  7 drm_kms_helper,nvidia_drm
$ env | grep XDG_SESSION_TYPE
XDG_SESSION_TYPE=wayland
$ lspci | grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1)

Sonarr, Lidarr, Radarr, Tautulli and Spotifyd packages for Fedora

I now have a new Plex server with lots of storage in a new small cube form factor, so it was now time to automate things a bit more and put the box to proper use.

Now in the multimedia repository you can now find Sonarr, Radarr, Lidarr and Tautulli. This allows you to populate and maintain automatically your TV Shows, Movies and Music libraries without effort. Tautulli is not particularly useful if you are not hosting Plex for third parties, but gives you anyway statistics and information in a nice GUI for consumption and also notifies you any time one of the other tools adds something to a library.

Now I can see how many times my kid has watched the Super Wings! TV show (a ridiculous amount of times, if you are interested):

The packages are built from the upstream releases. Being Sonarr, Radarr and Lidarr built on different Mono versions and requiring a different minimum version, I assembled the packages from their Mono binaries tarballs. The plan is to make all of these available also for CentOS, so packaging needs to be relaxed. Tautulli as well bundles a lot of specific Python dependencies.

All of them come with proper System units and Firewalld rule definitions. So should be a breeze to enable them on the system.

$ rpm -ql sonarr radarr lidarr tautulli | grep -E 'systemd|firewalld'
/usr/lib/firewalld/services/sonarr.xml
/usr/lib/systemd/system/sonarr.service
/usr/lib/firewalld/services/radarr.xml
/usr/lib/systemd/system/radarr.service
/usr/lib/firewalld/services/lidarr.xml
/usr/lib/systemd/system/lidarr.service
/usr/lib/firewalld/services/tautulli.xml
/usr/lib/systemd/system/tautulli.service

Along with those, there is also Spotifyd, which allows you to turn any system into a Spotify client and/or Spotify Connect speaker. Without any configuration file it just works like a WiFi speaker support Spotify Connect, with a configuration file that contains a Spotify Premium username and password you have a fully connected client that you can control with the Spotify phone app like any other client.

If the Plex server is always on and close to a set of speakers, why not use it also as a WiFi speaker? Would also be nice to have Google Cast support; so my family could also use it for listenting to Plex hosted music, but unfortunately Google locked out all APIs for casting and no open source implementation exists (as far as I know).

For example:

This list comes from my phone, and I’m in the same network of the laptop. Everything else is signed in with my account or has been playing something when I was close by, so it’s still logged in.

Also Spotifyd will eventually be available for CentOS/RHEL even if it does not have any Rust packages. The version currently in the repositories is built to also support PulseAudio as a backend, as the plan is to run this on a fully fledged Fedora/CentOS/RHEL system. The binary release offered on the Github project is built with only Alsa as a backend as it requires a considerable less amount of libraries as dependencies; making it suitable for running on a barebone Raspberry Pi.

HandBrake FFmpeg, no more Nvidia 32 bit drivers

HandBrake has been updated again to track the master branch, as it now uses FFMpeg 4 and no longer libAV 12. This could probably lead to other improvements, like NVENC/CUDA support, more formats, etc.

Starting with the Nvidia drivers version 396.24 there will be no more 32 bit support, the driver will be 64 bit only. The 32 bit libraries are still included, so Steam and other applications will keep on being supported.

In a few days, the updated drivers will be pushed in the Fedora repositories, and at the same time I will also remove the i386 folder from the repositories. Some i386 packages will still be provided in the x86_64 folder, as it is now for Fedora 28 and CentOS/RHEL 7. The packages that will be kept, are mostly multilib library packages.

The same will happen to CentOS/EPEL 6 at the moment a new 64 bit only driver series will be nominated as “Long Lived”.

Also the Spotify repository has already no more i386 support, upstream stopped providing updated clients. Judging from the web server logs, there seems to be almost no one using an i686 Fedora in conjunction with the repositories hosted here.

Plex Media Player is back!

Just a small post to notify that Plex Media Player package is back. Now it does not require Conan or Python anymore for building, and you can just build it using standard tools, the dependency issues between the Plex binary packages have been resolved.

Also the TV interface is now improved, on par with what Plex currently offers for other platforms, and it’s much better in terms of performance. I also don’t get anymore the weird positioning of the PIN window.

You can still install plex-media-player-session and do the minimal configuration required (extracted from /usr/share/doc/plex-media-player/README.Fedora):

If you are planning to do an HTPC installation, and would like to have Plex Media Player starting instead of the login screen the moment you boot the
device, execute the following commands as root:

# dnf install plex-media-player-session
# systemctl set-default plex-media-player
# echo "allowed_users = anybody" >> /etc/X11/Xwrapper.config

The first command installs the required files (services, targets and PolicyKit overrides). The second command instructs the system to load by default the Plex Media Player target; that is X and the player just after. The third command allows the system to start the X server as the Plex Media Player user, otherwise only users logged in through a console or root can start it.

If you want to go back to your normal installation (let’s say Gnome), then revert back the changes:

# systemctl set-default graphical
# sed -i -e '/allowed_users = anybody/d' /etc/X11/Xwrapper.config
# rpm -e plex-media-player-session

The package is available for all supported Fedora releases.

Also, on a side note, HandBrake has been updated again to track the master branch, as it now uses FFMpeg 4 and no longer libAV 12. This could probably lead to other improvements, like NVENC/CUDA support, more formats, etc.

CUDA 9.0, cuDNN 7.0 and Wayland support in Fedora 27

The Nvidia repository now contains packages for Fedora 27. This is with the release candidate of CUDA 9, and it contains also cuDNN at version 7.0, which is the only version supported with CUDA 9 at the moment of writing.

The updated cuDNN 7.0 library has been added also to the other branches, this means it will be automatically upgraded from version 6.0 to 7.0. If you still need one of the previous versions, just remove it and install one of the compatibility packages:

# dnf list cuda-cudnn*
Installed Packages
cuda-cudnn.x86_64                   1:7-1.fc26         @fedora-nvidia
Available Packages
cuda-cudnn-devel.x86_64             1:7-1.fc26         fedora-nvidia 
cuda-cudnn5.1.x86_64                1:5.1-2.fc26       fedora-nvidia 
cuda-cudnn5.1-devel.x86_64          1:5.1-2.fc26       fedora-nvidia 
cuda-cudnn6.0.x86_64                1:6.0-1.fc26       fedora-nvidia 
cuda-cudnn6.0-devel.x86_64          1:6.0-1.fc26       fedora-nvidia 

CUDA 9 supports GCC 6.x and CLANG 3.9, so when it will be officially released, it will cover Fedora 25 and RHEL/CentOS compilers. With Fedora 27, there will be the usual need for a GCC compatibility package (like the compat-gcc53 package currently in the repository) as GCC is at version 7 and CLANG is at version 4.0.

I will try to provide a compat-gcc64 for Fedora 27+ at the time of the official CUDA 9 release.

Regarding the drivers, on Fedora 27 where Mutter 3.25+ is available, the modesetting part of the Nvidia drivers has been enabled by default, this means that at the login you can just select “GNOME” to run Gnome on Wayland. Please note that X 3D programs running on XWayland might not work properly.

RHEL 7.4 multimedia packages and Skype repository removal

The upgrade path from Red Hat Enterprise Linux 7.3 to 7.4 is a bit of a pain if you have the multimedia repository configured. This is because I’m rebuilding a few components for an upgraded libwebp package and because a lot of stuff has been rebased to versions that are in Fedora. Judging by the logs, I see that most of the downloads come from CentOS systems, so I just decided to hold on some updates that are required for the various package rebases for Red Hat Enterprise Linux 7.4. So until also CentOS releases version 7.4, I can’t make everyone happy and something (like Gstreamer plugin updates) will be stuck with 7.3 versions. Hopefully the new CentOS release will come quickly enough.

Also, I decided to stop rebuilding the base packages to use a newer libwebp version. This really had very few benefits and just a lot of pain due to the huge amount of packages involved in both x86_64 and i686 variants. The amount of packages affected by this weigh at around 3 gb.

In RHEL 7.4 there are additional WebKit variants that also would require a rebuild. So, as of today, to update the packages from the EPEL 7 multimedia repository you should run this command:

rpm -e --nodeps GraphicsMagick && yum distro-sync && yum -y install GraphicsMagick

Hopefully you would get an output similar to this:

Dependencies Resolved

==============================================================================================
 Package                         Arch        Version                  Repository         Size
==============================================================================================
Updating:
 compat-ffmpeg-libs              x86_64      1:2.8.12-2.el7           epel-multimedia   5.6 M
 ffmpeg                          x86_64      1:3.3.3-2.el7            epel-multimedia   1.5 M
 ffmpeg-libs                     i686        1:3.3.3-2.el7            epel-multimedia   6.1 M
 ffmpeg-libs                     x86_64      1:3.3.3-2.el7            epel-multimedia   6.3 M
 gstreamer1-plugins-bad          x86_64      1:1.4.5-5.el7            epel-multimedia   1.8 M
 libavdevice                     x86_64      1:3.3.3-2.el7            epel-multimedia    63 k
Downgrading:
 leptonica                       i686        1.72-2.el7               epel-multimedia   881 k
 leptonica                       x86_64      1.72-2.el7               epel              928 k
 libwebp                         i686        0.3.0-3.el7              base              169 k
 libwebp                         x86_64      0.3.0-3.el7              base              170 k
 lz4                             x86_64      1.7.3-1.el7              epel               82 k
 python-pillow                   x86_64      2.0.0-19.gitd1c6db8.el7  base              438 k
 webkitgtk                       x86_64      2.4.9-1.el7              epel               12 M
 webkitgtk3                      x86_64      2.4.9-6.el7              base               11 M
Installing for dependencies:
 libwebp0.6                      i686        0.6.0-1.el7              epel-multimedia   255 k
 libwebp0.6                      x86_64      0.6.0-1.el7              epel-multimedia   250 k

Transaction Summary
==============================================================================================
Install               ( 2 Dependent packages)
Upgrade    6 Packages
Downgrade  8 Packages

Total download size: 47 M
Is this ok [y/d/N]:

Basically libwebp should come again from the main CentOS/RHEL channels and the libwebp0.6 package should come from the multimedia repository. All the packages which were rebuilt for the previous libwebp 0.5 update should become synced again to their proper versions.

If you don’t get this output, but still get some dependency errors you have to do some debugging. For example, ffmpeg-libs.i686 requires libssh.i686, but the version of libssh in CentOS extras is different from the one in EPEL (it really depends on what kind of packages you have installed and with which repositories enabled) so I’m providing here the same version that is in CentOS extras but in both variants.

Update 16th August 2017

If you get many qt5 errors during the transactions, keep in mind that RHEL 7.4 has been rebased massively, and everyone else (including EPEL) is catching up. As of today, if you have the following errors (trimmed down) in a Yum transaction:

Error: Package: gvfs-1.30.4-3.el7.x86_64 (rhel-x86_64-server-7)
Error: Package: qt5-qtwebkit-5.6.1-3.b889f46git.el7.x86_64 (epel)
Error: Package: qt5-qtquickcontrols2-5.6.1-2.el7.x86_64 (@epel)
Error: Package: qt5-qtquickcontrols2-5.6.1-2.el7.x86_64 (@epel)
Error: Package: GraphicsMagick-1.3.26-3.el7.x86_64 (@epel-multimedia)
Error: Package: kf5-kdeclarative-5.36.0-1.el7.x86_64 (epel)
Error: Package: qt5-qtquickcontrols2-5.6.1-2.el7.x86_64 (@epel)
Error: Package: qt5-qtwebkit-5.6.1-3.b889f46git.el7.x86_64 (epel)
Transaction check error:
  file /usr/lib64/gstreamer-1.0/libgstopus.so from install of gstreamer1-plugins-bad-1:1.4.5-5.el7.x86_64 conflicts with file from package gstreamer1-plugins-base-1.10.4-1.el7.x86_64

You can do the following. For this:

Error: Package: GraphicsMagick-1.3.26-3.el7.x86_64 (@epel-multimedia)

Do:

rpm -e --nodeps GraphicsMagick && yum -y install GraphicsMagick

All of the QT7KDE 5 stuff:

Error: Package: qt5-qtwebkit-5.6.1-3.b889f46git.el7.x86_64 (epel)
Error: Package: qt5-qtquickcontrols2-5.6.1-2.el7.x86_64 (@epel)
Error: Package: qt5-qtquickcontrols2-5.6.1-2.el7.x86_64 (@epel)
Error: Package: kf5-kdeclarative-5.36.0-1.el7.x86_64 (epel)

Are in EPEL testing updates, so:

yum --enablerepo=epel-testing update

These:

Error: Package: gvfs-1.30.4-3.el7.x86_64 (rhel-x86_64-server-7)Transaction check error:
  file /usr/lib64/gstreamer-1.0/libgstopus.so from install of gstreamer1-plugins-bad-1:1.4.5-5.el7.x86_64 conflicts with file from package gstreamer1-plugins-base-1.10.4-1.el7.x86_64

are some of the packages that are rebased in RHEL 7.4. I’ve created a temporary repository for those, it will disappear once CentOS 7.4 is released as the packages will be integrated in the main multimedia repository. You can install it through:

yum-config-manager \
  --add-repo=https://negativo17.org/repos/rhel74-temp/rhel74-temp.repo

With the above repository it is possible to install all the other multimedia packages.

Skype repository removal

Skype 4.3 is 32 bit only, is now obsolete and has been superseded by a package that actually lists proper dependencies. It is also one of the packages that required one of the above WebKit rebuilds in i686 form for RHEL/CentOS 7 x86_64.

If you have it installed, just remove it with:

yum remove webkitgtk.i686

The repository has been deleted; to install the new Skype provided version, just head to the following official link.

Plex Media Player and MPV with CUDA

The Plex Media Player is now part of the multimedia repository for Fedora 25+. I works as a standalone player and also as the main interface for an HTPC setup, where the “TV interface” starts as the main thing when you power up your system.

Plex Media Player uses MPV in the background, so any compilation option that was added to MPV, is now also part of Plex Media Player by using the same libraries that were already available in the multimedia repository.

If you are using Gnome Software, you will also find it in the software selection screens.

To install it on Fedora, just perform the following commands:

dnf -y install plex-media-player

You will then find it along with the other applications in your menu.

Normal desktop interface

To get to the normal desktop interface just look for the Plex Media Player icon in your menu. You will be greeted with the familiar Plex web interface, with the main difference being that the player is local through the MPV library.

Enabling Plex Media Player startup at boot

If you are planning to do an HTPC installation, and would like to have Plex Media Player starting instead of the login screen the moment you boot the device, execute the following commands as root:

dnf install plex-media-player-session
systemctl set-default plex-media-player
echo "allowed_users = anybody" >> /etc/X11/Xwrapper.config

The first command installs the required files (services, targets and PolicyKit overrides). The second command instructs the system to load by default the Plex Media Player target; that is X immediately followed by the player itself. The third command allows the system to start the X server as the Plex Media Player user, otherwise only users logged in through a console or root can start it.

You will be greeted with the TV interface just after boot:

If you want to go back to your normal installation (let’s say Gnome), then revert back the changes (again type the following commands as root):

systemctl set-default graphical
sed -i -e '/allowed_users = anybody/d' /etc/X11/Xwrapper.config
rpm -e plex-media-player-session

MPV with CUDA

This has been already available for a long time, but with FFmpeg 3.3, CUDA dynamic support loading is enabled also in MPV, so the hard dependency on the CUDA library is gone, and the binaries load the library dynamically:

$ strings /usr/bin/mpv | grep libcuda
libcuda.so.1
$ strings /usr/lib64/libmpv.so.1.25.0 | grep libcuda
libcuda.so.1

So assuming you have the Nvidia driver already installed with the appropriate CUDA part, you can then play a video with the following command line:

mpv --hwdec=cuda /path/to/video.file

And then check with nvidia-smi or with the Nvidia control panel if the video engine is being utilized:

If you want to enable that by default, just make sure your configuration file has something like this inside:

$ cat ~/.config/mpv/mpv.conf 
#hwdec=vdpau
#vo=vdpau
hwdec=cuda

Nvidia driver improvements for Fedora 25+

The Nvidia repository now contains all the remaining bits for the work done by Hans De Goede.

Making an Optimus laptop work as expected with the Nvidia drivers should be much less painful than it was a few years ago and most of the things should work out of the box on Fedora 25+.

Just enable the repository on a pristine Fedora installation, and after a while you should be able to search for Nvidia, CUDA, GeForce to Quadro to make the driver, control panel and other programs appear in your Gnome Software search:

Optimus laptops

The driver should install and operate cleanly whether you are installing it on a system which has one or more discrete Nvidia cards or an Optimus laptop with an Intel and a Nvidia card. Nothing to do to enable or configure Optimus.

This is up to the point that when the drivers are installed, you can even turn off Optimus on or off in your system Bios (if your laptop allows that) and the only difference you should see is that there’s an additional VGA card enabled in your system (check with lspci) and that the Nvidia control panel switches between a PRIME Display, like in this picture:

And a normal RandR managed one, like in this one:

Everything else should not be different from your normal experience.

Limitations

Nvidia driver

The limitations are the same as provided by the Nvidia driver, this means that if you are running it on an Optimus laptop, the Intel card can never power off. Which means higher power consumption, unfortunately. If you have an Optimus laptop and absolutely need the proprietary drivers, my suggestion is still to disable Optimus in the Bios.

OSS stack

On the contrary, if you use the OSS stack (nouveau/intel) the second card can be powered off if there’s no application running on it or display directly connected to one of the card’s outputs. That’s the best reason to use the OSS drivers at all if you you’re not doing serious gaming or 3D work:

$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0

You also got the nifty selection menu about running your game on the discrete card on Gnome, which is really cool:

It will power up the video card just before launching the process. Launching a program through that menu entry is like starting it from the command line with the DRI_PRIME variable declared. For example, the same as above would be:

$ DRI_PRIME=1 quake3 &
$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynPwr:0000:01:00.0

As you can see, the discrete video card is turned on. For Steam, you still need to edit each of your game to run on the Nvidia card:

SLI systems

SLI is now enabled by default with the Auto profile, there’s nothing to do if you have a SLI system. If you need any different SLI option (AA, SFR, etc.), just override it in X.org configuration files.

Nouveau fallback

With the new expanded OutputClass support for X, as carried out by Hans, it’s now super easy to switch to the OSS stack if the proprietary Nvidia driver somehow does not work. No user space component is touched, as soon as the Nvidia kernel module is not loaded (check on /sys/module/nvidia), the desktop starts with the normal OSS components you get with a normal installation. Thanks to all the work done on libglvnd, the libraries loaded are the correct one for the driver you are running.

This means that the performance of the Nvidia card would be abysmal, but still you would get a nice desktop and browser to Google around for answers on how to fix it :).

Upgrade path from Nvidia CUDA, ELRepo and RPMFusion repositories

The current packages should allow you to upgrade if you have any Nvidia component installed on your system from one of the mentioned repositories. All upgrade paths, obsolency and packaging rename should be taken into account.

This has been cool for a few years, and actually helped me a lot in migrating some installed CUDA clusters to the packages hosted here. As part of ongoing discussions with a few parties (mostly Red Hat), this is going to disappear to allow later an opposite upgrade path to one of the other repositories (RPMFusion/Nvidia).

As of the 15th of May, all Nvidia packages will be marked with Conflicts instead of Obsoletes/Provides for all the other repositories out there. I will update the installation and repository page accordingly. If you have anything installed from the RPMFusion, ELRepo or CUDA repository from Nvidia and want to switch to the packages here after the 15th of May, you must “wildcard remove” all Nvidia and CUDA packages on your system prior to proceeding with the installation.

I’m not planning to remove any other feature in terms of capability or packaging option.

Compatibility GCC 5.3.1 package for Fedora

As some might have noticed, since a few days there’s a new compat-gcc-53 package in the Fedora repositories. This is only intended for compiling CUDA programs on Fedora where the latest update to Clang 3.9 actually broke the last compiler compatible with CUDA 8.

$ rpm -ql compat-gcc-53 compat-gcc-53-c++ | grep /bin/
/usr/bin/gcc53
/usr/bin/gcov53
/usr/bin/g++53

If you need to build a package using it, you can check for examples in the Blender and CCMiner packages as in the multimedia repository:

https://github.com/negativo17/blender/blob/master/blender.spec#L57-L61
https://github.com/negativo17/blender/blob/master/blender-2.78a-cuda.patch#L19-L23
https://github.com/negativo17/ccminer/blob/master/ccminer.spec#L75-L82

This way, I was able to provide the Blender package with CUDA support also on Fedora 26 even after the Clang update from 3.8 to 3.9.

The package is also available as a COPR repository if you prefer to use official Nvidia CUDA packages instead of the ones provided here.

To do list

Figure out what to do with the PRIME Synchronization configuration:

https://github.com/negativo17/nvidia-driver/issues/13
https://github.com/negativo17/nvidia-driver/blob/master/nvidia.conf#L2-L5

All reports have been mixed so far. On my systems (including a SLI one) works fine.