Internal Screen not detected by Gnome Shell when logging in via GDM, but works fine with LightDM

Help
1

Hi Guys

I’m using Nixos for 3 months now for development on my Razer Blade and am absolutely loving it 3>
But there’s one thing that’s pretty annoying since the beginning:

When I enable GDM and Gnome, and then log in in GDM, the internal display of the laptop does not get detected. I need to connect an external monitor over HDMI to get an image. But even then, I cannot switch to the internal screen using the gnome settings or xrandr as it is not detected. (it’s not in the list)

But the funny part is:
Before logging in, GDM shows an image on both screens, so at least GMD detects both screens and the internal screen only turns black after login.

The workaround I currently have is that I use LightDM. When I log in using LightDM, gnome does detect the internal screen and everything works fine. ALMOST. When I use LightDM, i have no way to lock my screen (gnome does not display a lock icon in the menu), and when I lock the screen via console, and then try to log back in again, the previous session gets terminated an I need to start over again. So really not ideal.

Interestingly, I don’t have this problem on Nixos-unstable. But I’d like to avoid using unstable if possible, because I have some other problems with it (some systemd services showing red when starting up and FTP does for some reason no longer work in nautilus)

What needs to be said is, that the Razer Blade has two GPUs, and I have configured it to use only the NVIDIA card. Here’s the part of my configuration.nix file that’s related to the display stuff:

  services.xserver.displayManager.gdm.enable = true;
  services.xserver.desktopManager.xterm.enable = false;
  services.xserver.desktopManager.gnome3.enable = true;
  services.xserver.videoDrivers = ["nvidia" ];
  hardware.nvidia.optimus_prime.enable = true;
  hardware.nvidia.optimus_prime.nvidiaBusId = "PCI:1:0:0";
  hardware.nvidia.optimus_prime.intelBusId = "PCI:0:2:0";
  hardware.nvidia.modesetting.enable = true;
  hardware.opengl.driSupport32Bit = true;

If i replace “gdm.enable” with “lightdm.enable”, I can log in and get an image on my internal screen. But not with GDM.

Does anybody have an idea what the problem could be an how to solve it?
I’ve tried a lot of things in these 3 months (like for example overriding GDM, gnome shell or xorg server packages to be taken from unstable), and also tried updating from time to time, but the problem sadly didn’t go away, so I thought it might be better to ask on the forum rather than waiting for a fix to appear out of nowhere.

Thanks guys!

2

This is highly likely a bug in GDM (or g-s-d?). On stable we have GNOME 3.30 and unstable has 3.32. So I believe it was fixed in that release. It could be possible that a fix could be backported though.

Also, could you describe the issue with FTP? I believe that used to be an issue we fixed.

3

I also think this is the case. But if it is, shouldn’t I be able to override just these packages to the those from the unstable and then the problem should go away? Or is this non trivial?

Yes, I’ll check again first and then tell you in a few minutes.

4

Ok, I’ve now tested unstable again!

The good news:

  • There are no longer failing systemd services
  • Nautilus FTP works now.

The bad news:

  • The internal display still does not get detected. Maybe I also had to switch to the intel driver to make it work the last time i tried. So, this bug seems to also exist in unstable.
  • Dash-to-Dock didn’t work (maybe that would be easily fixable, would need to do some more investigation)

What I’m really curious about is, which component is responsible for detecting available displays?
It’s really strange. Both LightDM and GDM detect all displays, but then, when logging in, Gnome “loses” this information when using GDM. What’s the difference there? Does the display manager hand over a list of displays to gnome shell (which GDM does not do correctly), or does Gnome detect displays again by itself and does it differently for some reason when using GDM?

It’s really a strange topic…

1 Like
5

Works for me. Do you have any errors in your system journal?

That would be gnome-settings-daemon if I am not mistaken.

GDM actually uses GNOME Shell internally. The issue might have something to do with Wayland, which is still sometimes buggy in nvidia cards. I think GDM has Wayland blacklisted on nvidia cards while the session ¿might not?. What is the value of XDG_SESSION_TYPE after you log in? Are you choosing GNOME or GNOME XOrg in GDM session chooser?

P.S. GNOME should be more stable on unstable channel as I use it as my main system and I do not actively maintain GNOME on release branches.

6

Oh, sorry, I just noticed that the test I did was still with the stable channel. I forgot to put sudo in front of nix-channel, so I didn’t upgrade to unstable but instead just upgraded to the latest stable. :roll_eyes::sweat:

So here my new findings:

  • FTP still works ( had to change services.gnome3.gvfs.enable to services.gvfs.enable )
  • Internal screen is still not detected with GDM.
  • Dash to Dock works ( but also just with LightDM and not with GDM, probably because there are issues with the display. I’m pretty sure that was exactly what I noticed before)
  • Locking the display using dm-tool lock and unlocking it now works, without terminating the session. This did not work on the stable channel, so that’s awesome! But I still don’t have a lock-button in the gnome menu (I think that’s normal when using LightDM. There are extensions that display the button with LightDM, but all of them are hardcoded to the path /usr/bin/dm-tool, so they don’t work. But at least I can now safely lock my screen :slight_smile:
  • There are sometimes systemd services showing red when booting up, but not every time. I’ll have to investigate this further. But now it’s time to sleep.

I’m sorry I didn’t mention this earlier, but wayland is disabled completely on my system. This is a requirement when enabling optimus_prime. I checked XDG_SESSION_TYPE to be completely sure, and the value is x11, as expected. So I don’t think this is related to wayland.

I’ll try again using the intel driver. I’m almost certain that it’ll work with that.

Thanks for the info, I’ll try to work on unstable and see how it goes. Didn’t notice any blockers for now.

7

Alright, I finally figured out what the problem is:

There are 2 commands that need to be executed when starting the session:

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

For LightDM, this is what gets executed as soon as the gnome session starts. GDM on the other hand does not.

I’ve found the commit that initially added support for PRIME:
https://github.com/NixOS/nixpkgs/commit/f26153754a1b6ac0d72adde9c75e1473463b4dbb#diff-eba4fea93f8708e0012684b9c398b1e3

According to the commit message, GDM should also already work, but there seems to be a bug. So I left a comment to the author of the commit and hope that he’ll help me with the problem.

btw
I’m still on unstable and it mostly works. The only thing thats a bit weird at the moment is that I occasionally get some short freezes where the mouse cursor still moves but the UI does not respond to it in any way (for 2-3 seconds), and then everything works fine again. I did not have this on stable, but I could imagine that this is some bug in gnome 3.32. I noticed that you’ve started working on upgrading to 3.34, so I’ll just wait and see if this will solve this :wink:

8

Hey, I’m the author of this commit. The patch added there modifies gdm-x-session.c to enable getting that code executed both for the GDM X server and the session X server. It works such that gdm.nix module sets GDM_X_SESSION_WRAPPER which GDM picks ups and runs every session through the generated wrapper.

I just tried GDM nixos-unstable and it works fine for me. GDM shows up and logging in to a Plasma session works.

Do you see the GDM_X_SESSION_WRAPPER environment variable to be set in the session? I do:

[ambro@nixos:~]$ echo $GDM_X_SESSION_WRAPPER 
/nix/store/g2q6jhmk00b12d7csif9nzvrd48w5w4b-gdm-x-session-wrapper

[ambro@nixos:~]$ cat $GDM_X_SESSION_WRAPPER
#!/nix/store/wywaq0js8mnz3ajf9rj6zjaaszhw2jhp-bash-4.4-p23/bin/bash
# Added by nvidia configuration module for Optimus/PRIME.
/nix/store/2kmb70m8sbxdi1m7sadhpi240mm2q3fj-xrandr-1.5.0/bin/xrandr --setprovideroutputsource modesetting NVIDIA-0
/nix/store/2kmb70m8sbxdi1m7sadhpi240mm2q3fj-xrandr-1.5.0/bin/xrandr --auto

exec "$@"
9

Wait you’re right, the internal screen does is not detected within the session. We’ll need to figure out what happened. I wouldn’t even assume that the commands were not run, we’d need to check.

10

I tried this again and now GDM doesn’t even show up, the system remains in console mode. Nothing changed, the exact same configuration no longer works. The system log shows these errors from the X server:

(EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA GPU at PCI:1:0:0.  Please
(EE) NVIDIA(GPU-0):     check your system's kernel log for additional error
(EE) NVIDIA(GPU-0):     messages and refer to Chapter 8: Common Problems in the
(EE) NVIDIA(GPU-0):     README for additional information.
(EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA graphics device!
(EE) NVIDIA(0): Failing initialization of X screen
... (after ~100 lines) ...
(EE) Screen(s) found, but none have a usable configuration.
(EE)
Fatal server error:
(EE) no screens found(EE)
(EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
(EE) Please also check the log file at "/dev/null" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file

I’ve seen this same issue before with GDM and still have no idea, especially why it worked once just now and then no more.

11

Ok, that’s strange. I fortunately never had this problem. GDM always starts here and shows up on all screens, and only after logging in the problem starts to appear.

edit
Another note: At least on the razer blade, the HDMI ports are connected to the nvidia card, while the internal display is connected to intel card. And because of this, my external screen always works when connected via HDMI, but the internal screen only gets detected after running the xrandr commands.

12

I’ve now temporarily fixed the problem for me by creating the file ~/.xprofile and putting the 2 xrandr commands into it. I tried adding them to /etc/gdm/PostLogin/Default first, but that sadly didn’t work. I’m not sure if gdm would first need to be configured to run the PostLogin script.

13

Another option would be adding it as autostart file:

https://wiki.debian.org/NvidiaGraphicsDrivers/Optimus#Configure_GNOME_Display_Manager_.28GDM.29

1 Like
14

I ended up with

  services.xserver.displayManager.sessionCommands = ''
    ${pkgs.xorg.xrandr}/bin/xrandr --setprovideroutputsource modesetting NVIDIA-0
    ${pkgs.xorg.xrandr}/bin/xrandr --auto
  '';

It’d be cool if something like this would be done automatically when enabling gdm and optimus at the same time, but I’m not experienced enough to do it myself. There would be quite a few things to be considered, I think.

2 Likes
15

Thanks. This patch got me over the hump on my fresh nixos install on my laptop.

16

Nov '21, and i have the same problem. This workaround or in ~/.xprofile don’t work.

I confirm that LightDM Work normally.
The GDM implementation on NixOS needs review.

1 Like