Phantom "Unknown Display" shown in Settings after installing the Nvidia driver

[Daniel van Vugt]

[ Impact ]

After installing Nvidia driver 545 on a single (27") monitor system, Settings shows a phantom 46" monitor of the same resolution.

It looks like the phantom monitor is /dev/dri/card0 which is still controlled by simpledrm, while Nvidia uses /dev/dri/card1.

This also seems to be triggering bug 2062426 and bug 2066126.

[ Temporary Workaround ]

1. sudo rm /dev/dri/card0
2. Log in again.

[ Permanent Workaround ]

Add kernel parameter: initcall_blacklist=simpledrm_platform_driver_init

[ Test Plan ]

Open Settings and verify the only monitors shown are your real monitors.

[ Where problems could occur ]

Removing the simpledrm card is only safe when it's not being used. If somehow a machine wasn't using the installed Nvidia driver then there could be a risk of deleting the only working display.

[ Other Info ]

ProblemType: Bug
ApportVersion: 2.28.0-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/seq: dan 4631 F.... pipewire
 /dev/snd/controlC1: dan 4636 F.... wireplumber
CRDA: N/A
CasperMD5CheckResult: pass
DistroRelease: Ubuntu 24.04
InstallationDate: Installed on 2024-01-04 (92 days ago)
InstallationMedia: Ubuntu 24.04 "Noble Numbat" - Daily amd64 (20231127)
MachineType: Intel(R) Client Systems NUC12DCMi7
NonfreeKernelModules: nvidia_modeset nvidia
Package: linux (not installed)
ProcEnviron:
 LANG=en_US.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
ProcFB: 0 simpledrmdrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-11-generic root=UUID=8434774e-88f2-4e3f-adb8-2eb07dff3cf9 ro quiet loglevel=3 splash vt.handoff=7
ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4
RelatedPackageVersions:
 linux-restricted-modules-6.8.0-11-generic N/A
 linux-backports-modules-6.8.0-11-generic N/A
 linux-firmware 20240318.git3b128b60-0ubuntu1
Tags: noble
Uname: Linux 6.8.0-11-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sudo users
_MarkForUpload: True
dmi.bios.date: 12/20/2021
dmi.bios.release: 5.24
dmi.bios.vendor: Intel Corp.
dmi.bios.version: EDADL579.0046.2021.1220.2351
dmi.board.name: NUC12EDBi7
dmi.board.vendor: Intel Corporation
dmi.board.version: M27908-302
dmi.chassis.type: 35
dmi.chassis.vendor: Intel Corporation
dmi.chassis.version: 2.0
dmi.ec.firmware.release: 3.7
dmi.modalias: dmi:bvnIntelCorp.:bvrEDADL579.0046.2021.1220.2351:bd12/20/2021:br5.24:efr3.7:svnIntel(R)ClientSystems:pnNUC12DCMi7:pvrM30143-302:rvnIntelCorporation:rnNUC12EDBi7:rvrM27908-302:cvnIntelCorporation:ct35:cvr2.0:skuRNUC12DCMi70000:
dmi.product.family: DC
dmi.product.name: NUC12DCMi7
dmi.product.sku: RNUC12DCMi70000
dmi.product.version: M30143-302
dmi.sys.vendor: Intel(R) Client Systems

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

apport information

[Daniel van Vugt (vanvugt)]

It looks like i915 avoids this by deleting /dev/dri/card0 (simpledrm) after /dev/dri/card1 (i915) exists. Although I don't really know exactly where that's implemented.

[Mario Limonciello (superm1)]

Probably nvidia.ko is missing a call to drm_aperture_remove_conflicting_pci_framebuffers()

[Daniel van Vugt (vanvugt)]

There's probably nothing to do in the kernel task here.

[Daniel van Vugt (vanvugt)]

I'm guessing this might also be the cause of the oversized panning login screen I get with Nvidia 470?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

If you're careful you can just delete /dev/dri/card0 to work around it :)

[Cristiano Fraga G. Nunes (cfgnunes)]

I recently installed Ubuntu 24.04 for testing purposes and have encountered the same issue:

The 'Displays' configuration indicates the presence of three monitors, like this:
1) Dell Inc. 27"
2) Dell Inc. 27"
3) Unknown Display
However, I only have two displays and not a third one.

When moving the cursor to the extreme right corner of the screen, the entire display shifts to the right.

My configuration:
- Utilizing: two monitors
- Graphics Card: NVIDIA GeForce GTX 1660 SUPER
- Environment: Xorg
- Driver Version: Nvidia driver 535.161.07

[Cristiano Fraga G. Nunes (cfgnunes)]

More information: listing the display outputs:

$ find /sys/devices -name "edid"

/sys/devices/platform/simple-framebuffer.0/drm/card0/card0-Unknown-1/edid
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card2/card2-DP-2/edid
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card2/card2-DVI-D-1/edid
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card2/card2-HDMI-A-3/edid
/sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1-HDMI-A-1/edid
/sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1-HDMI-A-2/edid
/sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-1/edid

I've tried to delete the /dev/dri/card0 with:
$ sudo rm -f /dev/dri/card0

But this workaround not worked for me.

[Michel Hanzen (papymichmich)]

Same problem with Nvidia driver 535.171.04 on Ubuntu 24.04

[Momo77 (zeronoid)]

I upgraded from 23.10 to 24.04 and I have the same issues plus other problems:
+Two monitors designated as Unknown display (I use one).
+most gnome apps (like Setting, alert message) don't render the characters as in https://askubuntu.com/questions/1511575/ubuntu-24-04-screen-glitches-on-gnome-apps-after-install
+The resolution is stuck at 1024*768 but I could change it in NVIDIA x server setting but it is reset after restart
+Only 470 works on my gt710

[Alexandre Hen (atropine07)]

Same problem for me on Ubuntu 24.04 fresh install on X11 AND on Wayland.

I tried updating my nvidia driver to nvidia-driver-550, but I keep getting this "phantom" monitor in Gnome settings.

I have two physical monitors :
- Main one : AOC 27" AG271QG with G-Sync
- Other one : Dell 25"

$ find /sys/devices -name "edid"
/sys/devices/platform/simple-framebuffer.0/drm/card0/card0-Unknown-1/edid
/sys/devices/pci0000:00/0000:00:03.1/0000:0e:00.0/drm/card1/card1-HDMI-A-1/edid
/sys/devices/pci0000:00/0000:00:03.1/0000:0e:00.0/drm/card1/card1-DP-2/edid
/sys/devices/pci0000:00/0000:00:03.1/0000:0e:00.0/drm/card1/card1-Unknown-2/edid
/sys/devices/pci0000:00/0000:00:03.1/0000:0e:00.0/drm/card1/card1-DP-3/edid
/sys/devices/pci0000:00/0000:00:03.1/0000:0e:00.0/drm/card1/card1-DP-1/edid

[ Workaround ]
I type in terminal : sudo rm -f /dev/dri/card0

*After relogin : Phantom monitor has disappeared, but I lost my monitors' configuration (Main becoming second and vice versa, losing refresh rate too for the AOC).
No sign of the phantom screen in Gnome settings.

/dev/dri$ ls -l
total 0
drwxr-xr-x 2 root root 100 avril 28 14:52 by-path
crw-rw----+ 1 root video 226, 1 avril 28 14:52 card1
crw-rw----+ 1 root render 226, 128 avril 28 14:52 renderD128

I set my monitors like before (refresh rate at 144Hz and main monitor for the AOC), and reboot.

* After rebooting : phantom monitor is there again in Gnome settings. I kept my monitors' configuration.

/dev/dri$ ls -l
total 0
drwxr-xr-x 2 root root 100 avril 28 15:21 by-path
crw-rw----+ 1 root video 226, 0 avril 28 15:21 card0
crw-rw----+ 1 root video 226, 1 avril 28 15:21 card1
crw-rw----+ 1 root render 226, 128 avril 28 15:21 renderD128

Other informations about my PC :

# Rapport d’informations du système
---

## Détails du compte rendu
- **Date de génération :** 2024-04-28 15:07:02

## Informations liées au matériel :
- **Modèle du matériel :** ASRock X570 Taichi
- **Mémoire :** 32,0 Gio
- **Processeur :** AMD Ryzen™ 7 5800X3D × 16
- **Carte graphique :** NVIDIA GeForce RTX™ 2080
- **Capacité du disque :** 8,5 To

## Informations liées au logiciel :
- **Version du micrologiciel :** P5.01
- **Nom du système d’exploitation :** Ubuntu 24.04 LTS
- **Construction du système d’exploitation :** (null)
- **Type de système d’exploitation :** 64 bits
- **Version de GNOME :** 46
- **Système de fenêtrage :** X11
- **Version du noyau :** Linux 6.8.0-31-generic

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Per Overgaard (perove1980)]

Another Workaround:
I believe this is the simpledrm driver not asking for the conflicting framebuffers to be unregistered.
You can try to add "initcall_blacklist=simpledrm_platform_driver_init" to your kernel command line parameters to make sure the simpledrm driver is not loading on boot.

Add to your kernel command line like this. Open your terminal:
sudo nano /etc/default/grub
add "initcall_blacklist=simpledrm_platform_driver_init" to where it says GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash", so it looks like this:
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash initcall_blacklist=simpledrm_platform_driver_init”
ctrl+O for save and ctrl+X for quit. Back in the terminal write:
sudo update-grub
reboot

This fixed the issue for me.

[Miguel Elias Machado (miguelemachado)]

> GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash initcall_blacklist=simpledrm_platform_driver_init”

This workaround worket for me too.

Thanks.

[leviatan89 (leviatan-89)]

Have the same issue. Fresh install of Ubuntu 24.04. Happening, at least, with Xorg.
NVIDIA Driver Version: 535.171.04
Graphic card: NVIDIA GeForce RTX 3060

Can give more information if useful. Just let me know guys what is relevant to add to this comment.

Cheers.

[Per Overgaard (perove1980)]

levitan89: Read my comment #32

[Chris Hermansen (c-hermansen)]

On 24.04 with NVIDIA GTX 3060 and Samsung 5120 X 1440 monitor, running libnvidia 535.171.04-0ubuntu2

Following Per Overgaard's excellent instructive, the

> GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash initcall_blacklist=simpledrm_platform_driver_init”

solution works for me to eliminate the "ghost monitor".

[Jhonny Oliveira (jhonny-oliveira)]

The proposed workaround works, but I use full disk encryption and the unlock screen doesn't show up anymore. As a workaround, after switching on the computer, I wait a few seconds, blindly type the password and the system boots successfully.

Any ideas on how to restore the visibility of the disk encryption unlock screen?

[Peter Würtz (pwuertz)]

Isn't this also a Gnome settings bug? Even with the presence of an erroneously detected extra monitor, shouldn't we be able to simply deactivate it / configure the desktop to not span across both monitors?

The Settings > Displays GUI doesn't seem to work correctly. The "Unknown" monitor is reported as being inactive, although we can see the effects of e.g. the mouse pointer getting lost on the right. Activating/deactivating the "Unknown" monitor also doesn't work.

[Noam Mor (noam-mor)]

Regarding the severity of this bug - if I turn off the monitor, Ubuntu switches to my second (non-existing) monitor, and when I turn the monitor back on, gnome crashes and forces me to logout. I *had* to apply the workaround to avoid constant crashes and forced logouts.

[Daniel van Vugt (vanvugt)]

I believe this bug is causing annoying side effects such as bug 2066126 and bug 2065791.

[DrShushen (dr-shushen)]

I experience a similar severe problem to what Noam Mor (noam-mor) has mentioned above.

In fact, in my case, since I use a monitor switch to switch screens between two machines, every time I switch back to my Ubuntu computer, Gnome crashes, and I have to re-login. Usually losing all my work in the process.

[Daniel van Vugt (vanvugt)]

Please report crashes in new bugs, not here. You can follow the steps in https://wiki.ubuntu.com/Bugs/Responses#Missing_a_crash_report_or_having_a_.crash_attachment

[Luuk Perdaems (luukp)]

The solution of Per Overgaard also eliminated the ghost monitor for me - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060268/comments/32
After applying the solution, I also had to blindly apply my disk encryption password - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060268/comments/37

[Cpuccino (cpuccino)]

> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash initcall_blacklist=simpledrm_platform_driver_init"

This seems to have fixed https://bugs.launchpad.net/ubuntu/+bug/2068849 for me "Ubuntu 24.04 crashes to login screen when display turns off"

[leviatan89 (leviatan-89)]

I also have encryption, does everyone with the bug have it?

[Sidney Kelley (memtha)]

> I also have encryption, does everyone with the bug have it?

Nope. I just got my bug marked duplicate here. I am not running encryption, but I am running ZFS, which uses a vaguely similar disk abstraction (booting a "fake" device that "maps" to a real one in some arbitrary way).

However, my bug was solved when I installed kubuntu-desktop (and then switched the default display manager back to gdm3). So, I assume one of the dependencies it brought along fixed it.

[Kostya Vasilyev (kmansoft)]

I'm not using encryption or zfs and the bug has been present since the beta

On Sun, Jun 16, 2024, 9:05 PM Sidney Kelley <email address hidden>
wrote:

> > I also have encryption, does everyone with the bug have it?
>
>
> Nope. I just got my bug marked duplicate here. I am not running
> encryption, but I am running ZFS, which uses a vaguely similar disk
> abstraction (booting a "fake" device that "maps" to a real one in some
> arbitrary way).
>
> However, my bug was solved when I installed kubuntu-desktop (and then
> switched the default display manager back to gdm3). So, I assume one of
> the dependencies it brought along fixed it.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (2063222).
> https://bugs.launchpad.net/bugs/2060268
>
> Title:
> Phantom "Unknown Display" shown in Settings after installing the
> Nvidia driver
>
> Status in linux package in Ubuntu:
> Confirmed
> Status in nvidia-graphics-drivers-470 package in Ubuntu:
> Confirmed
> Status in nvidia-graphics-drivers-535 package in Ubuntu:
> Confirmed
> Status in nvidia-graphics-drivers-545 package in Ubuntu:
> Confirmed
> Status in nvidia-graphics-drivers-550 package in Ubuntu:
> Confirmed
>
> Bug description:
> [ Impact ]
>
> After installing Nvidia driver 545 on a single (27") monitor system,
> Settings shows a phantom 46" monitor of the same resolution.
>
> It looks like the phantom monitor is /dev/dri/card0 which is still
> controlled by simpledrm, while Nvidia uses /dev/dri/card1.
>
> [ Temporary Workaround ]
>
> 1. sudo rm /dev/dri/card0
> 2. Log in again.
>
> [ Permanent Workaround ]
>
> Add kernel parameter:
> initcall_blacklist=simpledrm_platform_driver_init
>
> [ Test Plan ]
>
> Open Settings and verify the only monitors shown are your real
> monitors.
>
> [ Where problems could occur ]
>
> Removing the simpledrm card is only safe when it's not being used. If
> somehow a machine wasn't using the installed Nvidia driver then there
> could be a risk of deleting the only working display.
>
> [ Other Info ]
>
> ProblemType: Bug
> ApportVersion: 2.28.0-0ubuntu1
> Architecture: amd64
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/seq: dan 4631 F.... pipewire
> /dev/snd/controlC1: dan 4636 F.... wireplumber
> CRDA: N/A
> CasperMD5CheckResult: pass
> DistroRelease: Ubuntu 24.04
> InstallationDate: Installed on 2024-01-04 (92 days ago)
> InstallationMedia: Ubuntu 24.04 "Noble Numbat" - Daily amd64 (20231127)
> MachineType: Intel(R) Client Systems NUC12DCMi7
> NonfreeKernelModules: nvidia_modeset nvidia
> Package: linux (not installed)
> ProcEnviron:
> LANG=en_US.UTF-8
> PATH=(custom, no user)
> SHELL=/bin/bash
> TERM=xterm-256color
> XDG_RUNTIME_DIR=<set>
> ProcFB: 0 simpledrmdrmfb
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-11-generic
> root=UUID=8434774e-88f2-4e3f-adb8-2eb07dff3cf9 ro quiet loglevel=3 splash
> vt.handoff=7
> ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4
> RelatedPackageVersions:
> linux-restricted-modules-6.8.0-11-generic N/A
> li...

[Mario Limonciello (superm1)]

#46:

That's this bug:

https://bugs.launchpad.net/ubuntu/+source/sddm/+bug/2063143

[Daniel van Vugt (vanvugt)]

No, #46 was bug 2069477

[MeduZa (meduzapat)]

Affecting my system:
Ubuntu 24.04 fresh install nvidia 3070ti with drivers 550.

Following Per Overgaard's excellent instructive, the

> GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash initcall_blacklist=simpledrm_platform_driver_init”

solution works for me to eliminate the "ghost monitor".

[Alessandro Astone (aleasto)]

== History ==
Prior to nvidia 545 the driver did not provide a framebuffer and instead relied on framebuffers from CONFIG_EFI_FB and CONFIG_VESA_FB alike.

SimpleDRM (required on a modern Wayland-only system) can also provide a framebuffer (simplefb), and indeed Ubuntu does not use EFI_FB and VESA_FB anymore, relying purely on SimpleDRM to provide a fallback framebuffer. However SimpleDRM also provides a DRM device which creates this phantom display.

Since nvidia 545, the driver has gained the capability to provide a framebuffer device, currently opt-in with the option `nvidia-drm.fbdev=1`. Enabling this makes SimpleDRM go away like it would with amdgpu or i915 (*currently racy, see [1]).

== Solutions ==
1. The first option is to enable fbdev=1 by default, like we do for nvidia-drm.modeset=1.
This is still considered to be in test-stage by nvidia, and unfortunately on my Ubuntu machine it breaks any graphical session with bug [2]. NB: somehow this bug does not happen on my Fedora install, where fbdev=1 is already the default.

2. Prior to having the nvidia-drm.fbdev option in Fedora we would instead disable SimpleDRM if-and-only-if the nvidia driver is installed. You may achieve this either by appending `initcall_blacklist=simpledrm_platform_driver_init` to the kernel commandline through a package install-time script, or through a patch like [3]. But we are now left with no framebuffer device, so switching VT leaves you with a black screen (imho unacceptable). The solution to that issue is to enable CONFIG_EFI_FB/CONFIG_VESA_FB again so that nvidia systems will keep access to VTs, albeit low-res ones compared to simplefb.

[1]: https://bugs.launchpad.net/ubuntu/+source/sddm/+bug/2063143
[2]: https://forums.developer.nvidia.com/t/545-29-06-18-1-flip-event-timeout-error-on-startup-shutdown-and-sometimes-suspend-wayland-unusable/274788
[3]: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1788/diffs

[Daniel van Vugt (vanvugt)]

Solution 1 sounds preferable. Being considered in test by Nvidia is fine, because so is Wayland support. It would be a shame if we couldn't fix the 535 driver though...

The other thing to consider is what framebuffer drivers are available to squeeze into initrd. You need something there to support those desktops with encrypted disks so as to be able to display the password prompt. I think I've seen in the past that copying the entire Nvidia driver into initrd was an option, albeit very large.

I'm also nervous that CONFIG_EFI_FB/CONFIG_VESA_FB would cause us to regress on bug 1970069.

[Alessandro Astone (aleasto)]

Apparently I can use fbdev=1 without hitting the bug at https://forums.developer.nvidia.com/t/545-29-06-18-1-flip-event-timeout-error-on-startup-shutdown-and-sometimes-suspend-wayland-unusable/274788 if I delay the startup of gdm with:

Wants=systemd-udev-settle.service
After=systemd-udev-settle.service

That is still different than 2063143 because the bug occurs even if I disable simpledrm.

[Daniel van Vugt (vanvugt)]

I do expect the same issue as bug 2063143 can occur in other display managers, but was under the impression that gdm already waited for settling. Some quick grepping reveals that gdm tries to do it manually:

https://gitlab.gnome.org/GNOME/gdm/-/blob/main/daemon/gdm-local-display-factory.c?ref_type=heads#L663

[Daniel van Vugt (vanvugt)]

Medium priority at least. This also seems to be triggering bug 2062426 and bug 2066126.

[Jan Hartkopf (jhartkopf)]

FWIW, this bug caused G-SYNC to not work in games for me (the G-SYNC indicator said NORMAL instead of G-SYNC), while nvidia-settings reported G-SYNC was active. Using the kernel parameter resolved this issue and also the "unknown display" went away.

However, this must be caused by a recent change to my system because G-SYNC was working fine before without using the kernel param. Unfortunately, I did not find out yet which change exactly caused G-SYNC to stop working.

[Alessandro Astone (aleasto)]

Status update from me.

The hang with nvidia-drm.fbdev=1 is caused by gpu-manager.service which is:
WantedBy=display-manager.service
Before=display-manager.service

In my previous testing delaying gdm.service with udev-settle really just caused to delay gpu-manager.service which fixes this issue.

I'm now thinking that gpu-manager.service is also the cause of bug 2063143.

It also explains why I don't hit any of these bugs in Fedora, as gpu-manager.service is only shipped in ubuntu: https://github.com/canonical/ubuntu-drivers-common/blob/master/share/hybrid/gpu-manager.c

[Alessandro Astone (aleasto)]

With this workaround https://github.com/canonical/ubuntu-drivers-common/pull/100 we can enable nvidia-drm.fbdev=1 and solve this bug for nvidia >=550

How do you want to handle 470 and 535?

[Daniel van Vugt (vanvugt)]

> How do you want to handle 470 and 535?

There are even more options than mentioned in #51...

(a) Install initcall_blacklist=simpledrm_platform_driver_init with the Nvidia driver.

(b) Patch everyone's kernels like Red Hat did. This is probably the worst option and least likely to be approved.

(c) Build all FB drivers as modules, something like:
    FB_EFI=m
    FB_VESA=m
    CONFIG_SYSFB_SIMPLEFB=y
    CONFIG_DRM_SIMPLEDRM=m
    Then put simpledrm in the initramfs default modules list and Nvidia drivers can reconfigure their preferred one.

(d) Delete /dev/dri/card0 during startup (in systemd scripts or maybe gdm) if you're sure card0 is simpledrm and that nvidia-drm is now up and running on card1.

(e) Can (d) be implemented purely as udev rules??

---

(a), (b) and (c) all have the risk that CONFIG_EFI_FB/CONFIG_VESA_FB might regress on bug 1970069. Not sure... So I'm wondering if there are any risks to option (d) given it would be entirely confined to the 470 and 535 Nvidia drivers.

[Daniel van Vugt (vanvugt)]

Although deleting /dev/dri/card0 sounds kludgy, it's actually better than the alternatives.

* Deleting /dev/dri/card0:
  - VTs keep working
  - bug is fixed for all display servers

* Unbinding the simple-framebuffer udev device:
  - VTs stop working
  - bug is fixed for all display servers

* Adding udev TAG+="mutter-device-ignore" to simpledrm:
  - VTs keep working
  - bug is fixed for Mutter/GNOME Wayland sessions only (Xorg issues like bug 2066126 aren't fixed)

[Daniel van Vugt (vanvugt)]

I think I've got a general solution. Add this to the bottom of /usr/lib/udev/rules.d/71-nvidia.rules

ACTION=="add", SUBSYSTEM=="module", KERNEL=="nvidia_drm", TEST=="/sys/devices/platform/simple-framebuffer.0/drm/card0", RUN+="/bin/rm /dev/dri/card0"

Meaning when nvidia-drm is loaded, check if card0 is owned by simpledrm and if so then delete it. This means the device still exists hidden so VTs will keep working. Edit: Actually VTs keep working because they use /dev/fb0

[Daniel van Vugt (vanvugt)]

It could probably also go in /lib/udev/rules.d/71-u-d-c-gpu-detection.rules and then works for all driver versions (ubuntu-drivers-common package).

[Alessandro Astone (aleasto)]

I like it.
And +1 for 71-u-d-c-gpu-detection.rules over 71-nvidia.rules

[Daniel van Vugt (vanvugt)]

Alright, since you were already working in that project I'll let you propose it.