A quick note:
RPM Fusion is either written “RPM Fusion” or “rpmfusion”.
I haven’t reviewed the code itself, but it should be relevant to have packaged in the rpmfusion nonfree section. (maybe the name should be simplified so that it can be relevant for other Fedora spins).
There are many corner cases that need to be taken care off, so this is very welcomed !
This is the “direct” method. A not-so savvy user or some one with less time to spare might not want to go through the documentation and add the repositories again, before installing the driver and their dependencies. This one tool does it all for you from a single place.
Thanks for the insight about RPM Fusion - I’d make changes soon and it would be reflected in the next revision. Also, I have linked my repo so feel free to take a look at the code.
The reason why I am specific about Workstation and the listed graphic cards is because those are resources I was able to test on. If someone running a spin could test and confirm it to be working, I can surely generalize it for other spins.
Please take a look and let know how I can improve upon this. I’d be obliged.
I would like to circle back to a point I had made when you posted your guide. There is no need to wait for 5 minutes. On my not very fast laptop, the whole thing is done in 25-40s depending on load. That’s a lot of time wasted, especially if there is a failure.
Your script should be keeping an eye on the actual process and I can think of none other more qualified than @kwizart to help you check the exit code of the akmod transaction.
Right. That is kind of a blind wait as of now but kind of ensures that things would most likely work. But in order to automate this, I should be able to track if the event took place or not.
@kwizart Looking forward to your assistance. You can find the link of my repo at the original post. I am in Fedora Join SIG Telegram group there so we can discuss as to how we can monitor the status of the akmod transaction.
@alexpl I wish I had testers for this. That would very much bring down the times I would have to shoot arrow in the dark.
He’s saying, with some polish this could easily become an RPM Fusion package; makes sense considering it’s using the repos. (Not sure why it would have to live in the nonfree section, though; is there some rule prohibiting even freely-licensed packages from living in rpmfusion-free if they have nonfree dependencies even indirectly, @kwizart?)
A few thoughts/suggestions, though I can open issues for some/all of these in the Github repo if you prefer.
Nothing needs that many exclamation points. Obtaining “compatibility information” for my graphics card is not a cause for celebration or excitement.
Do yourself a favor and at the very least create a class of string aliases, something like:
So you can just print(Status.SUCCESS + "Message" + Style.RESET_ALL).
Or better yet, a Status class with a set of class methods that take string arguments and do all of the necessary decorating and printing, so you can just write lines like Status.success("Message") and Status.failure("Message").
It’ll greatly reduce repetitive code duplication, and more importantly allow you to change how things are formatted in one place instead of having to make identical edits to 20 lines of code.
“if lspci line count != 1” is a bad way to identify Optimus/PRIME configurations. It’ll mis-classify any system with two or more discrete GPUs.
You say “Discrete cards from 9XX/10XX/20XX series only are supported.” but that’s just not true. There’s nothing I can see that would fail to work with older cards, and more importantly nothing in the code that limits support to only those cards — or any cards. Literally any GPU that has “NVIDIA” in its PCI ident string will be recognized.
That previous point is an issue for older cards that aren’t supported by the current driver series (currently that’s any card not on the Supported Products listing here, roughly anything before GeForce 630 / Quadro 410) — it’d be cool to have some way of detecting older cards and automatically switching to the appropriate 390.xx, 340.xx, or 304.xx (forgot, those were dropped) legacy driver as needed. That’s admittedly a tall order, though, as you’d probably have to both convert that support list to some parseable form, and constantly keep it up to date with newer releases. But at the very least, it’d make sense if the tool refused to install the current drivers on systems with GPUs they won’t support.
I would definitely need some assistance in solving this.
I claimed so because these are the only cards that I was able to test with. It would have been wrong (to my conscience) if I would have claimed it to be working on some other cards when it was not tested on them.
I admit it can be a long haul but it is worth doing as it would also address people owning older GPUs.
I have very little experience with switchable-GPU type setups, my one laptop contains only an Intel GPU. But AIUI, all switchable GPU laptops pair an Intel GPU with a higher-end discrete chip, correct? So, identifying those systems might be as simple as searching for a second line in the output that contains “Intel”.
(Well, scratch that — it still won’t be able to discriminate between Optimus/PRIME and systems like one desktop I had, where the motherboard used a sucky Intel GPU, so I stuck an Nvidia card into it and just used that instead, ignoring the motherboard GPU.)
And that’s laudable, but I would say it that way: It’s only been tested with those cards, but should work with any GPU supported by Nvidia’s current driver series.
I don’t know how far you have been by replacing the sleep after akmods installation. But at least you should be able to poll the availability of the nvidia.ko using modinfo
Please verify to be on the latest kernel or you will need to
On second thought, using python will requires you do lot of bolder plates.
It might be more relevant to move to use “ansible” instead…
It still interesting work!
v0.2.5 released (31 May 2020, 10:38IST)
Made very important changes and fixed some bugs to get the v0.2.5.
What has been improved upon?
Removed that nuisance mandatory sleep time for kernel module load. (as per discussion here)
Removed dependency on kernel module loader (as per discussion here)
Removed kernel module force-read altogether (no sudo akmods --force or sudo dracut --force anymore)
Defaulted textual messages to autocolor for better legibility (functionable visibility in themed terminals also)
Fixed boolean choices in main function
Fixed boolean choices in package check
Fixed prompt colors for custom-themed terminals
This is what I would work on, down the line. All the issues would be paid equal amounts of attention but there is a dire need of testers for the spins. Feel free to comment under the issue on which you can be assistance.
This is kind of a big update as it does away with the unnecessary wait times for kernel module loading and forced akmods creation after the installation has completed. The five-minute wait was indeed an inconvenience an modified kernel modules are loaded way before that time even in the slower PCs so it is not worth waiting so long. Also, the akmods transaction commences immediately after the installation gets over and does not let you turn off the PC right away before the modules are completely built so there is no reason why you should force building modules via akmods and dracut.