Bug 2128910 - NVIDIA Wayland Session Not Available in GDM 43
Summary: NVIDIA Wayland Session Not Available in GDM 43
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 37
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL: https://ask.fedoraproject.org/t/if-th...
Whiteboard:
: 2128818 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-21 22:26 UTC by miles.ramage
Modified: 2022-11-25 21:00 UTC (History)
14 users (show)

Fixed In Version: gdm-43.0-3.fc37
Doc Type: Known Issue
Doc Text:
Cause: The vendor driver provided directly from nvidia fails to suspend and resume out of the box with wayland sessions without manual configuration from the user Consequence: Wayland sessions are removed from the login screen if a non-working configuration is detected Workaround (if any): Install the vendor drivers from rpmfusion which configures the drivers correctly out of the box, or configure the drivers manually following https://download.nvidia.com/XFree86/Linux-x86_64/515.76/README/powermanagement.html Result: Users with misconfigured vendor nvidia drivers will get Xorg sessions out of the box.
Clone Of:
Environment:
Last Closed: 2022-09-30 00:15:28 UTC
Type: Bug


Attachments (Terms of Use)

Description miles.ramage 2022-09-21 22:26:17 UTC
Description of problem:
In the GDM login menu of the Fedora 37 beta, Wayland is no longer an option for laptops with hybrid graphics that are running proprietary NVIDIA drivers.

Version-Release number of selected component (if applicable):
GDM 43.0

How reproducible:
Always

Steps to Reproduce:
1. Try to select a Wayland login session from the GDM menu

Actual results:
Only X11 options are available.

Expected results:
Wayland and X11 sessions should both be available.

Additional info:
Fedora Workstation 37 Beta pushed an upgrade to GDM 43 yesterday (from GDM 42). Part of that upgrade included a change to the "/usr/lib/udev/rules.d/61-gdm.rules" file. In particular, the following lines were added to the udev rules:

> # If this is a hybrid graphics laptop with vendor nvidia driver, disable wayland
> LABEL="gdm_hybrid_nvidia_laptop_check"
> TEST!="/run/udev/gdm-machine-is-laptop", GOTO="gdm_hybrid_nvidia_laptop_check_end"
> TEST!="/run/udev/gdm-machine-has-hybrid-graphics", GOTO="gdm_hybrid_nvidia_laptop_check_end"
> TEST!="/run/udev/gdm-machine-has-vendor-nvidia-driver", GOTO="gdm_hybrid_nvidia_laptop_check_end"
> GOTO="gdm_disable_wayland"
> LABEL="gdm_hybrid_nvidia_laptop_check_end"

Comment 1 Jonathan S. 2022-09-21 22:33:59 UTC
Can confirm. Not only did this change to Xorg, the change to Xorg also lead to multiple regressions to me:

* Touchpad no longer working correctly
* Colors looking wrong
* All graphic output freezing for a second every few seconds
* Moving my mouse cursor suddenly creating coil whine?!

Uncommenting that last GOTO line and hence getting Wayland back fixes all of those.

So if the intention was to make things work "better" by reverting to Xorg, it achieved the opposite.

Comment 2 Luke Jones 2022-09-22 05:27:10 UTC
This is concerning. So much progress has been made on Gnome Wayland that it is by far more beneficial for users to use the wayland session by default, especially as xorg gives a different and reduced-feature experience.

Of the last few ASUS laptops I have been using with Fedora 37, none have had issues with Wayland and in-fact ran very smoothly with it for a vastly superior experience. This includes much better screen handling also - within my discord server I have seen many complaints about xorg being unable to run screens at different refresh rates, while user satisfaction is much better with wayland.

Steam offloading is also fine. We do still see Steam flicking some, but most have preferred to put up with it rather than use xorg.

At this point I think the only negative is Steam. Wayland session is otherwise giving optimus nvidia based laptops a much much better experience overall and feels on par with Windows.

We would like to see Wayland become the default session for nvidia optimus laptops please.

Comment 3 Kalev Lember 2022-09-22 11:31:45 UTC
*** Bug 2128818 has been marked as a duplicate of this bug. ***

Comment 4 Kalev Lember 2022-09-22 11:36:36 UTC
jadahl said on IRC that "nvidia driver can't work good enough with hybrid graphics due to the inability to import buffers from the intel gpu", which makes things very slow when using an external monitor, which is why the default is xorg for now. It should however still be possible to manually choose the wayland session in gdm, despite the login screen is using xorg.

Comment 5 Christian Labisch 2022-09-22 13:40:04 UTC
@Kalev : Setting Xorg as default session is one thing (and okay) ... removing the option to choose Wayland session another thing (and not okay).
I agree with you - "It should however still be possible to manually choose the wayland session in gdm, despite the login screen is using xorg."

Comment 6 Jonas Ådahl 2022-09-22 13:43:45 UTC
Right, the bug is that Wayland isn't an option, not that Xorg is selected by default.

Comment 7 Luke Jones 2022-09-23 00:25:19 UTC
(In reply to Kalev Lember from comment #4)
> jadahl said on IRC that "nvidia driver can't work good enough with hybrid
> graphics due to the inability to import buffers from the intel gpu", which
> makes things very slow when using an external monitor, which is why the
> default is xorg for now. It should however still be possible to manually
> choose the wayland session in gdm, despite the login screen is using xorg.

Gnome + Wayland works perfectly well on hybrid laptops when only the internal screen is used - and it works well enough with external screens that it shouldn't be fully disabled. If users notice any issues they then have the option of using Xorg, rather than users noticing that they are missing features available in Wayland and not having the option to use Wayland at all.

It should not be disabled completely.

> nvidia driver can't work good enough with hybrid
> graphics due to the inability to import buffers from the intel gpu

This doesn't seem correct. There can be a slight stutter which IIRC is due to some roundabout buffer copying (from igpu to dgpu to igpu) but it is definitely usable for daily tasks.

Comment 8 Sjoerd Broekhuijsen 2022-09-23 07:44:08 UTC
> Gnome + Wayland works perfectly well on hybrid laptops when only the internal screen is used - and it works well enough with external screens that it shouldn't be fully disabled. If users notice any issues they then have the option of using Xorg, rather than users noticing that they are missing features available in Wayland and not having the option to use Wayland at all.

Not only does it perfectly well for internal screens, it actually works better (not worse) for a dual monitor setup than Xorg. On my setup Libadwaita applications just freeze on the external screen on Xorg. It's a complete mess when using dual monitors (laptop + external screen), I always assumed it has something to do with Nvidia drivers so went to Wayland and didn't bother. I don't care that much about default settings, but having Wayland disabled by default is a mistake and frankly a surprising decision.

Comment 9 Jonathan S. 2022-09-23 10:28:57 UTC
> "nvidia driver can't work good enough with hybrid graphics due to the inability to import buffers from the intel gpu"

This is partially correct.

a.) This does not affect the internal display at all.
b.) This can be worked around by making the NVIDIA GPU the primary GPU, which in Mutter can be done by adding a tag via a udev rule. E.g. I have an alias that adds this when I want to use an external monitor:

ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary"

With this, the external monitor works perfectly fine with 120 Hz (no 240 due to NVIDIA on Linux not supporting DSC). Granted, though, the internal display remains black then. But it allows a user to switch between internal and external display if they have no desire to use both simultaneously.

> Setting Xorg as default session is one thing (and okay)
> Right, the bug is that Wayland isn't an option, not that Xorg is selected by default.

I would disagree with that. For the vast amount of users, defaulting to Wayland should be fine. I think it would be much better to provide a second login option: "GNOME (Wayland, external display only)" that makes above mentioned udev rule unnecessary.

Also, since it's never a problem in GDM, I'd say GDM should always use Wayland.

> This doesn't seem correct. There can be a slight stutter which IIRC is due to some roundabout buffer copying (from igpu to dgpu to igpu) but it is definitely usable for daily tasks.

Unfortunately this is not correct. It depends on the display attached. If you attach a high resolution display, frame rates can go down to single digits.

The problem is that NVIDIA doesn't support reverse prime yet. I mailed to linux-bugs already, but didn't get a response. Maybe it helps if more people pester them about it. I don't think the solution is to go back to Xorg, the solution is to get NVIDIA to fix the remaining bugs. Especially for Fedora, which is progressive in adopting new things, so Fedora should be the last distro to go back to Xorg.

Comment 10 Sjoerd Broekhuijsen 2022-09-23 11:06:03 UTC
> This can be worked around by making the NVIDIA GPU the primary GPU

Perhaps this is why it works fine on my setup. The HDMI slot to the external monitor is directly coupled to the Nvidia GPU. Again, this works great with Wayland where I use both the internal and external display in extended mode (as one would typically do with two monitors). Neither of the screens go black, and refresh rates (60 Hz on external, 165 Hz on internal) even behave nicely as well. On Xorg on the other hand the same setup is a serious regression, libadwaita applications do not even work at all in Wayland on the external monitor. (They freeze, until I move them over to the internal screen where they work nicely)

Needless to say your mileage may vary depending on the setup (and it obviously does), but why disable it at all if Wayland is the objective better option for many users such as me? It just seems puzzling for a forward-driven distro such as Fedora. Adding more options would make things more complicated and convoluted, but just keep Wayland there as an option so that the users themself can pick whatever works best on their system seems like the obvious choice here. Instead of just assuming it doesn't work on any optimus laptop and disabling it for all, as that is obviously not the case.

Comment 12 Ray Strode [halfline] 2022-09-27 12:59:15 UTC
I honestly think having an option in the UI that doesn't work properly when a monitor is attached isn't an awesome user experience. So, imo, it's better the way it is!

BUT, having said that, this is a change in behavior and we're late in the cycle, so I'll tweak the udev rule to prefer xorg.

Comment 13 Ray Strode [halfline] 2022-09-27 13:29:31 UTC
Sjoerd, your comment is pretty persuasive, and I missed it when writing comment 12. Your comment makes me think we should just keep it wayland by default for f37, since that's what we had in f36, and changing this late has the potential to break users that are happy right now. I've already initiated a build to prefer xorg, but I think I'm going to do another build to just do wayland.

I'd like to get ofourdan and jadahl's take first though.

Comment 14 Olivier Fourdan 2022-09-27 13:42:37 UTC
FWIW, I think it works "fine" thanks to this MR upstream:

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2341

Prior to this, the external monitor could end up entirely blank depending on the hardware, if wired to the discrete GPU, which was not the greatest user experience of all.

Even though it works, it's not fast as this is using the CPU copy path, I guess the actual user experience depends on various factors such a the resolution of the monitor or the actual apps involved (e.g. gaming).

But considering that it should no longer risk a black screen at login, we might as well allow users to chose as they can tell best how that works for them instead of denying Wayland entirely on such setups. Jonas, what do you reckon?

Comment 15 Ray Strode [halfline] 2022-09-27 13:45:07 UTC
Yea I think we all agree at this point the user should be able to pick. I guess the only remaining question is what the default should be.

My take originally was "default to Xorg, let user optionally pick wayland", but after reading comment 12 my take is "default to what we did in f36"

Comment 16 Jonas Ådahl 2022-09-27 13:46:37 UTC
We should definitely allow to pick, and I'm leaning towards agreeing with Ray that we should just default to Wayland, and assume users know how to fall back to Xorg if it's not working well enough. As has been said, it should "work" only with relatively terrible performance.

Comment 17 Ray Strode [halfline] 2022-09-27 13:53:54 UTC
okay i'll do another build that just defaults it to wayland.

Comment 18 Fedora Update System 2022-09-27 14:13:17 UTC
FEDORA-2022-72ebb58b18 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-72ebb58b18

Comment 19 Christian Labisch 2022-09-27 14:35:11 UTC
Thank you @Ray ! FYI : I applied the new build gdm-43.0-3.fc37 ... Wayland is NOT available. I still have to create a modified /etc/udev/rules.d/61-gdm.rules file in order to be able to login to a Wayland session.

Comment 20 Ray Strode [halfline] 2022-09-27 14:58:50 UTC
what's the output of ls /run/udev/gdm* for you?

Comment 21 Ray Strode [halfline] 2022-09-27 15:02:52 UTC
actually i wonder if you're getting hung up on:

# Check if suspend/resume services necessary for working wayland support is available•
TEST{0711}!="/usr/bin/nvidia-sleep.sh", GOTO="gdm_disable_wayland"•
TEST{0711}!="/usr/lib/systemd/system-sleep/nvidia", GOTO="gdm_disable_wayland"•
IMPORT{program}="/bin/sh -c \"sed -e 's/: /=/g' -e 's/\([^[:upper:]]\)\([[:upper:]]\)/\1_\2/g' -e 's/[[:lower:]]/\U&/g' -e 's/^/NVIDIA_/' /proc/driver/nvidia/params\""•
ENV{NVIDIA_PRESERVE_VIDEO_MEMORY_ALLOCATIONS}!="1", GOTO="gdm_disable_wayland"•
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"•
LABEL="gdm_nvidia_end"•
•

In other words, wayland might be getting disabled because the machine would tank if you suspend and resumed ?

Can you tell me the output of:

# cat /proc/driver/nvidia/params
# ls -l /usr/bin/nvidia-sleep.sh /usr/lib/systemd/system-sleep/nvidia

?

Comment 22 Christian Labisch 2022-09-27 15:10:17 UTC
(In reply to Ray Strode [halfline] from comment #20)
> what's the output of ls /run/udev/gdm* for you?

$ ls /run/udev/gdm*
/run/udev/gdm-machine-has-hardware-gpu  /run/udev/gdm-machine-has-vendor-nvidia-driver  /run/udev/gdm-machine-is-laptop

(In reply to Ray Strode [halfline] from comment #21)
> actually i wonder if you're getting hung up on:
> 
> # Check if suspend/resume services necessary for working wayland support is
> available•
> TEST{0711}!="/usr/bin/nvidia-sleep.sh", GOTO="gdm_disable_wayland"•
> TEST{0711}!="/usr/lib/systemd/system-sleep/nvidia",
> GOTO="gdm_disable_wayland"•
> IMPORT{program}="/bin/sh -c \"sed -e 's/: /=/g' -e
> 's/\([^[:upper:]]\)\([[:upper:]]\)/\1_\2/g' -e 's/[[:lower:]]/\U&/g' -e
> 's/^/NVIDIA_/' /proc/driver/nvidia/params\""•
> ENV{NVIDIA_PRESERVE_VIDEO_MEMORY_ALLOCATIONS}!="1",
> GOTO="gdm_disable_wayland"•
> 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"•
> LABEL="gdm_nvidia_end"•
> •
> 
> In other words, wayland might be getting disabled because the machine would
> tank if you suspend and resumed ?
> 
> Can you tell me the output of:
> 
> # cat /proc/driver/nvidia/params
> # ls -l /usr/bin/nvidia-sleep.sh /usr/lib/systemd/system-sleep/nvidia
> 
> ?

$ cat /proc/driver/nvidia/params
ResmanDebugLevel: 4294967295
RmLogonRC: 1
ModifyDeviceFiles: 1
DeviceFileUID: 0
DeviceFileGID: 0
DeviceFileMode: 438
InitializeSystemMemoryAllocations: 1
UsePageAttributeTable: 4294967295
EnableMSI: 1
EnablePCIeGen3: 0
MemoryPoolSize: 0
KMallocHeapMaxSize: 0
VMallocHeapMaxSize: 0
IgnoreMMIOCheck: 0
TCEBypassMode: 0
EnableStreamMemOPs: 0
EnableUserNUMAManagement: 1
NvLinkDisable: 0
RmProfilingAdminOnly: 1
PreserveVideoMemoryAllocations: 0
EnableS0ixPowerManagement: 0
S0ixPowerManagementVideoMemoryThreshold: 256
DynamicPowerManagement: 3
DynamicPowerManagementVideoMemoryThreshold: 200
RegisterPCIDriver: 1
EnablePCIERelaxedOrderingMode: 0
EnableGpuFirmware: 18
EnableGpuFirmwareLogs: 2
EnableDbgBreakpoint: 0
OpenRmEnableUnsupportedGpus: 0
DmaRemapPeerMmio: 1
RegistryDwords: ""
RegistryDwordsPerDevice: ""
RmMsg: ""
GpuBlacklist: ""
TemporaryFilePath: ""
ExcludedGpus: ""

$ ls -l /usr/bin/nvidia-sleep.sh /usr/lib/systemd/system-sleep/nvidia
-rwxr-xr-x. 1 root root 900 27. Sep 13:46 /usr/bin/nvidia-sleep.sh
-rwxr-xr-x. 1 root root  92 27. Sep 13:46 /usr/lib/systemd/system-sleep/nvidia

Comment 23 Ray Strode [halfline] 2022-09-27 15:13:34 UTC
> PreserveVideoMemoryAllocations: 0

So that's the issue. Your driver isn't configured correctly, so it doesn't work with suspend/resume. Do you remember how you initially installed it?

Comment 24 Christian Labisch 2022-09-27 15:20:10 UTC
(In reply to Ray Strode [halfline] from comment #23)
> > PreserveVideoMemoryAllocations: 0
> 
> So that's the issue. Your driver isn't configured correctly, so it doesn't
> work with suspend/resume. Do you remember how you initially installed it?

I installed it by using the NVIDIA-Linux-x86_64-515.76.run file ... it worked perfectly fine on Fedora 36 Workstation.

Comment 25 Christian Labisch 2022-09-27 15:40:05 UTC
(In reply to Ray Strode [halfline] from comment #23)
> > PreserveVideoMemoryAllocations: 0
> 
> So that's the issue. Your driver isn't configured correctly, so it doesn't
> work with suspend/resume. Do you remember how you initially installed it?

I tested if downgrading to gdm-42.0-2.fc36.x86_64 brings back the old behavior ... and it did ... I am on Wayland now.

Comment 26 Christian Labisch 2022-09-27 15:56:02 UTC
(In reply to Ray Strode [halfline] from comment #23)
> > PreserveVideoMemoryAllocations: 0
> 
> So that's the issue. Your driver isn't configured correctly, so it doesn't
> work with suspend/resume. Do you remember how you initially installed it?

I ran another test : I uninstalled the original NVIDIA drivers, upgraded to gdm-43.0-3.fc37 again, and then installed the same drivers version from RPM Fusion (testing).
Seems that made a difference - the GDM login selection menu is present and defaults to Wayland. cat /proc/driver/nvidia/params gives InitializeSystemMemoryAllocations: 1

Comment 27 Christian Labisch 2022-09-27 16:05:04 UTC
(In reply to Ray Strode [halfline] from comment #23)
> > PreserveVideoMemoryAllocations: 0
> 
> So that's the issue. Your driver isn't configured correctly, so it doesn't
> work with suspend/resume. Do you remember how you initially installed it?

Sorry Ray, I made a typo (InitializeSystemMemoryAllocations) - I wanted to inform you that cat /proc/driver/nvidia/params gives me PreserveVideoMemoryAllocations: 1 now.

Comment 28 Ray Strode [halfline] 2022-09-27 16:52:21 UTC
hmm, so the question is, what's the best way forward here? To summarize, 

- Installing the vendor drivers directly from NVIDIA leads to broken suspend/resume out of the box on wayland. It needs manual re-configuration from the user for suspend/resume to work. F36 just lived with that breakage, users didn't get functioning resume and probably didn't know why, F37, as it stands, detects the misconfiguration and hides wayland from the menus.

Possible options:

1. Go back to F36 behavior
2. Keep current behavior of hiding wayland and maybe add a release note?
3. Prefer Xorg if the driver is misconfigured but still allow the user to pick wayland and have their system break when they suspend ?
4. ??

I'm currently leaning toward 2, but am curious what takes other people have.

Comment 29 Jonathan S. 2022-09-27 17:03:32 UTC Comment hidden (obsolete)
Comment 30 Jonathan S. 2022-09-27 17:07:04 UTC Comment hidden (obsolete)
Comment 31 Ray Strode [halfline] 2022-09-27 17:21:00 UTC Comment hidden (obsolete)
Comment 32 Jonathan S. 2022-09-27 17:22:32 UTC Comment hidden (obsolete)
Comment 33 Christian Labisch 2022-09-27 17:30:16 UTC
(In reply to Ray Strode [halfline] from comment #28)
> hmm, so the question is, what's the best way forward here? To summarize, 
> 
> - Installing the vendor drivers directly from NVIDIA leads to broken
> suspend/resume out of the box on wayland. It needs manual re-configuration
> from the user for suspend/resume to work. F36 just lived with that breakage,
> users didn't get functioning resume and probably didn't know why, F37, as it
> stands, detects the misconfiguration and hides wayland from the menus.
> 
> Possible options:
> 
> 1. Go back to F36 behavior
> 2. Keep current behavior of hiding wayland and maybe add a release note?
> 3. Prefer Xorg if the driver is misconfigured but still allow the user to
> pick wayland and have their system break when they suspend ?
> 4. ??
> 
> I'm currently leaning toward 2, but am curious what takes other people have.

gdm-43.0-3.fc37 works as expected with the drivers from RPM Fusion (what's most important), so I suggest to stick with the settings being provided in the gdm-43.0-3.fc37 package.
If someone installs the original NVIDIA drivers, Wayland is disabled (what's we have to live with then). In this case the user will have to find a solution or workaround himself.

Comment 35 Ray Strode [halfline] 2022-09-27 17:55:59 UTC
I'd also appreciate karma in the update from anyone affected by this issue

Comment 36 Luke Jones 2022-09-27 20:19:28 UTC
(In reply to Ray Strode [halfline] from comment #28)
> hmm, so the question is, what's the best way forward here? To summarize, 
> 
> - Installing the vendor drivers directly from NVIDIA leads to broken
> suspend/resume out of the box on wayland. It needs manual re-configuration
> from the user for suspend/resume to work. F36 just lived with that breakage,
> users didn't get functioning resume and probably didn't know why, F37, as it
> stands, detects the misconfiguration and hides wayland from the menus.
> 
> Possible options:
> 
> 1. Go back to F36 behavior
> 2. Keep current behavior of hiding wayland and maybe add a release note?
> 3. Prefer Xorg if the driver is misconfigured but still allow the user to
> pick wayland and have their system break when they suspend ?
> 4. ??
> 
> I'm currently leaning toward 2, but am curious what takes other people have.

Please prefer option 3.

The reason I suggest this is that a great many Optimus laptops have two output options:
1. An output wired to dGPU
2. An output wired to iGPU

In the case of users using the iGPU output, Wayland works amazingly well, and Nvidia can be pushed to fix the remaining issues for dGPU wired output.

Myself and many other users would prefer that the user experience of using Wayland with iGPU wired output not be hampered thanks to Nvidia not being fully up to scratch (and they are nearly there).

And there is of course the case where Nvidia outputs do work mostly fine for many folk. This is especially true of gaming exclusive fullscreen I believe?

Comment 37 Christian Labisch 2022-09-28 09:10:54 UTC
(In reply to Ray Strode [halfline] from comment #35)
> I'd also appreciate karma in the update from anyone affected by this issue

Done ! :)

Comment 38 Christian Labisch 2022-09-28 10:15:08 UTC
I think using the settings in gdm-43.0-3.fc37 are providing the best and safest experience.
Everything works as expected with the original NVIDIA drivers after applying this "tweak" :

sudo nano /etc/modprobe.d/nvidia.conf

options nvidia "NVreg_PreserveVideoMemoryAllocations=1"

$ cat /proc/driver/nvidia/params
ResmanDebugLevel: 4294967295
RmLogonRC: 1
ModifyDeviceFiles: 1
DeviceFileUID: 0
DeviceFileGID: 0
DeviceFileMode: 438
InitializeSystemMemoryAllocations: 1
UsePageAttributeTable: 4294967295
EnableMSI: 1
EnablePCIeGen3: 0
MemoryPoolSize: 0
KMallocHeapMaxSize: 0
VMallocHeapMaxSize: 0
IgnoreMMIOCheck: 0
TCEBypassMode: 0
EnableStreamMemOPs: 0
EnableUserNUMAManagement: 1
NvLinkDisable: 0
RmProfilingAdminOnly: 1
PreserveVideoMemoryAllocations: 1
EnableS0ixPowerManagement: 0
S0ixPowerManagementVideoMemoryThreshold: 256
DynamicPowerManagement: 3
DynamicPowerManagementVideoMemoryThreshold: 200
RegisterPCIDriver: 1
EnablePCIERelaxedOrderingMode: 0
EnableGpuFirmware: 18
EnableGpuFirmwareLogs: 2
EnableDbgBreakpoint: 0
OpenRmEnableUnsupportedGpus: 0
DmaRemapPeerMmio: 1
RegistryDwords: ""
RegistryDwordsPerDevice: ""
RmMsg: ""
GpuBlacklist: ""
TemporaryFilePath: ""
ExcludedGpus: ""

Comment 39 Fedora Update System 2022-09-28 12:20:06 UTC
FEDORA-2022-72ebb58b18 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-72ebb58b18`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-72ebb58b18

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 40 Ray Strode [halfline] 2022-09-28 12:58:34 UTC
(In reply to Luke Jones from comment #36) 
> Please prefer option 3.

To be clear, we're going to default to wayland for hybrid graphics laptops with a properly configured vendor nvidia driver. That was decided in comment 17.

This is just about what to do if a user installs the nvidia driver from nvidia.org instead of rpmfusion and doesn't do the post installation configuration that's required to fix suspend/resume.

We've settled on option 2 now: don't show wayland on the login screen if the system is going to break when the user shuts the lid because of a misconfiguration

I don't think we should revisit, but now that you understand that the lion's share of vendor nvidia hybrid graphics users on fedora (who get their driver packaged as an rpm that does the post installation configuration for them) will continue to get wayland, just as they did in f36, does that alay your concerns?

Comment 41 miles.ramage 2022-09-28 22:02:18 UTC
Just saw the `gdm` update (to `gdm-43.0-3.fc37.src.rpm`) in the Fedora 37 Beta. My original issue has been fixed with this update. Great work, folks! I think we can close this issue now.

Comment 42 Fedora Update System 2022-09-30 00:15:28 UTC
FEDORA-2022-72ebb58b18 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 43 cwize1 2022-11-25 21:00:37 UTC
FYI: I ran into an issue where even though I had the rpmfusion nvidia drivers installed, GNOME was still defaulting to x11 under Fedora 37. (Under Fedora 36 it defaulted to Wayland.) And unfortunately, this resulted in applications becoming slideshows on secondary monitors connected via DisplayPort. The behavior was the same in both hybrid graphics mode and discrete graphics mode. (My machine is a Lenovo Legion 5 Pro 16ACH6H which has AMD Ryzen 5800H + integrated Radeon graphics + NVIDIA RTX 3060.)

Fortunately, uninstalling and reinstalling the rpmfusion NVIDIA drivers fixed the problem.

(Just leaving this comment in case someone else hit the same issue I did.)


Note You need to log in before you can comment on or make changes to this bug.