When NVreg_PreserveVideoMemoryAllocations in modeprobe.d is set to 0, gdm will disable wayland in /lib/udev/rules.d/61-gdm.rules, therefore x11-drivers/nvidia-drivers should set it to 1 when emerged with the "wayland" USE-flag. Reproducible: Always Steps to Reproduce: 1. install x11-drivers/nvidia-drivers and gnome-base/gdm with "wayland" USE-flag 2. try to open a Wayland session 3. Actual Results: Wayland sessions are not available from gdm when using the nvidia proprietary driver. Expected Results: Possibility to open wayland sessions from gdm when using the nvidia proprietary driver. Related bug: https://bugs.gentoo.org/873154
This has been known to cause issues with elogind for several users (partly due to lack of nvidia hooks) and not convinced I want to unexpectedly turn this back on at the moment even with USE=wayland (perhaps not even using wayland) -- doesn't help that I don't have a proper setup to test this at the moment (maybe if had some feedback). Would rather leave it up to users to edit their nvidia.conf as they see fit. Regardless of if that'd be good or not, that gdm is checking sleep-related stuff to enable wayland makes little sense to me -- this is just adding obscure ways in which wayland will be disabled based on how users setup sleep features.
(In reply to Ionen Wolkens from comment #1) > Would rather leave it up to users to edit their nvidia.conf as they see fit. In this case I would at least add an explaining elog entry into pkg_postinst() to make people aware of this issue, since enabling the "wayland" USE-flag alone would not be enough for starting Wayland sessions with this driver.
(In reply to Thomas Scheiblauer from comment #2) > In this case I would at least add an explaining elog entry into > pkg_postinst() to make people aware of this issue, since enabling the > "wayland" USE-flag alone would not be enough for starting Wayland sessions > with this driver. I consider this to be a gdm issue more than a nvidia-drivers issue, and I think gdm should be the one to do something about it.
(In reply to Ionen Wolkens from comment #3) > (In reply to Thomas Scheiblauer from comment #2) > > In this case I would at least add an explaining elog entry into > > pkg_postinst() to make people aware of this issue, since enabling the > > "wayland" USE-flag alone would not be enough for starting Wayland sessions > > with this driver. > I consider this to be a gdm issue more than a nvidia-drivers issue, and I > think gdm should be the one to do something about it. As a reminder, this is entirely gdm-specific, this doesn't stop you from using wayland with e.g. sddm+plasma, sway, etc... And I'm not quite sure why it wants to disable wayland based on sleep settings.
I upgraded to gdm-43.0 today and also got my Wayland session unavailable. I'm glad I found those two reported bugs. I had to change the lookup path for "system-sleep/nvidia" and set NVIDIA_PRESERVE_VIDEO_MEMORY_ALLOCATIONS variable to 1. But found another problem. ``` IMPORT{program}="/bin/sh -c 'echo NVIDIA_HIBERNATE=`systemctl is-enabled nvidia-hibernate`'" ENV{NVIDIA_HIBERNATE}!="enabled", GOTO="gdm_disable_wayland" IMPORT{program}="/bin/sh -c 'echo NVIDIA_RESUME=`systemctl is-enabled nvidia-resume`'" ENV{NVIDIA_RESUME}!="enabled", GOTO="gdm_disable_wayland" IMPORT{program}="/bin/sh -c 'echo NVIDIA_SUSPEND=`systemctl is-enabled nvidia-suspend`'" ENV{NVIDIA_SUSPEND}!="enabled", GOTO="gdm_disable_wayland" ``` These lines in the rules file (right after the one with MEMORY_ALLOCATIONS check) basically disable Wayland session for anyone with the OpenRC system since there isn't a systemctl utility. I had to comment out these lines to enable the Wayland session again.
It seems the setting is here to avoid problems like: https://gitlab.gnome.org/GNOME/mutter/-/issues/1942 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3583
(In reply to Pacho Ramos from comment #6) > It seems the setting is here to avoid problems like: *needed
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a0f953fc4720a191288b7e28c1df4ab50eb9a598 commit a0f953fc4720a191288b7e28c1df4ab50eb9a598 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-09-06 09:13:41 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-09-14 10:49:26 +0000 x11-drivers/nvidia-drivers: use PreserveVideoMemoryAllocations=1 (Disclaimer: I do not have the right setup to test any of this, but doing it blind given the increasing amount of affected users -- call for testing has shown that it should work as expected albeit users with more custom setups such as suspend without elogind/systemd will need to pay attention to warnings given breakage *is* expected). Was formerly disabled because it broke sleep with elogind, systemd if the units were not enabled, and other custom methods to enable sleep. However, =0 is limited and is seemingly broken with wayland (typically resulting in graphical corruption after resume). GDM straight up refuse to show a wayland session if it's not set wrt bug #873160, and several Plasma 6 users been reporting issues and its upstream also instructs distributions to set this. So this adds a elogind hook, enables systemd units by default (much like it is for the elogind hook), and at least warn for the last case which is considered semi-unsupported. elogind does have its own HandleNvidiaSleep option, but it is intended for old drivers which did not ship a nvidia-sleep.sh and reports seem to show that it may not be working properly. Ebuild warns that it should be disabled instead, and also tries to warn if there is old custom scripts installed by the user. One downside of hook vs the option is that hooks are not told if using suspend or hibernate and this sends the wrong message to the drivers (albeit not known to be an issue at the moment). May not fix everything wrt bug #693384, but believe this is the best we can do downstream unless someone knows better, and so closing it. There are plenty of issues unrelated to elogind too, ideally would need users to compare with systemd before filing more elogind sleep bugs unless know exactly what is causing issues in elogind. wrt bug #873160, this only fix *one* thing that the gdm udev rules check and so may not mean will necessarily start seeing wayland in gdm. Rules currently need =1, systemd-only, and a non-hybrid setup (aka just nvidia, no offloading). See also the general bug #939201. Straight-to-stable may not be the best idea, but wanted to simplify and not revbump the 3 .conf, duplicate them, and adjust every ebuilds further for this (believe it *should* be ok, or at least not make things worse for typical users). Also want to deliver the fix early to plasma 6 users newly using wayland by default. Closes: https://bugs.gentoo.org/693384 Closes: https://bugs.gentoo.org/873160 Closes: https://github.com/gentoo/gentoo/pull/38482 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> x11-drivers/nvidia-drivers/files/nvidia-470.conf | 8 ++-- x11-drivers/nvidia-drivers/files/nvidia-545.conf | 8 ++-- x11-drivers/nvidia-drivers/files/nvidia-555.conf | 8 ++-- .../nvidia-drivers/files/system-sleep.elogind | 7 +++ ....ebuild => nvidia-drivers-470.256.02-r1.ebuild} | 56 ++++++++++++++++++++++ ....ebuild => nvidia-drivers-525.147.05-r1.ebuild} | 56 ++++++++++++++++++++++ ....ebuild => nvidia-drivers-535.183.01-r1.ebuild} | 56 ++++++++++++++++++++++ ....ebuild => nvidia-drivers-550.107.02-r1.ebuild} | 56 ++++++++++++++++++++++ ...1.ebuild => nvidia-drivers-550.40.71-r1.ebuild} | 56 ++++++++++++++++++++++ ...3.ebuild => nvidia-drivers-560.35.03-r1.ebuild} | 56 ++++++++++++++++++++++ 10 files changed, 358 insertions(+), 9 deletions(-)
