nvidia-drm.modeset=1, gdm3 and optimus laptop results in no external 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.

[Tim Richardson (tim-richardson)]

19.10 beta and nvidia drivers 430 and 435 have the same problem. I have made the bug title correctly specific.

[Tim Richardson (tim-richardson)]

And PS: workaround continues to be: use lightdm, a five minute fix at worst.

https://askubuntu.com/questions/139491/how-to-change-from-gdm-to-lightdm

[Nathan Johnson (marththeweird)]

Jeremy Soller's fix to edit Xwrapper seems to be good.

The edits to the gdm service cause a crash to happen on boot.

Currently using an HP Laptop with an Intel CPU and Nvidia GPU that I believe is Optimus.

I have the proprietary Nvidia driver running on nvidia-driver-430 as of this comment's date.

[Tim Richardson (tim-richardson)]

I just installed popOS 19.10 an an Optimus laptop, nvidia option. Out of the box you get gdm3 and tear-free prime-sync; it uses Jeremy Soller's solution (root rights granted in Xwrapper)

[Zoltán Süle (zoltan-sule)]

I confirm Xwrapper root rights worked for me too.

Ubuntu 18.04
kernel: 5.3.x and 4.15.x
Nvidia driver: 435.21

[Tim Richardson (tim-richardson)]

This bug persists in 20.04 daily.
The one-line Pop!OS solution (https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1716857/comments/26) works, just logout and login.

Pop!OS has used this for several releases now, just saying.

[Alberto Milone (albertomilone)]

I think forcing all users (even on systems that don't use the NVIDIA driver) to run X with root privileges would be a little heavy-handed.

[Daniel van Vugt (vanvugt)]

Is it a kernel, systemd or Nvidia issue to get the right device nodes exposed here?

[Tim Richardson (tim-richardson)]

@Alberto, couldn't prime-select do this when going into hybrid or Optimus mode? Only users with nvidia hybrid graphics would go down this logic path, and they are only ones who need the fix (but only if they are using gdm3, sddm and lightdm continue to be unaffected by this)

The set of users who "need" this fix are gdm3 users with hybrid Nvidia graphics (where "need" = want tear-free graphics on their laptop panel if Optimus, or on all displays if it's something like a T-series Thinkpad where the nvidia card has no direct access to any display).

[Daniel van Vugt (vanvugt)]

I've added systemd to the bug because that seems to be involved in device permissions, as well as proving useful in the above comments.

[Jean-Pierre van Riel (jpvr)]

Hi, thanks to everyone, especially Daniel for unpacking this issue.

I have had a very similar issue, where gnome shell fails to run my external 4K/UHD display at 60HZ and I see the following failure loop triggered in `journalctl -b -p warning _COMM=gnome-shell`:

May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to blit shared framebuffer: EGL failed to allocate resources for the requested operation.
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to set CRTC mode 3840x2160: No such file or directory
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to flip: Device or resource busy
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to set CRTC mode 3840x2160: No such file or directory
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to blit shared framebuffer: EGL failed to allocate resources for the requested operation.
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to set CRTC mode 3840x2160: No such file or directory
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to blit shared framebuffer: EGL failed to allocate resources for the requested operation.
May 02 20:39:38 JNBA434499PLL gnome-shell[1957]: Failed to set CRTC mode 3840x2160: No such file or directory
...

 While not sure it's exactly the same, it should still inform the overall discussion about dealing with GDM3 + Mutter + proprietary Nvidia drivers modeset problems.

To summarise and share my experience of it on a Lenovo P53 and some quirks/workarounds:

- `sudo ubuntu-drivers autoinstall` got Nvidia 440.59 drivers installed.
- However, Nvidia modeset was not enabled as yet.

$ sudo cat /sys/module/nvidia_drm/parameters/modeset
N

-

- Using prime-select

- For laptops like mine, seems the external port is connected to the Nvidia GPU.
- Using the proprietary Nvidia drivers seems to then bump into a

[Jean-Pierre van Riel (jpvr)]

Apologies, continuing the comment above (mistakenly posted when adding the log attachment). Let me retry.

Failure loop observed:

- Failed to blit shared framebuffer: EGL failed to allocate resources for the requested operation.
- Failed to set CRTC mode 3840x2160: No such file or directory

To summarise and share my experience of it on a Lenovo P53 and some quirks/workarounds:

- `sudo ubuntu-drivers autoinstall` got Nvidia 440.59 drivers installed.
- However, Nvidia modeset was not enabled as yet.

$ sudo cat /sys/module/nvidia_drm/parameters/modeset
N

- Blank external screen occurs with modeset=0 (disabled)
- Then, using `prime-select nvidia`, I tried to ensure nvidia was primary
- `prime-select nvidia` sets `options nvidia-drm modeset=1` but it's not effective, even after I rebooted

~$ cat /lib/modprobe.d/nvidia-kms.conf
# This file was generated by nvidia-prime
# Set value to 0 to disable modesetting
options nvidia-drm modeset=1

- To make it effective, because modeset is done during initramfs part of boot, I ran `sudo update-initramfs -u -k all`.
- It seems the prime-select option fails to trigger a intiramfs update (probably should be filed as a separate bug)
- Regardless, the blank screen issue occured on my Lenovo P53 with or without Nvidia KMS modeset enabled
- But one benefit of KMS modeset for Nvida is now the external display gets properly recognised. /sys/class/drm/card1-HDMI-A-1/ now exists (was missing with Ubuntu 18.04.4 LTS default proprietary install) including the EDID data being read properly and X getting the actual DPI of the screen correctly.

Without nvidia modeset, as seen in `journalctl -b _COMM=gdm-x-session | grep -C2 -E '(EE)|(WW)'`:

(WW) NVIDIA(0): Unable to get display device for DPI computation.

With nvidia modeset:

(II) NVIDIA(0): Validated MetaModes:
(II) NVIDIA(0): "DFP-3:nvidia-auto-select"
(II) NVIDIA(0): Virtual screen size determined to be 3840 x 2160
(--) NVIDIA(0): DPI set to (139, 140); computed from "UseEdidDpi" X config

I've also found two workarounds to my issue.

1. Run a script that sets the frequency to 30HZ and then back to 60HZ
2. Switch to discrete only graphics in the BIOS

In most cases, when one is using a 2nd display, there's usually a powersource available so the complexity of hybrid graphics isn't worth it and I went with simply disabling hybrid graphics in the BIOS.

It's quite interesting that toggling the display refresh rate down to 30HZ and then back up to 60HZ seems to work around the problem of gnome-shell mutter's "EGL failed to allocate resources for the requested operation" bug.

To conclude, even with the root access workaround in place:

$ tail -n 2 /etc/X11/Xwrapper.config
# Added by xserver-xorg-video-nvidia-440
needs_root_rights=yes

I still had external display connection issues with 4K 60Hz.

This might need to be logged as different bug? I'm unsure it's GDM3s fault given the root workaround was in place, but it's highly related/similar.

[Jean-Pierre van Riel (jpvr)]

Here's the script I run to workaround the intital failure of gnome to use the external display after unlocking or resuming from DPMS suspend/off.

[Jean-Pierre van Riel (jpvr)]

Another correction. For the one workaround, switching to discrete graphics in the BIOS only seemed to get past the initial gnome login. But resuming from DPMS off/suspend, the same error loop happens even when hybrid graphics is disabled in the BIOS.

Even worse, seems hardware acceleration ends up being disabled:

$ journalctl --no-hostname -b -p warning _COMM=gnome-shell
-- Logs begin at Wed 2019-02-06 14:13:52 SAST, end at Sun 2020-05-03 16:09:45 SAST. --
May 03 14:51:40 org.gnome.Shell.desktop[2284]: glamor: 'wl_drm' not supported
May 03 14:51:40 org.gnome.Shell.desktop[2284]: Missing Wayland requirements for glamor GBM backend
May 03 14:51:40 org.gnome.Shell.desktop[2284]: Failed to initialize glamor, falling back to sw
...
May 03 14:53:25 gnome-shell[6549]: setup_framebuffers: assertion 'width > 0' failed

The "EGL failed to allocate resources" error stops happening probably because gnome-shell isn't even using hardware acceleration now.

I've also disabled all gnome shell extensions to avoid noise/errors in the logs and will try weed out the problem better.

I checked `grep -C2 -E '(EE)|(WW)' /var/log/Xorg.0.log` and things seem fine:

[ 45.181] (II) NVIDIA dlloader X Driver 440.59 Thu Jan 30 01:08:17 UTC 2020
[ 45.181] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
--
[ 45.182] (II) LoadModule: "ramdac"
[ 45.182] (II) Module "ramdac" already built-in
[ 45.183] (WW) Falling back to old probe method for modesetting
[ 45.183] (II) NVIDIA(0): Creating default Display subsection in Screen section
 "Default Screen Section" for depth/fbbpp 24/32
--
[ 46.392] (==) NVIDIA(0): Silken mouse enabled
[ 46.392] (==) NVIDIA(0): DPMS enabled
[ 46.393] (WW) NVIDIA(0): Option "PrimaryGPU" is not used
[ 46.393] (II) Loading sub module "dri2"
[ 46.393] (II) LoadModule: "dri2"

Note, I've done no customisation to X config - trying to stick to defaults.

xrandr confirms only one provider / hybrid is indeed off and Intel not in use:

$ xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x218 cap: 0x1, Source Output crtcs: 4 outputs: 6 associated providers: 0 name:NVIDIA-0

I'm guessing the Lenovo P53 impliments a mux/switch to connect the laptop panel to the NVidia card so that Intel is disabled in this mode.

And double checking, also no i915 modules are loaded:

$ lsmod | grep '^drm'
drm_kms_helper 180224 1 nvidia_drm
drm 491520 10 drm_kms_helper,nvidia_drm

So there seems to be, on current Ubuntu 18.04.4 LTS (fully up to date as of today), a 4K / UHD 60Hz issue with Nvidia, as seen in X log

[ 45.228] (II) NVIDIA GLX Module 440.59 Thu Jan 30 01:05:38 UTC 2020

Lastly, I think due to `needs_root_rights=yes` in /etc/X11/Xwrapper.config, X logs to /var/log/Xorg.0.log again instead of the X without root which used to log at ~/.local/share/xorg/Xorg.0.log

[Kai-Chuan Hsieh (kchsieh)]

Test on Intel Tiger Lake platform with nvidia dGPU (N17S-G5 PCI\VEN_10DE&DEV_1C94).

Distribution: Ubuntu
Codename: focal
kernel: 5.6.0-1018-oem
NV driver: 440.100
nvidia_drm modeset=1
gdm3: 3.34.1-1ubuntu1
xserver-xorg-core: 2:1.20.8-2ubuntu2.1

The device can detect external 4K/UHD monitor sucessfully by HDMI or DP.
It seems the original issue is not able to reproduce on this machine.
However, the modeset has to be enabled for https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1769857/comments/5, but it is disabled by default currently.

[Daniel van Vugt (vanvugt)]

Can someone please retest on Ubuntu 21.10?

[Daniel van Vugt (vanvugt)]

Closed due to no reply after 5 months. If anyone still experiences problems then please open new bugs for them using the 'ubuntu-bug' command.