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.
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.
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
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…
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
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…
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
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
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…
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.
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?