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.

[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

[Daniel van Vugt (vanvugt)]

The fix has stopped working in Oracular kernel 6.11. Looks like the reason is no '/sys/devices/platform/simple-framebuffer.0/drm/card0' file.

[Daniel van Vugt (vanvugt)]

In progress again for Oracular:
https://github.com/canonical/ubuntu-drivers-common/pull/104

[Launchpad Janitor (janitor)]

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

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

  [ Kuba Pawlak ]
  * Sort the output list of matching nvidia drivers (LP: #2081970)
  * NVIDIA 560 release should suggest -open variant first (LP: #2081967)

  [ Alessandro Astone ]
  * Improve SimpleDRM+NVIDIA fix across kernel versions (LP: #2060268)

 -- Kuba Pawlak <email address hidden> Thu, 26 Sep 2024 10:27:26 +0200

[Daniel van Vugt (vanvugt)]

Continued in bug 2083329 and bug 2084046.

[Damien Masson (dajam)]

Hello,
I had this issue and #32 solved it.

However, I do not have an nvidia device, but use intel driver i915. I run Ubuntu 24.04.1 LTS (fresh install) on an HP EliteBook 840 laptop. The bug appeared after a recent update.

dm

[Daniel van Vugt (vanvugt)]

This bug is closed. Comment #103 is being tracked in bug 2084046.

[Alessandro Astone (aleasto)]

kernels 6.8.0-50 and 6.8.0-51 have regressed, for the same reasons as kernel 6.11: the simple-framebuffer device in sysfs is no longer at /sys/devices/platform/simple-framebuffer.0 (comment #99)

But for some reason, I only get a phantom display in Wayland. Instead, comment #29 previously mentioned that both X11 and Wayland are affected, and I remember seeing the same. Odd.

[Daniel van Vugt (vanvugt)]

Xorg might have a heuristic to ignore simpledrm if something else exists. But now I'm just guessing...

If 6.8 has regressed I'll update bug 2083329 to show that better.

[Prakash Vishwakarma (prakash2033)]

I'm experiencing the same issue on Ubuntu 24.04.01 LTS. The temporary and permanent fixes from the entry don't work because they don't display the LUKS password field. Is there an official fix available?

[Daniel van Vugt (vanvugt)]

This bug is about Nvidia only and this bug is closed as fixed. The issue has however resurfaced on:

Intel: as bug 2084046
Nvidia: as bug 2083329

Either way, you should be able to just "turn off" the unknown display in Settings > Displays.