Graphics drivers cannot be swapped out without a reboot. Once they’re loaded, they’re holding onto that GPU for dear life. It doesn’t matter whether you try doing it from within a GUI session or a text-only session.
I just got the a recall, I remember that we sometimes use modprobe when troubleshooting parameters for a kernel module, this could possibly work, what do you think?
Looking at the modules folder for the running kernel
ls /usr/lib/modules/$(uname -r)/extramodules
You can use the command modprobe -r <modulename> [<modulename>] to remove the given module(s).
Likewise you can use modprobe -i <modulename> [<modulename>] to load a given module.
Doing modprobe -r nouveau doesn’t seem to unload it(no errors doing it though), I still get the same error from the boot process when doing modprove -i nvidia(with or without the -i) after.
One of the most basic troubleshooting techniques to discover whether an issue is local or system-wide is to create a new User account for testing purposes.
Once the account is created, reboot and login to that account, and progressively test each and every application you might be having difficulty with.
If these applications launch as expected in the new User account, then the likelihood is high that the problem is limited to your usual User account – this knowledge may be useful to others in diagnosing the actual issue – certainly it narrows the scope of troubleshooting required.
If only some applications launch as expected, and others don’t, this may indicate mixed application related causes.
You mention that some of the applications in question are games. As I’m sure you must be aware, many games have specific minimum CPU and/or GPU capability requirements. It might be prudent to research what those requirements are, and whether they are met.
Perhaps you could try that to see what it might reveal, and report back.
Regards.
Both your topics have been merged, as they appear to be closely intertwined.
I would have preferred you didn’t since although they are related, they are 2 very distinct issues I’m trying to solve(and that’s excluding the actual nvidia problem) and merging them just makes things really confusing for people as shown by this:
It’s very well explained… in the original first post. It’s just to test something without having to install a new drive in my pc and install a brand new manjaro on it just for that test.
Ironically, that is something that might have been done a number of times in the time it has taked for you to explain your issue well enough for others to understand.
You’re dealing with others whose first language might not be English, so with that in mind, one needs to be careful to not be ambiguous when attempting to explain a problem, and to be aware that you might not be fully understanding any responses given.
I presume English is not your first language, either, judging by your confusion with the difference between a question mark (?) and an exclamation mark (!).
There was more to my previous comment. Could you create a new User account as suggested to determine whether your issues are indeed local, or otherwise? Then report back with your findings.
… it actually isn’t but that is unrelated to me messing that up since my english is very good, lol, don’t know how I didn’t notice I messed that up.
About creating a new user, I’ll try that tomorrow, it’s 2 am now so a bit late to jump into testing more stuff.
And yeah, I could have done the new install many times by now, but that would require me to find a spare drive I’m not sure I have. It’s mostly to figure out what’s the problem v26 created with the iso at this point.
The next time I create a thread, I think I’ll avoid providing any context, it seems to create more problems when I do that since people try to fix the problem I explain in the context rather than the actual question I want an answer to.
Edit: Btw, all the issues with the apps I mentioned were not present a couple months back, meaning all the apps/games worked fine so it’s not a hardware requirement issue.
Context is welcome – it just needs to be specific. The best context is often in what you can demonstrate – the full output of any diagnostic commands requested are always a good start, even if they may not initially seem related – they can often reveal other factors that might be contributing. Have a good rest-of-the-night.
I include it because it can be helpful, but it has caused a lot of problems each time since people are trying to be too helpful here.
I might try to add it at the end of the post instead of the beginning next time in case people only read the first few lines. Not a single person gave me an answer to this merged thread title. Making a grub entry like on the iso is probably the way to go, I need to give that a shot for that problem.
The title is Switch between Nvidia drivers without driver removal possible?
And the answer in comment number 2
Next thing is that you create a topic about the ISO boot - and so all answers will circle around - booting the ISO - now the threads has been merged and the result is even more confusing.
The free driver (nouveau) and proprietary driver (nvidia) can coexist as packages, which one is active - that is a lot of configuration.
When using mhwd to configure the graphics, a lot of configuration is done based on which GPU and the chosen driver, it is not as simple as a snap of fingers.
Configuration files that are added/changed/removed can be found in
/etc/modprobe.d
/etc/modules.load.d
/etc/X11/xorg.conf.d
Various nvidia services files is activated
nvidia-hibernate.service
nvidia-resume.service
nvidia-suspend.service
The various actions are defined by the mhwd database located at /var/lib/mhwd/.
I don’t know it this will work as you expect but you can tell mhwd which driver to configure.
To configure the free driver (nouveau) - the example uses latest nvidia (video-nvidia) - this could be any of the available nvidia driver versions
mhwd -r pci video-nvidia
mhwd -i pci video-linux
To configure the latest nvidia driver (video-nvidia)
You can also choose to configure everything manually.
First list all drivers installed by mhwd
mhwd -li
Then remove the drivers
mhwd -r pci <drivername>
Ensure that nvidia and nouveau is not blacklisted and there is no remnants of mhwd configuration files.
Then continue to install the packages providing the nvidia driver, either use the precompiled drivers or use the dkms versions (remember kernel headers if you choose dkms) example is Nvidia 580.xx
sudo pacman -Syu $KERNEL-nvidia-580xx
So to be able to prioritise Nvidia over Nouveau you would have to maintain a blacklist configuration in /etc/modprobe.d/my-nvidia.conf.
This is an example, you may need to blacklist other modules as well.
blacklist nouveau
And to use nouveau
blacklist nvidia
Then you can use (add --verbose to get more messages)
The on-the-fly reply I got was simply confirming what I said that that option wasn’t possible, I wasn’t asking how to do it on the fly, I assumed it required a reboot from the start.
I was hoping I could simply blacklist one of them in grub, but it doesn’t seem to be that simple since uninstalling a dkms package I last tested didn’t properly enable the nouveau driver, I had to install and uninstall the proprietary driver with mhwd for nouveau to detect my 2nd monitor, refresh rate and stuff.
Using mhwd to install and uninstall the proprietary one is likely the best way, unless I learn all it does under the hood and possibly make a startup script that would do what I need or something like that.
As for creating a new user to test, it’s having the same software issues so the problem is global.
With the information gathered you are in a better position to understand how the system is configured and perhaps create a script that tears down one driver, blacklist it and setup the other driver - everything without having to reboot.
Doing this while the system is running doesn’t seem to be possible since I get this if I try to do modprobe -r nouveau while KDE is running:
modprobe: FATAL: Module nouveau is in use.
Doing the switch with grub and a script might not be too bad though, the difference in those 3 folders you mentioned is mostly down to modules loaded and blacklisted, which grub can take care of and the nvidia.conf file in X11 and a symlink to it so hopefully a startup script could take care of that, just not sure if we can control launching those before some modules are loaded on linux like freebsd can.
Haven’t worked on this since last time, but I did figure out how to bypass the problem with vs code and brave not working with the proprietary driver.
Apparently in electron 38 a setting changed to auto-detect the platform but when it fails for wayland, it doesn’t fallback to X11 and therefore just fails to load.
With the --ozone-platform=x11 argument it loads fine.