319.32 - The infamous blank black screen...?

I have done extensive searching and I can’t find a solution that resolves my issue.

Machine & software specs:
Dell XPS 17 (L702X) BIOS A19
GeForce GT 555M
Intel Sandybridge integrated
Intel Core i7-2720QM (2.2GHZ)

Fedora 19 (Schrodinger’s cat)
Linux 3.9.9-301-fc19.x86_64
nVidia 319.23 driver
X.Org X Server 1.14.2
xrandr 1.4.0

I followed the instructions in the readme, but I get a blank black screen. I’ve tried both Intel and modesetting drivers for the integrated graphics, but I get the same results.

.xinitrc contents (double checked +x):

xrandr --setprovideroutputsource Intel NVIDIA-0
xrandr --auto

DISPLAY=:0.0 sudo xrandr --listproviders

Providers: number : 2
Provider 0: id: 0x2b8 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-0
Provider 1: id: 0x45 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 4 associated providers: 0 name:Intel

It’s almost like something is crashing, but that information isn’t making it to the screen or to the Xorg.0.log.

Xorg.o.log: http://pastebin.com/6AhPpQuu
xorg.conf: http://pastebin.com/88QjaVzj

I updated to 319.32, but same issue…

I did notice that the F19 3.9.9 kernel has CONFIG_DRM enabled as a module, but only two of the seven driver interfaces were found in the modules.symbol file.

In other words, I can’t find these:

gem_prime_pin
gem_prime_get_sg_table
gem_prime_import_sg_table
gem_prime_vmap
gem_prime_vunmap

Is this an indication that F19 kernel doesn’t have the necessary patches / support?

try xrandr --fb <supported_resolution_for_both_display> e.g. xrandr --fb 1024x768

The only way I can run any xrandr is if I prepend DISPLAY=:0.0 and run as sudo:

DISPLAY=:0.0 sudo xrandr --fb 1024x768

X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 7 (RRSetScreenSize)
Serial number of failed request: 14
Current serial number in output stream: 16

Just a long shot, but have you tried manually starting X through a TTY? Also, have you tried adding

Option "UseDisplayDevice" "none"

to your xorg? Also, have you tried connecting an external monitor to your laptop?

The “UseDisplayDevice” “none” Option is in my xorg.conf and in addition to it, I have tried setting it to “DFP” or “DFP-0” but that forces X to complain of “no screen”

I have not tried an external monitor.

If I manually try to startx from another terminal X server crashes with a segmentation fault at address 0x418. This crash is not seen in the original boot logs; so, I’m unsure if this crash is due to it interfering with the first x load that results in a black screen or what…

Backtrace:

/usr/bin/X (OsLookupColor+0x129) [0x46edb9]
/lib64/libpthread.so.0 (__restore_rt+0x0) [0x390fc0ef9f]
/usr/bin/X (RRCrtcDetachScanoutPixmap+0x44) [0x5022f4]
/usr/bin/X (RRCrtcDetachScanoutPixmap+0x181) [0x502521]
/usr/bin/X (RegisterResourceName+0x222) [0x458ff2|
/usr/bin/X (FreeClientResources+0x97) [0x459f47]
/usr/bin/X (FreeAllResources+0x47) [0x45a007 ]
/usr/bin/X (_init+0x3ade) [0x429b7e]
/lib64/libc.so.6 (__libc_start_main+0xf5) [0x390f421b75]
/usr/bin/X (_start+0x29) [0x4267b1]
? (?+0x29) [0x29]

Segmentation fault at address 0x418

I had the same issue with the crash. You need to start the desktop manager as well. Try putting

exec <DM>

at end of your .xinitrc file, where is your desktop manager. For instance, i use MATE, so mine says

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto
exec mate-session

I added exec gnome-session and manually starting X reproduces the black screen of the original boot-up process, but when I check the log it still has a segmentation fault crash. Backtrace is identical…

I had a slightly different error that would show up, but did get the black screen/crash at some point. Since our systems are pretty much identical (I have a 750M instead of 555M), I suggest you take a look at

https://forums.freebsd.org/showthread.php?t=40664

where I posted how I finally managed to boot using NVIDIA.

I’d imagine it would work since we’re running the same OS/kernel/xrandr version. (Though my xserver is 1.14.1-4.fc19 ).

Also, if it doesn’t work let me know so I don’t upgrade my xserver to 1.14.2!!!

Still not working. My xorg.conf is practically identical to yours now…

I see a few main differences in our setup:

  • 750M vs 555M (shouldn’t be an issue)
  • xserver 1.14.1-4 vs 1.14.2-4 (highly suspect)
  • modesetting driver vs Intel driver (tried both… no go)
  • Mate vs Gnome 3 (highly suspect)

A further note, I assumed the black screen was just blank, but after reading your post I attempted to play with some key combos to see if that was true. In fact, I can login to the machine and launch a terminal, but I just can’t SEE anything… so… yeah. No clue…

Update:

Downgraded to xserver 1.14.1-4 but no difference…

I don’t have a clue either then. There was a thread on this that I read a good 20 times last week when I was going through the same thing. You might have already read through it, but in case you haven’t it’s at

https://devtalk.nvidia.com/default/topic/539322/blank-screen-with-319-12-on-optimus-laptop/

I think they do mention using lightdm instead of gdm (gnome) for solving the black screen at some point. I did not pay attention to that part too much because I replaced gnome3 with mate right off the bat.

If your X server is really 1.14.2, then it’s missing this patch:
xfree86: don’t enable anything in xf86InitialConfiguration for GPU screens
Without it, the sink device initializes to a black screen until you manually turn it off and on again. You’ll need to figure out what the output name is by running xrandr without the --listproviders option. Then modify your startup script to turn that output off before autoconfiguring the screen. E.g., on my laptop I need to run

xrandr --setprovideroutputsource Intel NVIDIA-0
xrandr --output LVDS1 --off
xrandr --auto

The crash at shutdown is fixed by this patch: http://patchwork.freedesktop.org/patch/13598/
The patch hasn’t been accepted upstream yet because Dave Airlie can’t reproduce the problem.

I am running 1.14.2 (upgraded back to it), but unfortunately I also already tried the xrandr --output <device> --off before posting my thread.

When I run xrandr by itself using the nouveau drivers, it shows LVDS1 connected, and so I assumed I needed to do xrandr --output LVDS1 --off; however, this does not work. I also tried LVDS-1, but I still get the black screen.

If I try running xrandr on a separate terminal after I’ve installed the Nvidia driver, this is my output:

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

At this point I can only assume that LVDS1 is the correct output, but that it just won’t work…

I was able to run:

DISPLAY=:0.0 sudo xrandr --setprovideroutput [Intel | modesetting] NVIDIA-0
`DISPLAY=:0.0 sudo xrandr

which produced output similar when using Nouveau.

When setting Intel my devices are LVDS1, VGA1, HDMI1, DP1, but when setting modesetting the devices are LVDS-0, VGA-0, HDMI-0, DisplayPort-0.

The only device connected in both situations is LVDS1 or LVDS-0, but xrandr --output [LVDS1 | LVDS-0] --off simply doesn’t do anything for me…

I give up… screw this.

care to explain how to apply the patch?

That patch has just been tweaked by Ubuntu:

-+    for (i = 0; i < rp->numCrtcs; i++)
++    for (i = 0; rp && i < rp->numCrtcs; i++)

Simple question. One month past. No answer. Nvidia at its best once again.

It’s an X server patch. How you apply it depends on how you’re building the X server. I wouldn’t recommend trying to build an X server yourself, but rather get a patched build from your Linux distribution.

Since I last wrote, the patch has been committed upstream: http://cgit.freedesktop.org/xorg/xserver/commit/?id=bdd1e22cbde9ea2324e4e1991c9e152f22f88151

brebs, the fact that Ubuntu needed that change is a little concerning. Do you know if Ubuntu provided any sort of description of how they got into the situation that needed that patch, or whether they reported it upstream?

Sorry, I don’t know more. I just rummage around their patches occasionally :)

I notice that Ubuntu’s latest changeset, xorg-server_1.14.2.901-2ubuntu1.diff.gz, still uses their rp && i < rp->numCrtcs tweak.

I suggest you contact Maarten Lankhorst.

highlightall, take a look at how patches are applied in thousands of your distro’s packages. It’s not Nvidia’s job to teach you about such things.

Fedora 20 was just released, so I thought I would try again… still the same issue (a blank screen upon boot).

Pretty terrible, Nvidia. Thank goodness Bumblebee works…