nvidia-drm.modeset=1 results in no monitors detected by Xorg

[Tim Richardson]

Context:
17.10 development packages, nvidia binary driver 375, modeset=1 for the nvidia driver.
ubuntu desktop (gnome shell), fresh install
ThinkPad W520 in Nvidia Optimus bios mode.
Nvidia profile.

Result:
no external monitors are detected.
xrandr does not even list them as disconnected (normally it would list five external disconnected monitors)

lsmod
shows that nvidia driver is loaded
and the modesetting is working at some level because there is no tearing on the laptop panel

Note: modeset=1 is the only way to get flicker-free graphics on the laptop panel. modeset=1 is not the default setting but it is highly desirable.

It works if lightdm is used which is why I have reported this against gdm3
My sessions in this configuration have mostly crashed after a few minutes with a gdm3 fail whale message in syslog but nothing else looks interesting.

[Tim Richardson (tim-richardson)]

ubuntu user Hon Weng Chong has emailed me as he continues to investigate the problem.
He believes he has proof that it is is GDM configuration issue and has provided the following fix

Hey Tim,

I figured out a hack solution to the GDM prime issue. If you replace /lib/systemd/system/gdm3.service with this file:

https://gist.github.com/hwchong/b3634b387e91b38d355a0500ffecfc7d

and /etc/X11/xorg.conf with this:

https://gist.github.com/hwchong/28d7c70aafd62a0d3114c5746da7da36

You should be able to use Prime Sync with your Intel graphics card and have an external monitor connected to the Nvidia GPU without using LightDM.

Cheers,
Hon

His proposed changes to xorg are probably not significant. He is proposing to add this to nvidia options, but this can be done via the GUI or command line.

    Option "metamodes" "nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"

The revised /lib/systemd/system/gdm3.service he proposes is
is
--> Compared to Fedora 27's config, changes seem to be the addition of
ExecStartPre=/usr/bin/xinit /usr/share/gdm/generate-config
.
.
.
RestartSec=1s
ExecReload=/usr/share/gdm/generate-config

[Unit]
Description=GNOME Display Manager

# replaces the getty
<email address hidden>
<email address hidden>

# replaces plymouth-quit since it quits plymouth on its own
Conflicts=plymouth-quit.service
After=plymouth-quit.service

# Needs all the dependencies of the services it's replacing
# pulled from getty@.service and plymouth-quit.service
# (except for plymouth-quit-wait.service since it waits until
# plymouth is quit, which we do)
After=rc-local.service plymouth-start.service systemd-user-sessions.service

# GDM takes responsibility for stopping plymouth, so if it fails
# for any reason, make sure plymouth still stops
OnFailure=plymouth-quit.service

[Service]
ExecStartPre=/usr/bin/xinit /usr/share/gdm/generate-config
ExecStart=/usr/sbin/gdm3
KillMode=mixed
Restart=always
RestartSec=1s
IgnoreSIGPIPE=no
BusName=org.gnome.DisplayManager
StandardOutput=syslog
StandardError=inherit
EnvironmentFile=-/etc/default/locale
ExecReload=/usr/share/gdm/generate-config
ExecReload=/bin/kill -SIGHUP $MAINPID

[Tim Richardson (tim-richardson)]

Celebratory fireworks from me.

It seems to work. For ubuntu the only difference is

[Service]
ExecStartPre=/usr/share/gdm/generate-config

becomes

[Service]
ExecStartPre=/usr/bin/xinit /usr/share/gdm/generate-config

I have a proper ubuntu gnome session running with gdm, an external monitor and laptop panel, with prime sync on and no flickering, running 'ubuntu on xorg'

*** FOR THE FIRST TIME EVER ***

on my thinkpad W520 which is old but is a genuine Optimus laptop with Quadro graphics on the nvidia 387.34 binary driver
in Optimus mode.

[Daniel van Vugt (vanvugt)]

Tim, are you really saying just that one-line change fixed it?...

I can confirm at least that /usr/share/gdm/generate-config is introduced only by Debian/Ubuntu packaging. It's not part of the upstream GDM project. So if Fedora's approach of running under xinit works then we should probably do the same. I can't yet see why it works though.

[Daniel van Vugt (vanvugt)]

Actually the offending line is directly from Debian: http://http.debian.net/debian/pool/main/g/gdm3/gdm3_3.26.2.1-2.debian.tar.xz

[Tim Richardson (tim-richardson)]

Let me clarify: the problem exists in Fedora too. Until a few hours ago, I
had never got prime sync and gdm3 working in any distribution.
This one line fix works, believe it or not. It's really a half a line fix.
I have only tried it in ubuntu 17.10 so far. Fedora is not a focus for me,
and I have other problems with nvidia binary support on Fedora 27. The
learning curve for Fedora is steep for me so I am not motivated to
investigate it.

On 13 December 2017 at 17:50, Daniel van Vugt <<email address hidden>
> wrote:

> Actually the offending line is directly from Debian:
> http://http.debian.net/debian/pool/main/g/gdm3/gdm3_3.26.2.
> 1-2.debian.tar.xz
>
> ** Also affects: gdm3 (Debian)
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1716857
>
> Title:
> gdm3, hybrid nvidia with modeset=1, no external monitors detected
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+subscriptions
>

--
Tim Richardson

[Hon Weng Chong (dr1337)]

Daniel, yes that one line fixes the bug. It's not a proper fix but a work-around for GDM3.

There's something about gdm-xsession being run that's different from LightDM that's not triggering the nvidia modeset drivers to turn detect external monitors and enabling PRIME sync. I discovered the workaround after accidentally doing a sudo startx and noticing that both PRIME sync and my external monitor had been enabled.

As this is quite an innocuous fix, would it be possible to upstream this into the Ubuntu GDM3 codebase until the GDM3 maintainers decide that it would be worth their time to actually look at this bug seriously and fix it in their codebase? Otherwise it gets annoying having to patch the systemd service everytime GDM3 gets a point update.

[Tim Richardson (tim-richardson)]

However with this change I'm seeing very long pauses on restart/shutdown, i haven't found any iclue why in the logs.

[Launchpad Janitor (janitor)]

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

[Aurélien PIERRE (aurelienpierre)]

Same on Thinkpad P51 (Nvidia Quadro M2200), Ubuntu 18.04, Nvidia 390

[Tim Richardson (tim-richardson)]

I re-confirm this. Stock 18.04 has no graphics in pure nvidia mode (on a Thinkpad W520 in discrete graphics).

lightdm works.

[Tim Richardson (tim-richardson)]

The current 18.10 nvidia packages have this problem too. That is, out of the box, the nvidia driver defaults to KMS now (first time on any distro) but the nvidia driver does not detect external screens. Probably should be a new bug I guess.

[Stefano (bhackt)]

18.10 Lightdm works but GDM works only with the mentioned hack/workaround (but with slowdowns):

ExecStartPre=/usr/bin/xinit /usr/share/gdm/generate-config

[Tim Richardson (tim-richardson)]

sddm works too: I just put kde plasma on my ThinkPad P50 with ubuntu 18.10, it works well.

[Jefferson H. Xavier (jeffersonx)]

Same issue in here on Ubuntu 18.04.1 LTS. I have a Dell G3 3579 with Nvidia Geforce 1050TI. I've tried to use a Samsung SmartTV as a secondary display connected to HDMI port but Gnome settings only shows laptop display. I've tested drivers 390, 396, 410, and 415 without success. This issue doesn't occurs using lightdm instead of gdm3.
I think developers have to solve this issue that has been reporting since 2017-09-13 and people who wants do use a external HDMI TV/Monitor to play games, like me, will face this issue.

[losingYou (niggoo)]

Running Ubuntu 18.10 here. Wanted to do a presentation with my Notebook, but it failed me cause of this bug.
I can confirm that it works "Out of the box" with lightdm and that it also works with gdm3 if you modify /lib/systemd/system/gdm3.service, changing the "ExecStartPre" line to the above mentioned: ExecStartPre=/usr/bin/xinit /usr/share/gdm/generate-config

[Stefano (bhackt)]

Yes but this workaround is going to create others issue for suspend and resume.

[Tim Richardson (tim-richardson)]

There are two workarounds mentioned: swap to lightdm and manipulate gdm3
start. I think you refer to the gdm3 startup changes when you say it causes
problems with suspend/resume (which I didn't try).
The other workaround is changing display manager to lightdm (or sddm, the
KDE display manager).
swapping to lightdm has not caused any suspend/resume problems for me on
the two Optimus laptops I used, so I think the lightdm workaround is ok.
It was the default display manager of ubuntu for a long time and is still
the default for xubuntu.

On Thu, 21 Feb 2019 at 08:45, Stefano <email address hidden> wrote:

> Yes but this workaround is going to create others issue for suspend and
> resume.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1716857
>
> Title:
> gdm3, hybrid nvidia with modeset=1, no external monitors detected
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+subscriptions
>

--
Tim Richardson

[Stefano (bhackt)]

Yes I was talking about the gdm3 workaround

[Stefano (bhackt)]

The problem with the lightdm workaround is that many had this cursor issue:

https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1770948

[Tim Richardson (tim-richardson)]

Personally, I have not encountered that when using ubuntu or fedora and
simply swapping gdm3 for lightdm but it's good that the other bug report
has a fix. It looks like a hidpi bug; none of my monitors are hidpi.

On Thu, 21 Feb 2019 at 12:50, Stefano <email address hidden> wrote:

> The problem with the lightdm workaround is that many had this cursor
> issue:
>
> https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1770948
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1716857
>
> Title:
> gdm3, hybrid nvidia with modeset=1, no external monitors detected
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+subscriptions
>

--
Tim Richardson

[Ivan (ivizot)]

I confirm the bug exists and workarounds work, both with lightdm and ExecStartPre line. Also, adding xinit to ExecStartPre messes up suspend functionality. That is a pity...

Laptop: Thinkpad P1 with nvidia graphics

[Ivan (ivizot)]

Forgot to add: Ubuntu 18.04.2

[Juan Cabello (juancabelloa)]

After adding the line "/usr/bin/xinit" to gdm3.service I get this in every boot:

ProblemType: Crash
Architecture: amd64
Date: Mon Mar 25 19:17:11 2019
DistroRelease: Ubuntu 18.04
ExecutablePath: /usr/lib/xorg/Xorg
ExecutableTimestamp: 1543339632
ProcCmdline: /usr/lib/xorg/Xorg :0
...

Did you guys find out why? And, why does it take too long to show the login screen?

[Tim Richardson (tim-richardson)]

Still present in 19.04, although as a workaround, the nvidia drivers have reverted to installing without modeset=1, so external monitors work, and Optimus users get dreadful tearing on their laptop's internal screen.

With modeset=1 (which in my case was a setting preserved during the update to 19.04):
At the login prompt (using gdm3) external monitors are powered on and display a background graphic.
During session start, they are lost.

External monitors work with lightdm or sddm3, both supported display managers in Ubuntu, so this remains the workaround.
 So odd that Fedora doesn't care about this. It's a dreadful welcome to Linux moment. Using gdm3 as the default display manager seems insane given this bug.

[Tim (tim-vandyke123)]

I'm on Ubuntu 19.04 as well and having issues with this.

I have an i7-8750h paired with a gtx 1050ti in a Dell G515.

I don't exactly what I did, but I can give a general idea:

I decided this morning that battery life was important to me, so I tinkered around with TLP. After I did that everything seemed fine, but when I plugged an HDMI cord back into my laptop, after reenabling my discrete GPU it no longer works. I have uninstalled and reinstalled TLP, I have reinstalled gdm3, no dice, and I have tried reverting just about everything I can think of that pertains to displays. I still can't get it. Switching over to lightdm for now, this is very frustrating though.

Before I was working with TLP though, I was able to connect to external displays via this HDMI cord no problem. I know it is not a hardware issue because before I log in the external display shows the image I have for my lockscreen. However, it's once I log in that the display turns off. Hope this helps. I'd love to help get gdm3 working as well. LMK if you need anything including logs.

[Jeremy Soller (jackpot51)]

The solution to this is to run X11 as root, so it can use VGA arbiter and detect displays on both the NVIDIA and modesetting drivers.

Add this to /etc/X11/Xwrapper.config :
needs_root_rights = yes

[Tim Richardson (tim-richardson)]

This works. Thanks. What does gdm3 do that requires this?

[Daniel van Vugt (vanvugt)]

In a more pure development environment, I can confirm this bug without needing hybrid GPUs, or gdm3.

Just the Nvidia driver and Xorg results in no outputs/monitors detected:

$ xrandr
Screen 0: minimum 8 x 8, current 640 x 480, maximum 16384 x 16384

To work around the problem I need to run Xorg as root. Then I get:

$ xrandr
Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 16384 x 16384
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
DVI-I-1 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200 59.95*+ 59.88
   1920x1080 60.00 59.94 50.00 23.98
   1600x1200 60.00
   1280x1024 75.02 60.02
   1280x720 60.00 59.94 50.00
   1152x864 75.00
   1024x768 75.03 60.00
   800x600 75.00 60.32
   720x576 50.00
   720x480 59.94
   640x480 75.00 59.94 59.93

So perhaps gdm3 is sometimes missing whatever /dev/* privileges it needs to start Xorg on Nvidia properly. And perhaps lightdm just always does it right.

Although a solution here in the medium term might lay in gdm3, I would more like to see the Nvidia driver fix this bug. Because I can reproduce it without any *dm. Just the kernel + Nvidia driver + Xorg.

[Daniel van Vugt (vanvugt)]

For a full list of reasons to not use nvidia-drm.modeset=1 right now, please see:
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=nvidia-drm.modeset

[Daniel van Vugt (vanvugt)]

Also, it sounds like the root cause here is the same as bug 1769857.

[Tim Richardson (tim-richardson)]

Hi Daniel, thanks for not forgetting about this, unlike everyone else :)
Have you communicated this observation to Nvidia at all?

[Tim Richardson (tim-richardson)]

I will post your findings to the nvidia developers forum.

[Daniel van Vugt (vanvugt)]

Not yet. I am just untangling more Nvidia bugs today.

Also, I forgot to mention that you CAN run Xorg+Nvidia and see your monitors as non-root. But only after you have started and stopped Xorg as root beforehand. Something gets remembered, maybe in $HOME somewhere?

[Tim Richardson (tim-richardson)]

I posted here:

https://devtalk.nvidia.com/default/topic/1055528/linux/nvidia-driver-in-modeset-1-requires-root-permissions-daniel-van-vugt-canonical-concludes-it-is-an-nvidia-bug/?offset=3#5351122

[Tim Richardson (tim-richardson)]

User generix reports that when gdm3 is compiled without wayland support, this bug is not seen.

[Daniel van Vugt (vanvugt)]

Nvidia 430.26 behaves a bit differently. It just fails to start as non-root and gives reasons:

[ 897.467] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
...
[ 897.470] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the
[ 897.470] (EE) NVIDIA: system's kernel log for additional error messages and
[ 897.470] (EE) NVIDIA: consult the NVIDIA README for details.
[ 897.470] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the
[ 897.470] (EE) NVIDIA: system's kernel log for additional error messages and
[ 897.470] (EE) NVIDIA: consult the NVIDIA README for details.
[ 897.470] (EE) [drm] Failed to open DRM device for (null): -2
[ 897.470] (EE) [drm] Failed to open DRM device for pci:0000:01:00.0: -2

So then the NVIDIA driver gives up and Xorg tries the modeset driver instead. Modeset seems to detect my monitor fine (got the EDID) but then fails with bug 1813897.

This is now a bit off-topic, but I suspect the above problem with nvidia-430 will have the same fix as this bug.

[Tim Richardson (tim-richardson)]

What we know about this bug is that gdm3, nvidia and modeset=1 is broken under configurations which are not broken when sddm and lightdm are used.

we know that gdm3 sessions with external monitors work with root permissions.

we know that gdm3 compiled with wayland also works (according to the gentoo user generix).

And neither gnome developers nor nvidia acknowledge a bug. If you make a venn diagram of all of this, gdm3 is the intersection of every observation.

[Tim Richardson (tim-richardson)]

"gdm3 compile without wayland", I meant

[Daniel van Vugt (vanvugt)]

Compiling gdm3 without wayland isn't a fix. It's a workaround, and kind of pointless. It's pointless because the most common reason for using nvidia-drm.modeset=1 is to get Wayland support. I know there are other reasons for wanting nvidia-drm.modeset=1 such as avoiding tearing in PRIME setups. But mostly if people use modeset=1 it is to get Wayland support.

If we can't get a fix from Nvidia then some kind of workaround that runs Xorg as root (like comment #26) is probably the next best option.

[Tim Richardson (tim-richardson)]

I think his point was to isolate the problem as being gdm3's wayland code.
If you need modeset=1 for wayland, then why is there any effort to support
nvidia and wayland under gnome, since it won't work (or are only optimus
systems affected by this?)

my point was that you marked this as invalid, but the only way to avoid
this bug is to avoid using gdm3. You don't have to change anything else. So
it looks like a gdm3 bug.

On Fri, 21 Jun 2019 at 11:50, Daniel van Vugt <email address hidden>
wrote:

> Compiling gdm3 without wayland isn't a fix. It's a workaround, and kind
> of pointless. It's pointless because the most common reason for using
> nvidia-drm.modeset=1 is to get Wayland support. I know there are other
> reasons for wanting nvidia-drm.modeset=1 such as avoiding tearing in
> PRIME setups. But mostly if people use modeset=1 it is to get Wayland
> support.
>
> If we can't get a fix from Nvidia then some kind of workaround that runs
> Xorg as root (like comment #26) is probably the next best option.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1716857
>
> Title:
> nvidia-drm.modeset=1 results in no monitors detected by Xorg
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+subscriptions
>

--
Tim Richardson

[Daniel van Vugt (vanvugt)]

> If you need modeset=1 for wayland, then why is there any effort to support
nvidia and wayland under gnome, since it won't work (or are only optimus
systems affected by this?)

I don't understand the question, sorry. The statement "it won't work" is wrong. Wayland does work. This bug is about Xorg, not Wayland.

> So it looks like a gdm3 bug.

Yes I understand that's how it looks, but we have established the root cause of this bug is in the Nvidia driver. Maybe we will be able to work around it with some gdm3 change, but that's not where the root cause of the problem is.

Other display managers are managing to work around the Nvidia driver bug here because they run as root. gdm3 does not run as root because it is trying to be more secure and avoid running as root. Calling this a gdm3 bug is probably wrong. I can reproduce the bug without gdm3.

[Daniel van Vugt (vanvugt)]

Actually, maybe those other DMs don't run as root. My memory is failing. So again maybe we do want a similar workaround in gdm3. But that doesn't seem to be the root cause of the bug.

[Tim Richardson (tim-richardson)]

just one last thing, possibly you are not aware that 19.04 Ubuntu wayland
sessions have exactly the same problem: no external monitors. While this
bug refers to Xorg, the problem is not limited to Xorg. At least on my
Optimus laptop. And when I use its multiplexor to go into pure Nvidia mode,
no monitors work, not even the laptop panel.

On Fri, 21 Jun 2019 at 12:50, Daniel van Vugt <email address hidden>
wrote:

> Actually, maybe those other DMs don't run as root. My memory is failing.
> So again maybe we do want a similar workaround in gdm3. But that doesn't
> seem to be the root cause of the bug.
>
> ** Changed in: gdm3 (Ubuntu)
> Status: Invalid => Opinion
>
> ** No longer affects: mutter (Ubuntu)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1716857
>
> Title:
> nvidia-drm.modeset=1 results in no monitors detected by Xorg
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/+subscriptions
>

--
Tim Richardson

[Daniel van Vugt (vanvugt)]

In isolation I don't think it's correct to say that Wayland sessions have "no external monitors". Wayland sessions do work with external monitors on the Nvidia driver if you have nvidia-drm.modeset=1. I've confirmed this on a desktop at least.

It sounds like you're describing some other laptop-specific or Optimus-specific bug. So I think to avoid confusion that should have its own separate bug report.

[Doug McMahon (mc3man)]

Being duped here with a more specific bug, i.e
19.10
optimus hardware
No login to ubuntu session possible with gdm, lightdm is ok

Maybe a few comments.

This bug orig. suggests that one could actually login on optimus hardware with nvidia-drm.modeset=1 thru gdm. That was once the case, it no longer is in 19.10.
The only session available is a wayland one because it falls back to Intel.

As far as why users set nvidia-drm.modeset=1?
I'd suggest the majority do so on optimus machines to be able to use nvidia without tearing. For the most part none have any interest in wayland even though wayland would solve tearing.
Why?, because no (or virtually none) optimus machine has ever been able to use wayland & nvidia drivers. Not in the last couple of years, not now.

While I don't have a desktop machine I do have a laptop with nvidia GPU only. In that case (19.04) with nvidia-drm.modeset=1 it presents and logs into a wayland session but llvmpipe only. It does work ok in a ubuntu session. Maybe I'll give it a try with 19.10 though on this machine there is no tearing so xorg is fine, currently any positives, if any, of wayland are outweighed by it's negatives.