Guide: Install and configure optimus-manager for hybrid GPU setups (Intel/NVIDIA)

Thanks! I can see DPI is changed in optimus-manager config, but it's not shown in 10-optimus-manager.conf. These three lines don't exist in my 10-optimus-manager.conf.

    Option         "AllowEmptyInitialConfiguration"   
    Option         "RegistryDwords" "PerfLevelSrc=0x2222"
    Option		   "DPI"	   "75 x 75" 

i was only referring to the DPI line, the other 2 are for coolbits to enable overclock and set performance level.

that DPI line is the easiest and IMO best way of handling the DPI issues you get on KDE between intel and nvidia modes. if you try using KDE settings to fix it on say nvidia mode and then boot into intel mode everything will be a huge mess. applying them only to nvidia's xorg config makes everything scaled properly.

I think HiDPI scaling in Nvidia mode is currently buggy, as seen in

Can you please explain why using KDE settings to fix scaling can mess up things? I didn't see any side effect actually.

because there are multiple settings and each scales certain things (font, gtk, qt, etc..) and since im assuming you want the scaling of intel mode to be the same as nvidia mode it just makes more sense to use the xorg configuration so that everything is scaled evenly, and then if needed you can make small adjustments.

i just had a look at the optimus-manager files, since DPI doesnt seem to set properly if set from 10-optimus-manager.conf i think you should just comment that particular line and try doing it this way.

again, i dont use optimus-manager but going by the github page you should have a xorg-nvidia.conf somewhere in optimus-manager's files where you can specify option lines to add to the xorg configuration.

# You can use this file to add Xorg options which are not covered in the configuration file.
# Everything you put here will go to the "Device" section corresponding
# to the Nvidia GPU in the Xorg configuration.
# Lines starting with # are ignored.
# Example :
# Option "ConnectToAcpid" "0" 

Option		   "DPI"	   "96 x 96"

save and switch modes after to see if it applies as it should. adjust "96 x 96" with any values you want

1 Like

Hey folks, optimus-manager-git PKGBUILD in AUR hasn't been updated for a while, but the author's repository has a working one:
Download it and .install file too and build with makepkg.
After installation, you can set a new cool "Auto" option of startup mode, which handles the behaviour of OM during the boot and allows to auto-choose mode depending on the wall power source availability:

1 Like

Isn't it the nature of AUR git packages that they pull directly from the working branch, so they don't need to be updated, apart some occasional version bumps (cosmetic change to the package look)? So if one wants to check new commits, reinstalling git package is all that is needed. The fact whether the package on AUR page was updated or not, has no influence upon it.

As far I recall, I had this Auto startup option since a long time on git branch.

Unless the git package is referring to some static release on git page, then yes, it does need update.

Yes. Thats true (from the maintainer end)
The user still needs to rebuild the git package to get the update though.
They probably wont be automatically bugged for it depending on their helper.
Though yay has a feature for this.
(I will include update first because you should .. and separately from the helper cuz tradition)

sudo pacman -Syu && yay -Sua --devel

Depends on the PKGBUILD. In this particular case, AUR's one has hardcoded instructions incompatible with the latest changes in git repo. It tries to operate with files that don't exist anymore.

Package Details: optimus-manager-git 1.2.2-2
Last Updated: 2020-05-02 07:02

  install -Dm755 scripts/prime-switch-boot "$pkgdir/usr/bin/prime-switch-boot"
  install -Dm755 scripts/prime-switch "$pkgdir/usr/bin/prime-switch"
  install -Dm755 scripts/prime-offload "$pkgdir/usr/bin/prime-offload"

This is why it ends up with a failure...


Thanks, that explains it. I flagged the git version on AUR as out-of-date. The non-git version is up to date ironically.

This gets me wondered, what the version is in Manjaro repo? Upon a fast check it turns out it's still 1.2.2-2.2 in stable branch. Upon a bit longer check, it's also on 1.2.2-2.2 in testing.

@philm or @oberon , could you update optimus-manager in Manjaro repo to 1.3?

I'll throw this in while we have the devs' attention :slightly_smiling_face:

Is there any chance that at some point optimus-manager could be officially supported by Manjaro, ideally through mhwd?

I'm still using bumblebee as I prefer to stick to officially supported configurations for graphics drivers as they are a minefield and I want to avoid potential problems after system updates, plus I love mhwd's ease and stability when changing configurations if needed.

I've tried video-hybrid-intel-nvidia-440xx-prime on one laptop that supports it but with the NVIDIA card always on the battery time goes down and the fan spins faster. optimus-manager seems the best solution.

1 Like

From what I understand, this isn't possible, at least in how it currently works. Optimus-manager does many changes, it even modifies systemd somehow to make it all work. MHWD is rather a simple install and configuration utility so implementing optimus-manager would need a complete rewrite MHWD from the scratch and even rebuild it into more advanced and complicated tool.

From distro maintainer perspective, it's just not a good choice. Everything is in flux so additional tools must be simple to update them easily.

Additionally, optimus-manager needs MANUAL configuration so this beats the purpose of having it within MHWD where you rely on everything being set for you automatically.

Also, since there are countless hardware combinations, we can't be sure that optimus-manager will work smoothly with them all the time and this also creates different graphic configs that need to be manually disabled.

In theory, it all could be automated, but this would be susceptible to more problems than it is now. Manual intervention ensures you adapt it for your current hardware and setup situation.

With time, when hybrid drivers and linux kernel updates along with newer graphic cards that could do more advanced energy settings, hybrid setup will be a viable solution, because dGPU will be turned down or use so little energy it would be negligible. Till then, switching hacks that complicate things a bit are the best solution for old or current hardware.

Thanks for the reply. OK I see and I suspected that could have been the case. I'll give optimus-manager a go at some point. Thank you for the work you are doing on it.

prime-run actually equates to


Forum kindly sponsored by