Manjaro Settings Manager - Chucked in a spare NVIDIA GPU up and running in no time

I can't believe how ridiculously easy that was to install an NVIDIA GTX960 into my already setup desktop formerly using the APU's built in AMD R3 GPU with Manjaro KDE.

It booted fine with nouveau, no issue whatsoever with SDDM. I clicked the Auto install proprietary driver button and left it to do it's thing. One reboot later, up and running with the proprietary 435.XX driver and so far all appears okay.

Idiot proof :slight_smile:

EDIT - and still whisper quiet as the dual fans are working on temperature control as they should without any extras from AUR. The APU has a fanless heatsink which is why there's 0 rpm read out.

System:    Host: Aures Kernel: 5.3.0-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.1.0 Desktop: KDE Plasma 5.16.4 
           Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: Gigabyte model: AM1M-S2H v: x.x serial: <filter> UEFI: American Megatrends v: F2 
           date: 06/20/2014 
CPU:       Topology: Quad Core model: AMD Athlon 5350 APU with Radeon R3 bits: 64 type: MCP arch: Jaguar rev: 1 
           L2 cache: 2048 KiB 
           flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 16379 
           Speed: 798 MHz min/max: 800/2050 MHz Core speeds (MHz): 1: 799 2: 798 3: 797 4: 798 
Graphics:  Device-1: NVIDIA GM206 [GeForce GTX 960] vendor: ASUSTeK driver: nvidia v: 435.21 bus ID: 01:00.0 
           Display: x11 server: X.Org 1.20.5 driver: nvidia resolution: 1280x1024~60Hz 
           OpenGL: renderer: GeForce GTX 960/PCIe/SSE2 v: 4.6.0 NVIDIA 435.21 direct render: Yes 
Audio:     Device-1: Advanced Micro Devices [AMD] FCH Azalia vendor: Gigabyte driver: snd_hda_intel v: kernel bus ID: 00:14.2 
           Device-2: NVIDIA GM206 High Definition Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 01:00.1 
           Sound Server: ALSA v: k5.3.0-1-MANJARO 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Gigabyte driver: r8169 v: kernel 
           port: d000 bus ID: 02:00.0 
           IF: enp2s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 349.32 GiB used: 71.15 GiB (20.4%) 
           ID-1: /dev/sda vendor: Crucial model: CT500MX500SSD1 size: 349.32 GiB 
Partition: ID-1: / size: 333.88 GiB used: 71.15 GiB (21.3%) fs: ext4 dev: /dev/sda2 
           ID-2: swap-1 size: 8.80 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda3 
Sensors:   System Temperatures: cpu: 37.0 C mobo: 31.0 C gpu: nvidia temp: 42 C 
           Fan Speeds (RPM): cpu: 0 fan-1: 0 fan-3: 0 fan-4: 0 fan-5: 0 gpu: nvidia fan: 0% 
           Voltages: 12v: N/A 5v: N/A 3.3v: N/A vbat: 2.88 
Info:      Processes: 163 Uptime: 13m Memory: 7.72 GiB used: 1.05 GiB (13.7%) Init: systemd Compilers: gcc: 9.1.0 Shell: bash 
           v: 5.0.9 inxi: 3.0.36

Got some of my Steam games up and running now. It's been ages since I played Titan Attacks! and Portal. I had to make some icons for them though as they were blank (edit - same for HL2). I converted the portal BMP icon to png and tidied up the rough white surround.


I also ended up extracting the ico file for multiwinia from the executable using this command:

wrestool -x -t 14 /home/antikythera/.steam/steam/steamapps/common/Multiwinia/multiwinia.exe > multiwinia.ico

I found a nicer Portal icon with DDG


Just curious: do users need to replace nvidia-430xx with nvidia-435xx to keep the driver up-to-date even if they don't use hybrid GPU?

The thing is I don't understand the meaning of version number. Is 435xx is just a different branch with default hybrid GPU implementation, or is it an absolute newer version which contains bug fixes that are not included in 430xx?

you should have opened a new topic about that or just read about it on the NVIDIA website but in simple terms 435.xx is the latest NVIDIA driver supporting newer hardware and carries optimisations for the latest games. It may not be suitable for some older hardware, you can check which driver to use for your GPU on the NVIDIA website using their driver selector tool.

  • Fixed a bug that caused the X server to crash when using HardDPMS with an NVIDIA-driven GPU Screen.
  • Fixed a bug which caused the kernel to panic when exiting a single X server when multiple X servers were active and in an SLI configuration.
  • Fixed a regression introduced in the 430.* series of releases that caused a segmentation fault in while using Video Codec SDK APIs on certain graphics boards.
  • Added initial experimental support for runtime D3 (RTD3) power management on Turing notebook GPUs.
  • Improved to collect runtime D3 (RTD3) power management information.
  • Improved to collect ACPI tables when the acpidump tool is available.
  • Added Vulkan and OpenGL+GLX support for PRIME render offload. Please see the PRIME Render Offload chapter in the README for system requirements and configuration details.
  • Added support for changing Digital Vibrance in the display controls section of nvidia-settings on Turing hardware.
  • Fixed the cuvidParseVideoData API in the NVCUVID driver to correctly propagate errors returned by the PFNVIDSEQUENCECALLBACK callback function to the application.
  • Fixed a bug that caused the NVIDIA X driver to behave incorrectly or crash when a client queried Xinerama information on X servers with a non-NVIDIA X screen as screen 0.
  • Fixed the "Image Settings" options in the "OpenGL Settings" page of nvidia-settings for Quadro GPUs. Previously, OpenGL rendering on Quadro would behave as if the "High Quality" option were selected regardless of the selection. Now, the setting will default to "High Quality" for Quadro but selecting a lower option will affect rendering accordingly. (Other GPUs are unchanged: the default remains "Quality", but other options can be selected if desired.)
  • Fixed a bug that could cause Vulkan applications to generate spurious warning messages about a missing NV-GLX extension.
  • Removed the non-GLVND OpenGL libraries from the NVIDIA Linux driver installation package. The GLVND OpenGL libraries were introduced in release 361.16, and have been installed by default since release 364.12, with the non-GLVND versions available as an alternative via the "--no-glvnd-glx-client" and "--no-glvnd-egl-client" installer options. As the non-GLVND libraries are no longer included in the installation package, these options will no longer have any effect.
  • Fixed a bug that prevented nvidia-drm from marking preferred modes properly when reporting display information via the DRM-KMS API.
  • Updated nvidia-installer to make compiler mismatches non-fatal when adding precompiled kernel interfaces to an installer package using the "--add-this-kernel" option, to be more consistent with the behavior when installing without precompiled interfaces.
  • Fixed the NvEncodeAPI driver to correctly reject the encoding of sequences with resolutions smaller than what the NVENC supports.
  • Fixed display color range handling on pre-Turing GPUs, such that when limited color range is selected through the display controls page in nvidia-settings, output pixel values will be correctly clamped to Consumer Technology Association (CTA) range.

Thanks for the enlightenment. I was confused because nvidia-430xx replaced the existing nvidia by default so I thought that means nvidia-435xx is not the direct upgrade from the existing driver. Perhaps is to prevent some backward compatibility issue? Anyway, thanks for the explanation.

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

Forum kindly sponsored by