This is really awesome! I just installed EOS with the nvidia option, it connects to my nvidia card when I connect an external screen, else it uses intel on the laptop. To me its a good balance to get good battery life on the go. I tried optimus and switching graphics manually (in October-Nov 2020) but this did not go well, also sometimes broke during updates. The only distros this worked for me was manjaro and pop OS, they seem to have implemented this quite well, although manjaro had some problems with nvidia drivers in Dec/Jan due to the recent upgrade in the Arch repository.
Edits: - may be important to also list DE, I have Plasma 5.20.5, all this on Lenovo thinkpad P1 (work computer) - I read stuff about optimus, prime etc. a dozen of time but I am still puzzled how this all works.
Also, haven’t check it in a while, but initiative idea was great in terms of solving hardware problems cross-distro, might wanna see what’s up with them
yea i see now looking very enhanced Garuda is putting a lot of work into this, i would also simple use mhwd, and it looks like Garuda is already porting this to work with arch itself.
And 100% is that we want to work together
Using Gnome on Wayland. Intel only. My dGPU is powered off via bbswitch as i’m not using it currently. Used to use nvidia-prime in the past to run games on the dGPU (on X11 back then, Nvidia you know…)
@joekamprad Since I was linked into this thread, here are my thoughts.
While I am flattered at @keybreak 's post about Optimus-Switch, I have to issue some cautions. First off, the main script is no longer actively maintained by the original dev. So far, nothing has changed with xorg that requires a revision. This reliance on xorg is also a long term problem. As Wayland matures and the nVidia driver will (hopefully one day) support it without issues, these scripts will become obsolete. I will do my best to try and update them as needed, but my knowledge in this area is limited. These are the reasons why I think that it should not be included as a default option. As an option for users to choose from, yes, but default, no.
I do have a couple of concerns about going the mhwd route. The biggest is that mhwd does not use the default naming conventions for config files and its use of custom directories. The config files created have mhwd appended to them and some of them are placed in directories that are not the default. This can cause issues when updating and installing a driver and if the distro wants to keep things as close to Arch as possible. This leads to my second concern, the use of a custom naming convention will cause more work for the maintainers of the distro. They will have to create/ maintain a custom kernel that makes use of the naming conventions and modify/ maintain the driver. If this issue is fixed, then I like the idea of using mhwd. So far, all the tools EnOS brings to the table are transparent to a normal Arch install. In my opinion, it would not be good to change that.
Finally, my concern with Optimus-Manager. For Gnome, or any other DE that uses GDM, it requires the use of modified version of GDM from the AUR. From what I recall, it adds in the “patches” that Ubuntu does to the upstream code to allow for the switching of GPU’s to take place. While I have no problem relying on the AUR for programs, when it comes to core system related stuff, I am very wary. A distro should be as close to upstream as possible. Any tweaks that they do, should be maintained by them and not a third-party source.
I wish that I could be of more help, but as I said before, my knowledge is limited. Since I have an extra SDD I can throw in my laptop, I would be willing to be a tester and give feed back.
To the nature of doing EndeavourOS in my spare time, I do not follow that much on Manjaro and mhwd function and development… But @linesma and @keybreak are right, if it is needed to change the default way to configure drivers and configs, we will not go that way.
But we need a way to detect hardware and configure basic system drivers in a more convenient way than the pure Archway.
That’s one of our core features.
Staying close to arch but making it more convenient to use, in my opinion, the basic system should be working out of the box, a user should not be forced to need to set up drivers and basic system features manually, they should work as they should, ready to fine-tuning them as you want.
And we already have nvidia-installer as a script, we can get informed and working on enhance this way of configuration to work also for optimus-manager and optimus-manager-qt.
But yes true GDM/GNOME and also Plasma need special changes, possible to test if this is needed, on GNOME you could use lightdm and Plasma may not need the extra plasma features to work good?
Both optimus-manager and the qt “rider” are from AUR, but developers are reachable and development is transparent:
I do not think we should start to create our own switcher tool if it is there already.
Hardware detection and using it to set up hardware to simply work is the main goal to get working!
I honestly think that this will not be possible with the current state of Optimus support under Linux. Some sort of user interaction during the install will be required.
Why not just edit the script a little bit. My concerns about using the AUR for core system components aside, one idea is, when the script runs, have it ask the user if they are installing it on a laptop with Optimus graphics. If they answer yes, the script can then ask the user what DE they are using and then install the appropriate version of Optimus-Manager.
Or after the user states that they are installing this on a laptop, give them a choice between “Prime” mode where the nVidia card is used all the time or Optimus-Manager for a switching setup. Then have the script install the appropriate configurations and files.
