[SOLVED] nvidia prime on dual gpu configuration giving a blank screen

lspci | grep VGA

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)

lspci | grep 3D

02:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev a2)

kernel: 4.11.0

The configuration described in the thread below stopped working as of kernel version 4.10

Once I blacklist the nouveau driver and install the nvidia one with the described configuration in the above thread, once gdm3 tries to start it just gives a blank screen - the system doesnt hang and I am able to switch to another console however no display output is displayed. It looks a bit like the display output is redirected to another output source. I’ve tried setting the nvidia-drm.modeset and disabling i915.modeset, all possible modeset combinations I could think of and tons of other things described on forums with similar issues.

The xorg.conf nvidia prime configuration is as following:
Section “ServerLayout”
Identifier “layout”
Screen 0 “nvidia”
Inactive “intel”

Section “Device”
Identifier “nvidia”
Driver “nvidia”
BusID “PCI:2:0:0”

Section “Screen”
Identifier “nvidia”
Device “nvidia”
Option “AllowEmptyInitialConfiguration”

Section “Device”
Identifier “intel”
Driver “modesetting”

Section “Screen”
Identifier “intel”
Device “intel”

Exec=sh -c “xrandr --setprovideroutputsource modesetting NVIDIA-0; xrandr --auto”

The issue relates to all the recent drivers for the GPU including 384.90, 384.69 (may apply to other drivers as well, drivers prior to 384.69 can not be installed on this kernel at all)

Is there a workaround on this or is it just the kernel is incompatible with the driver?

There’s no known incompatibility regarding kernel version but another user reported problems getting it to run on latest gdm. So probably the xrandr commands don’t get started.
Was gdm/gnome recently updated on your system? Which version is installed?
Other than that, run nvidia-bug-report.sh and attach output file.

gdm3 --version

GDM 3.26.0

I aim to keep my system updated to the latest release from the repistories. I’ll post the result of the debug script later.

To see the autostart directory gdm is using, use
ps aux |grep gdm-x-session

Maybe add
logger setOptimus
to your optimus autostart file command line, then you can see in journal if it gets started and when.

  1. blackliting nouveau driver
    echo “blacklist nouveau” >> /etc/blacklist-nouveau.conf

  2. installing nvidia driver
    Do you want to intall the 32-bit library compatibilit binaries - YES

Note: getting a warning:
/usr/lib64/xorg/modules/extensions/libglx.so (No such file or directory)

  1. Driver installs successfully. Configuring prime and adding nvidia-drm.modeset=1 to /etc/default/grub then running update-grub

  2. Rebooting

  3. GDM gives a blank screen

  4. Editing /etc/gdm3/daemon.conf and uncommenting debug mode

Enable = true

Enable = true

  1. Running gdm3
    service gdm3 start

Getting a blank screen again

  1. Running nvidia-bug-report.sh

Link to log:

I have omitted the /usr/bin/nvidia-debugdump -D output as I’m not sure what binary data it contains. If required I could it to someone from nvidia support.

Please note that the notebook is with a touchscreen if it makes any difference during the debugging process.

Paths are set correctly:

I’m pretty sure the xrandr commands are starting as I tried removing the prime configuration and the kernel either crashes or gdm3 reports the graphical message “OOps. something went wrong and the system can’t recover”.

Driver and X is fine, it’s gdm starting the autostart file too early, too late or not at all.
Add the logger entry to the .dektop file so the line reads
Exec=sh -c “xrandr --setprovideroutputsource modesetting NVIDIA-0; xrandr --auto ; logger setOptimus”
and copy that file also to /etc/xdg/autostart/
reboot and post the journal.txt from
journalctl -b 0 --no-pager >journal.txt

The xrandr command is always copied to /etc/xdg as well. Output wil be posted in few minutes.

Here’s the output (irrelevant entries have been removed):

The following lines brought attention:
Sep 23 21:44:53 nvdebug gnome-session[1111]: gnome-session-binary[1111]: WARNING: Could not parse desktop file optimus.desktop or it references a not found TryExec binary

Sep 23 21:44:53 nvdebug gnome-session-binary[1111]: WARNING: Could not parse desktop file optimus.desktop or it references a not found TryExec binary

Ok, at least we now we know it gets started and at the right time, between the xserver and gnome-shell.
Now to find out why it fails. Either it was due to the change adding the logger, or it failed because of sh not found, maybe the path has to be set. Or it failed due to being more complex containing ".
To test, revert to the version you had before, and see if the error is gone.
If not, add the path to sh to it, like Exec=/bin/sh -c …
If there are still errors, put the xrandr commands in a script, make it executable and call that from the .desktop file.
If at one point the error is gone or different, post the relevant lines from journal.

Already tried providing the full path to the binary, also tried different variations of the quotes. Tried with /bin/sh, /bin/bash as well. Tested the command manually and it works fine. I’ve looked up for the error on google and there are plenty of threads from people getting the same warning (exec related) after updating gdm3 on various Linux distributions. Seems to be a gdm3 related bug. I’ll try placing it in an executable and call it directly from a .desktop file and let you know of the result.

Thanks for all your prompt answers.

Issue has been resolved. The problem is in gdm3 parsing some special symbols which seem to be included in the nvprime configuration script I wrote, which can not be seen in a text editor:

# diff optimus.desktop optimus.valid.desktop
< [Desktop Entry] 
< Type=Application 
< Name=Optimus 
< Exec=sh -c "xrandr --setprovideroutputsource modesetting NVIDIA-0; xrandr --auto" 
< NoDisplay=true 
> [Desktop Entry]
> Type=Application
> Name=Optimus
> Exec=sh -c "xrandr --setprovideroutputsource modesetting NVIDIA-0; xrandr --auto"
> NoDisplay=true

Showing the difference using cat -A (-A show all if you’re lazy)

# cat -A optimus.desktop
[Desktop Entry] $
Type=Application $
Name=Optimus $
Exec=sh -c "xrandr --setprovideroutputsource modesetting NVIDIA-0; xrandr --auto" $
NoDisplay=true $

# cat -A optimus.valid.desktop
[Desktop Entry]$
Exec=sh -c "xrandr --setprovideroutputsource modesetting NVIDIA-0; xrandr --auto"$

The file optimus.valid.desktop is the valid and working one. As you can see, the files seem to contain the same but not quite, as the ascii values represented by the file are different due to symbols not being shown (like any whitespaces or newline characters). The issue lies in the following code of my bash script:

gdm_entry='[Desktop Entry]
\nExec=sh -c "xrandr --setprovideroutputsource modesetting NVIDIA-0; xrandr --auto"

and then writing it to a file without using double quotes:

echo $gdm_entry > $gdm_setup_file

The above code becomes, respectively:

gdm_entry='[Desktop Entry]
Exec=sh -c "xrandr --setprovideroutputsource modesetting NVIDIA-0; xrandr --auto"
echo "$gdm_entry" > $gdm_setup_file

diff After the above changes:

# diff optimus.desktop optimus.valid.desktop 

(no difference)

For anyone getting the same issue check carefully whether your file doesnt contain any newlines or system characters not shown by the editor. If needed rewrite it by hand.

I will update the nvprime.sh script with the appropriate changes. Please note that the original script used to work for gdm versions up to 3.24.

Bottom line the nvidia driver, nvidia prime and GDM3 are working fine. The issue occurs due to gdm3 not handling special characters properly.

@generix, once again thank you for all your help (actually I can’t express how grateful I am - this has been bothering me for quite some time, I run several VMs at the same time on occasions and GPU performance can be really important at times) - wouldn’t have figured this out without knowing how to debug the prime configuration. Also thank you for pointing out the nvidia driver and X are working as they are expected to.

The thread is now marked as solved.

That’s a rather unexpected outcome, things like that can drive people crazy. The .desktop file parsing is done by glib afaik. Maybe make a bug report there.

Indeed, rather unexpected:)) - couldn’t say it better. Stuff like this has to be debugged with cold-blood hehe. At least I know how to debug this stuff now so let’s say it’s a lesson learned. Thanks once again for answering promptly - thought this wouldn’t get resolved for weeks.

NVPrime configuration script updated:

Hi nospam_ out of curiosity, are you using an external display and do you have prime-sync enabled (nvidia driver in modeset?).

_nospam has nvidia-drm.modeset=0 set, so no.
You’re the one I mentioned having problems setting up recent gdm, I think. Obviously regarding prime sync, why not opening a new thread?

I don’t know what the bug is, but the problem is gdm3 doing something that other display managers don’t do. Maybe the root cause is a nvidia problem with modeset and wayland, but the immediate problem seems to be gdm3, which is why I don’t think this the right forum.

Actually I have nvidia-drm.modeset=1 set in /etc/default/grub
With previous configurations the prime worked fine even without it. With the most recent versions I haven’t tried.

@TimRichardson I’m not using an external display, but when I connect one via hdmi it works just fine.

Hi all.
I wrote a script 2 years ago for Prime switching there [url]https://github.com/wildtruc/nvidia-prime-select[/url]. It was working just fine until I realize that it didn’t on more recent distros.

After reading nopsam_ work, I realise I have a lot to do to make it working again.

Then it’s done and i’m in testing process, but not on Github yet.

For Gnome3, with the previous script, I had the same problem of the blank screen. It appears that xrandr need to wait gdm starting before being launched. I don’t have gdm anymore (Fedora 27 compiz-mate with lightdm), but this is here maybe the same issue.

With nospam_ help (and you already helped a lot), maybe we could fix this and find a work-around. resulting work is not on Github yet, but I can give a temporary dl page until Github uploading.