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
Beware that this has side-effects: see comment #37

[ Test Plan - Nvidia case ]

1. Set up a DESKTOP where the only GPU enabled is an Nvidia one.
2. Open the 'Additional Drivers' app to install a supported Nvidia driver.
3. Reboot and verify the Nvidia driver is now active (lspci -k should mention 'nvidia' and not 'nouveau').
4. Open Settings and verify the only monitors shown are your real monitors.

[ Regression Test Plan - Intel/AMD graphics ]

1. Set up a machine with integrated graphics only.
2. Reboot.
3. Verify that you are able to log into the Ubuntu Desktop Wayland session.
4. Run `apt install nvidia-driver-535`.
5. Reboot.
6. Verify that you are able to log into the Ubuntu Desktop Wayland session.

[ Regression Test Plan - Virtual machines ]

1. Set up a virtual machine without any graphics acceleration (vmware, virtio...)
2. Reboot.
3. Verify that you are able to log into the Ubuntu Desktop Wayland session.
4. Run `sudo apt install nvidia-driver-535`.
5. Reboot.
6. Verify that you are able to log into the Ubuntu Desktop Wayland session.
7. Optionally go back to point 4, and try with nvidia-driver-550.

[ Regression Test Plan - Nvidia+LUKS ]

1. Set up a desktop machine (not a laptop) with an Nvidia GPU and encrypted disk.
2. Open the 'Additional Drivers' app to install a supported Nvidia driver.
3. Reboot
4. Verify that you see the password prompt for decrypting the disk.

[ 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.

One case where this could happen is if the Nvidia driver would allow being loaded even without any nvidia hardware present: if that is the case, "Regression Test Plan - Virtual machines" would fail.

[ 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.

[Daniel van Vugt (vanvugt)]

https://github.com/canonical/ubuntu-drivers-common/pull/101

[Brian Murray (brian-murray)]

I don't see an upload of ubuntu-drivers-common in the unapproved queue or in -proposed which addresses this bug so I'm setting it back to In Progress. Fix Committed should *not* be used for Ubuntu bug tasks if the fix is in some "upstream" branch.

[Daniel van Vugt (vanvugt)]

For everyone's benefit:

Desktop team policy (from seb128) is to use Fix Committed on anything committed to a packaging branch (or upstream in the case that it's expected to roll into an upstream micro release). I asked Seb again recently if this was something we wanted to continue doing and the answer was yes.

But that policy shouldn't apply to non-desktop packages because we know it annoys people. In those cases, Fix Committed means it's in proposed already.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-drivers-common - 1:0.9.7.7

---------------
ubuntu-drivers-common (1:0.9.7.7) oracular; urgency=medium

  * SRU (LP: #2076245)
  * debian/tests/control
    - change test dependencies from libgl1-mesa-glx to libglx-mesa0
      (LP: #2071829)
  * debian/control
    - change repository links
  * tests/test_ubuntu_drivers.py (synchronize repository)
    - increase the timeout for test_system_driver_packages_performance
      since for some reason it seems really slow but only on the builders
  * UbuntuDrivers/detect.py
    - Ensure that self._major_ver is an int
    - Replace "udevadm hwdb" with systemd-hwdb
    - Recommend hwe-*-meta for non-oem hardware enablement meta packages
  * share/hybrid:
    - Change Makefile to respect CC and CFLAGS environment variables
  * share/hybrid/71-u-d-c-gpu-detection.rules
    - Remove SimpleDRM device when nvidia-drm loads (LP: #2060268)
  * share/hybrid/gpu-manager.c
    - Wait for nvidia-drm to settle before opening /dev/dri/card* (LP: #2060268)

 -- Kuba Pawlak <email address hidden> Wed, 24 Jul 2024 11:00:58 +0200

[Robie Basak (racb)]

From IRC (#ubuntu-release):

13:14 <rbasak> tjaalton: for bug 2060268, are there any cases where the udev rule would be triggered but is the wrong thing to do? How certain are we on that point?

13:14 <rbasak> tjaalton: presumably the Test Plan should specify testing on particular hardware? That needs adjusting. But also, because of the previous question, do we need to be testing on multiple hardware?

13:15 <rbasak> tjaalton: or maybe against multiple nvidia driver versions - we ship multiple, right?

[Daniel van Vugt (vanvugt)]

I've extended the test plan to mention the particular hardware required.

As for testing multiple Nvidia driver versions, that's not required. Because the phantom monitor comes from simpledrm and not from nvidia. There are no separate per-driver fixes. Although it's always advisable you're starting with a machine that has the bug before verifying the fix.

[Timo Aaltonen (tjaalton)]

answer to the first question forwarded from mattermost:
"the simpledrm master device is never useful with another real DRM device, so yes it is safe"

[Andreas Hasenack (ahasenack)]

This regression potential concerns me, thank you for raising it:
"""
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.
"""

It may be obvious to you that it's safe to remove /dev/dri/card0 (see comment #71), but it's not clear to me what creates that device, why, and when.

Also, the test plan still does not cover non-nvidia platforms, and it sounds to me like that would be crucial.

Finally, don't systems with multiple video cards exist, and couldn't one be using /dev/dri/card0?

[Andreas Hasenack (ahasenack)]

During boot, when does exactly "/bin/rm /dev/dri/card0" run? Would that run in the initrd environment? I ask because of comment #37, which said they lost the display during the luks password prompt. Although I believe that's because of the workaround they were using then, which was to disable simpledrm via the kernel command line.

[Andreas Hasenack (ahasenack)]

Finally, and pardon my ignorance, but could /dev/dri/card0 be used for non-graphical things, like servers doing gpu calculations? And in that case, removing it could break that workload?

[Andrea (pesa1234)]

Sorry, I would like to inform that I also get this issue.

Thanks

Comment #32 is a solution for me

[Bill Yu (billchyu)]

@Daniel @Alessandro
Sorry for the pushing. Is that possible to clarify SRU team's concern on #74?
There are HP's commercial demands. Please see the impacted platform and bugs listed below.

HP Z4 G5 cert with 24.04: https://warthogs.atlassian.net/browse/STELLA-58
HP Elite SFF 805 G9 with 22.04: https://bugs.launchpad.net/stella/+bug/2071758

If this fix can be reviewed OK and moved to proposed first by Sep-03, that would be very helpful for the HP projects. Thank you.

[Alessandro Astone (aleasto)]

Very early in the boot process SimpleDRM will claim card0 as a DRM device backed by the BIOS framebuffer, mostly useful to offer Wayland-friendly graphics on systems without a GPU.
When the system loads a GPU driver that brings its own framebuffer, it will automatically unload SimpleDRM. The nvidia driver doesn't yet expose a framebuffer (it's changing soon), so SimpleDRM will stick around on nvidia-only systems.

On single-GPU systems without nvidia, the GPU display will be at /dev/dri/card1 and card0 won't be present because SimpleDRM was unloaded.
On single-GPU systems with nvidia, the GPU display will also be at /dev/dri/card1 but card0 will stick around, causing this bug.
On multi-GPU systems, the presence of any non-nvidia GPUs should trigger the automatic removal of SimpleDRM. I'm not sure about this but I think it is possible that one of the real GPUs would end up as /dev/dri/card0.

To address the bug, we cannot simply unload SimpleDRM on nvidia because it also provides the system's only framebuffer at /dev/fb0, which we need for VTs and comment #37 for example. But we can remove the SimpleDRM DRM node at /dev/dri/card0 which we don't need because an actual GPU card is available at /dev/dri/card1.

 > don't systems with multiple video cards exist, and couldn't one be using /dev/dri/card0?

There are two conditions that need to be satisfied in order for the `rm /dev/dri/card0` action to run:

1. The nvidia proprietary driver must be loaded. Note that the nvidia driver will refuse to probe unless a nvidia GPU is present, so this implies that the nvidia hardware is available.

2. The /dev/dri/card0 device must be owned by SimpleDRM. If /dev/dri/card0 is created by another driver, the action will not be run.

 > During boot, when does exactly "/bin/rm /dev/dri/card0" run

Whenever the nvidia driver is loaded. I'm not sure when that normally is, but it shouldn't be relevant: when any other GPU DRM driver is present, we don't need a SimpleDRM DRM node.

 > Also, the test plan still does not cover non-nvidia platforms, and it sounds to me like that would be crucial.

The two pre-conditions that i've illustrated above will cover the non-nvidia case. The crucial point there is that the nvidia driver must refuse to load without the underlying hardware. Since that is the case, the `rm` action is not triggered. The regression potential here is that on a system with the nvidia driver installed but no GPU hardware we would remove the only DRM driver, breaking Wayland compositors. I'll add a test-plan to ensure that the driver behaves as expected. I guess this would be where testing multiple nvidia driver versions is useful.

 > could /dev/dri/card0 be used for non-graphical things, like servers doing GPU calculations? And in that case, removing it could break that workload?

No, SimpleDRM only allows drawing one buffer to the screen.

[Łukasz Zemczak (sil2100)]

I think we have all the answers now. Let me accept this into proposed, but I'd request lots of test coverage from users using the -proposed package on different hardware.

[Łukasz Zemczak (sil2100)]

Hello Daniel, or anyone else affected,

Accepted ubuntu-drivers-common into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.9.7.6ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Łukasz Zemczak (sil2100)]

Hello Daniel, or anyone else affected,

Accepted ubuntu-drivers-common into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.9.6.2~0.22.04.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Geroen Dierckx (ridiekel)]

Hello,

I tested on my laptop with:
 - ubuntu-drivers-common/1:0.9.7.6ubuntu3.1
 - nvidia-driver-555-open/555.58.02-0ubuntu0~gpu24.04.1
 - LUKS enabled

The phantom display is gone, and the password prompt for decrypting the disk was correctly shown at startup.

Seems to work for me.

[Daniel van Vugt (vanvugt)]

> Finally, and pardon my ignorance, but could /dev/dri/card0 be used for non-graphical things, like servers doing gpu calculations? And in that case, removing it could break that workload?

"servers doing gpu calculations" would use /dev/dri/render* (or something Nvidia-specific), not /dev/dri/card*. Only the "render" nodes are actual GPUs. The "card" nodes are for displaying images on screen without implying acceleration.

[frenchy82 (cartes)]

Nvidia-driver-550
The problem is solved for me too

[Daniel van Vugt (vanvugt)]

Sorry I was on leave and didn't notice how many questions needed answering:

> It may be obvious to you that it's safe to remove /dev/dri/card0 (see comment #71), but it's not clear to me what creates that device, why, and when.

The device is created by whatever DRM driver loads first. The fix works by verifying it is simpledrm before deleting anything:

  TEST=="/sys/devices/platform/simple-framebuffer.0/drm/card0", RUN+="/bin/rm /dev/dri/card0"

> Also, the test plan still does not cover non-nvidia platforms, and it sounds to me like that would be crucial.

Actually no. Testing for all the possible regressions on unrelated platforms is not something we do in SRU testing.

That said, testing non-NVIDIA systems is something I have been doing with this fix over the past month or so. The set of test plans we have now feels a little excessive but isn't much worse than the testing we already deemed necessary and already conducted.

> Finally, don't systems with multiple video cards exist, and couldn't one be using /dev/dri/card0?

As mentioned above, the fix works by verifying it is owned by simpledrm before deleting anything. Of course testing that non-NVIDIA systems (and hybrid NVIDIA systems) don't have their card0 deleted should be part of the test plan and is something I've been testing for quite some time already.

[Daniel van Vugt (vanvugt)]

> During boot, when does exactly "/bin/rm /dev/dri/card0" run? Would that run in the initrd environment? I ask because of comment #37, which said they lost the display during the luks password prompt. Although I believe that's because of the workaround they were using then, which was to disable simpledrm via the kernel command line.

It runs when nvidia-drm is added:

  ACTION=="add", SUBSYSTEM=="module", KERNEL=="nvidia_drm"

but I don't remember if we still allow that to happen in initrd or afterwards. It depends on the current state of the Nvidia drivers' packaging.

If nvidia-drm is loaded during initrd then yes I imagine that might create a problem... although usually devices already in use still exist in the kernel after you delete the /dev entry. If Plymouth was already rendering on card0 then it shouldn't suddenly turn the screen black just because there's no longer a device node on disk. I think the bug you describe was more likely due to the workaround and didn't blank a previously working screen, but rather made it blank from the beginning.

TL;DR - probably no bug but we have a regression test anyway.

[Daniel van Vugt (vanvugt)]

Verified these both fixed on Noble using ubuntu-drivers-common 1:0.9.7.6ubuntu3.1 -

* [ Test Plan - Nvidia case ]
* [ Regression Test Plan - Intel/AMD graphics ] (Intel)

[Daniel van Vugt (vanvugt)]

Could not verify on Noble:

  [ Regression Test Plan - Nvidia+LUKS ]

I tried a couple of times but the installer keeps crashing. Looks like the main reason is:

  Volume group "ubuntu-vg" has insufficient free space (60256 extents): 60264 required

on a completely blank disk.

[Alessandro Astone (aleasto)]

Verified [ Regression Test Plan - Virtual Machines ] with ubuntu-drivers-common 1:0.9.7.6ubuntu3.1 on Ubuntu 24.04 LTS by using KVM:
```
<video>
  <model type="ramfb" heads="1" primary="yes"/>
</video>
```

Even with nvidia-driver-535 or nvidia-driver-550 installed, the system has kept access to SimpleDRM and can still boot a Wayland session.

[Alessandro Astone (aleasto)]

Verified [ Regression Test Plan - Intel/AMD graphics ] with ubuntu-drivers-common 1:0.9.7.6ubuntu3.1 on Ubuntu 24.04.1 LTS on an AMD thinkpad.

[Alessandro Astone (aleasto)]

Verified [ Regression Test Plan - Virtual Machines ] with ubuntu-drivers-common 1:0.9.6.2~0.22.04.7 on Ubuntu 22.04.4 LTS

[Daniel van Vugt (vanvugt)]

We're only missing [ Regression Test Plan - Nvidia+LUKS ] now (comment #87), if anyone can help with that. It requires the primary GPU be Nvidia, so probably not a laptop but a desktop.

The other test cases have all been completed for Noble in comments #81, #86, #88, #89. So that may be as good as we can get.

[Daniel van Vugt (vanvugt)]

Test cases verified on Jammy using ubuntu-drivers-common 1:0.9.6.2~0.22.04.7 -

* [ Test Plan - Nvidia case ]
* [ Regression Test Plan - Intel/AMD graphics ] (Intel)
* [ Regression Test Plan - Nvidia+LUKS ]

Combined with comment #90, that makes Jammy verification done.

[Kirill Kuzminykh (cykooz)]

I still have a phantom “Unknown Display” in Settings. But it seems that this "display" doesn't affect the system. Only once I saw oversized desktop, that extended beyond the monitor. I don't know how to reproduce this oversized desktop again.

My configuration:
- One monitor
- Ubuntu 24.04
- Environment: Xorg
- Graphics Card: NVIDIA GeForce RTX 3080 Ti
- Driver Version: Nvidia driver 535.183.01
- ubuntu-drivers-common 1:0.9.7.6ubuntu3

[Daniel van Vugt (vanvugt)]

You don't have the fix installed. The fix is in:

  ubuntu-drivers-common 1:0.9.7.6ubuntu3.1

and not in:

  ubuntu-drivers-common 1:0.9.7.6ubuntu3

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-drivers-common - 1:0.9.7.6ubuntu3.1

---------------
ubuntu-drivers-common (1:0.9.7.6ubuntu3.1) noble; urgency=medium

  [ Mate Kukri ]
  * debian/control: Make Vcs-Git and Vcs-Browser fields point to current location

  [ Alessandro Astone ]
  * Wait for nvidia-drm to settle before opening /dev/dri/card*
    (LP: #2060268)

  [ Daniel van Vugt ]
  * Remove SimpleDRM device when nvidia-drm loads
    (LP: #2060268)

  [ Kuba Pawlak ]
  * Revert "Change maximum open files limit for the shell" (LP: #2077646)

 -- Timo Aaltonen <email address hidden> Thu, 22 Aug 2024 15:26:53 +0300

[Timo Aaltonen (tjaalton)]

The verification of the Stable Release Update for ubuntu-drivers-common has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Leo Lin (0xff07)]

[ Regression Test Plan - Nvidia+LUKS ]

Tested on a HP desktop machine with Nvidia graphic card with 550.107.02 driver

1. Install the stock 24.04.1 image fresh (with the additional drivers option selected) and enabled disk encryption.
2. Install the proposed ubuntu-drivers-common after booting in to it.
3. Reboot. The LUKS prompt showed as expected, and the phantom display no longer appear.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-drivers-common - 1:0.9.6.2~0.22.04.7

---------------
ubuntu-drivers-common (1:0.9.6.2~0.22.04.7) jammy; urgency=medium

  * share/hybrid/71-u-d-c-gpu-detection.rules
    - Remove SimpleDRM device when nvidia-drm loads (LP: #2060268)
  * share/hybrid/gpu-manager.c
    - Wait for nvidia-drm to settle before opening /dev/dri/card*
    (LP: #2060268)
  * tests/test_ubuntu_drivers.py
   - Split a test to fix a race condition
    (LP: #2077654)
   - revert RLIMIT_NOFILE set and test (LP: #2077646)

 -- Kuba Pawlak <email address hidden> Wed, 07 Aug 2024 13:45:38 +0200