search

bayasdev / envycontrol

Easy GPU switching for Nvidia Optimus laptops under Linux
MIT License
1.22k stars 62 forks source link

Does not work on Silverblue #49

Closed ghost closed 1 year ago

ghost commented 2 years ago

Hello, As you may know, Fedora Silverblue has a read-only filesystem where only /etc and /var are writable directories. Unfortunately, since your Python script relies on putting udev rules in /lib which is read-only, a tiny modification is required to make this work: swapping every /lib (there are only two) in the script with /etc. As I'm not really familiar with scriping with Python, I don't know what would be the cleanest way to implement this without rendering this script unusable on other distros. I just wanted to make you aware of this current issue. For now, I will be modifying it locally for myself, until a solution is found.

Thank you for making Fedora usable for the unlucky Nvidia Optimus owners!

bayasdev commented 2 years ago

Hello there,

Thanks for letting me know.

Maybe we can try adding a flag called --silverblue or sth else that swaps file paths starting /lib with /etc.

Greetings.

El jue, 30 de jun. de 2022 08:34, ActualDisaster2447 < @.***> escribió:

Hello, As you may know, Fedora Silverblue has a read-only filesystem where only /etc and /var are writable directories. Unfortunately, since your Python script relies on putting udev rules in /lib which is read-only, a tiny modification is required to make this work: swapping every /lib (there are only two) in the script with /etc. As I'm not really familiar with scriping with Python, I don't know what would be the cleanest way to implement this without rendering this script unusable on other distros. I just wanted to make you aware of this current issue. For now, I will be modifying it locally for myself, until a solution is found.

Thank you for making Fedora usable for the unlucky Nvidia Optimus owners!

— Reply to this email directly, view it on GitHub https://github.com/geminis3/envycontrol/issues/49, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALY7IYNYWXYXEAGPHI53ZH3VRWO65ANCNFSM52JMHQ3A . You are receiving this because you are subscribed to this thread.Message ID: @.***>

ghost commented 2 years ago

Thanks for responding so quickly! Yes, that would be awesome. The question is: Do you think that would change the behavior of the GNOME extension GPU profile selector? If so, then I would open an issue against that extension and see if the maintainer is open to adapt their code around this change.

kenos1 commented 2 years ago

This can be fixed by making envycontrol an installable rpm

ghost commented 2 years ago

The question is who would maintain it? Would it be submitted to the official Fedora repos? Even if not submitted to the Fedora repos, the RPM would require testing before getting published on GitHub. But all that aside: Would enough people benefit from this?

The reason why I am being so skeptical is because I don't have the expertise to do any of that/contribute and I don't want to waste dev time and QA on something that only I would benefit from.

kenos1 commented 2 years ago

You can put it on Copr. People can benefit from this as anyone running Fedora can just install the RPM on their system.

ghost commented 2 years ago

I don't like adding Coprs just like many other people don't. There is always this fear of them breaking updates. Also adding Coprs on Silverblue is not really that easy and a lot can go wrong. You basically have to copy a reference file (from Copr) into a directory and hope that rpm-ostree would pick the change up.

I would prefer an RPM from GitHub that I would manually install and update over Copr anyday.

kenos1 commented 2 years ago

That is understandable, just putting an RPM on Github releases works. I do not know packaging software very well (especially for RPM distributions), but it would be both convenient and helpful for rpm and rpm-ostree users.

From what I heard from others, there isn't much clear documentation for creating RPMs, but you can get help from others.

ghost commented 2 years ago

I also don't have experience with building and maintaining RPMs and I'm hesitant to ask for an RPM because of the lack of documentation.

kenos1 commented 2 years ago

I guess I will try sometime.

kenos1 commented 2 years ago

https://www.redhat.com/sysadmin/create-rpm-package I found a decent source on how to.

kenos1 commented 2 years ago

I unfortunately didn't get it to work on rpm-ostree distributions.

kenos1 commented 2 years ago

I have also tried to replace /lib to /etc in the script and it does not work on Fedora Kinoite because /usr/share/sddm/scripts/Xsetup is read-only.

Update: Integrated and hybrid mode works. Only nvidia does not.

ghost commented 2 years ago

It seems that Silverblue is still not ready for the masses. I've been having a few other issues and contemplating switching back to Workstation because of this and other things.

kenos1 commented 2 years ago

I'm testing this fix on Fedora Silverblue and I can confirm that everything works. I think that it is broken with SDDM.

sith-on-mars commented 1 year ago

Is there any progress on this?

bayasdev commented 1 year ago

@sith-on-mars I don't have Silverblue (or any other ostree/inmutable distro) support planned

travier commented 1 year ago

Note for people coming to this issue: You should be able to overlay the RPM package from the COPR build on Silverblue.

travier commented 1 year ago

My bad, it looks like the script directly writes to /lib: https://github.com/bayasdev/envycontrol/blob/main/envycontrol.py#L202

This is not recommended, on any distributions, not just Silverblue. Custom local udev rules should be installed in /etc/... as /lib or /usr/lib is for distribution provided rules only.

alongwhile commented 10 months ago

I can confirm that simply cloning the repo and editing the python script to replace /lib/udev/ with /etc/udev/ in 2 places was enough to get this working for me running Fedora Silverblue 38 w/ Gnome Wayland

I forked it here if anyone wants to use it but you can easily edit the original script yourself as well.

I'll continue to add or update my version if people can commit some changes since I'm sure it can be improved for further compatibility. @bayasdev has indicated in the past that he has no plans to support immutable distros so hopefully this can help others somewhat.

klmcwhirter commented 6 months ago

@bayasdev , @ghost, others, I notice that arch wiki documents the /etc/udev location as:

udev rules written by the administrator go in /etc/udev/rules.d/, their file name has to end with .rules.

And /lib/udev (/lib is symlinked to /usr/lib on fedora ws 39) as:

The udev rules shipped with various packages are found in /usr/lib/udev/rules.d/

Also, ...

f there are two files by the same name under /usr/lib and /etc, the ones in /etc take precedence.

https://wiki.archlinux.org/title/Udev

So, if /etc/udev vs /usr/lib/udev is an intentional design choice, what is the harm in envycontrol switching to /etc/udev ? It seems lile the right thing to do in general. envycontrol is overriding shipped behavior - right?

If the user is not using systemd, then it seems a completely different approach might be needed anyway.

Just challenging the need for a -silverblue or -immutable flag as mentioned above in https://github.com/bayasdev/envycontrol/issues/49#issuecomment-1171441927

Thoughts?

Incidentally, I found a different approach for integrated mode that does not require messing with udev rules. See #157