Blank screen/no input on 334.21, faulty glx?

with the latest nvidia driver on my Optimus system, when I xinit to use the nvidia card, X spins up and then shuts down the screen
I lose input and cannot switch VT’s to identify the problem, also forcing me to shut down.
this is the last line of my xorg log

[   523.253] (II) Initializing extension GLX

moving or renaming any component allows the process to boot normally and loads xterm with the understandable “no GLX visual”
here is the appropriate log section

[   330.164] (II) modesetting(G0): Damage tracking initialized
[   330.194] (II) config/udev: Adding input device Power Button (/dev/input/event3)
[   330.194] (**) Power Button: Applying InputClass "evdev keyboard catchall"
[   330.194] (**) Power Button: Applying InputClass "system-setup-keyboard"
[   330.194] (II) LoadModule: "evdev"
[   330.194] (II) Loading /usr/lib64/xorg/modules/input/
[   330.194] (II) Module evdev: vendor="X.Org Foundation"
[   330.194]    compiled for 1.14.3, module version = 2.8.2

this is new to the 334.21 driver as I have successfully offloaded graphics using the 331.20 binary

nvidia-bug-report.log.gz (143 KB)

Can you connect to the system via SSH? If so, can you please paste the output of the “xrandr” command? Please also attach the startup scripts you’re using to run the xrandr commands listed in chapter 33 of the README.

when ssh’d xrandr -d :2 hangs with no output no joy even with strace

my startup script

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto
#export LD_LIBRARY_PATH=/usr/lib/nvidia/
#export LD_LIBRARY_PATH=/usr/lib64/xorg/nvidia/
#ldconfig -l /usr/lib/nvidia/
#ldconfig -l /usr/lib64/xorg/nvidia331/
#export LD_LIBRARY_PATH=/usr/lib64/xorg/nvidia/modules/extensions/
nvidia-settings &
exec xterm

this is my xorg.conf.nvidia as it may be of interest

Section "ServerLayout"
	Identifier "layout"
	Screen	0 "nvidia"  
	Inactive "intel"

Section "Module"
	#Disable	"glx"
	#load	""
	#load	"/usr/lib/nvidia/"
	#load	"/usr/lib64/xorg/nvidia/"


Section "Files"
	#ModulePath 	"/usr/lib/nvidia/"
	ModulePath	"/usr/lib64/xorg/nvidia/"
	ModulePath	"/usr/lib64/xorg/modules/"

Section "Device"
	Identifier	"nvidia"
	Driver		"nvidia"
	BusID		"PCI:1:0:0"
	Option 		"UseEDID" "false"
	#Option		"Sync to vblank" "false" 
	Option "OnDemandVBlankInterrupts" "1"
        #Option 	"ConnectedMonitor" "VGA-0"

Section "Device"
	Identifier	"intel"
	BusID		"PCI:0:2:0"
	Driver		"modesetting"
	#Option		"ConnectedMonitor" "VGA-0"

Section "Screen"
	Device		"intel"
	Identifier	"intel"

Section "Screen"
	Identifier	"nvidia"	
	Device          "nvidia"
	Option		"AllowEmptyInitialConfiguration" "True"
	#Option		"UseDisplayDevice" "VGA-0"
	#Option         "UseDisplayDevice" "none"
	#Option	"Coolbits" "2"
	#Subsection "Display"
		#Depth 	24
		#Modes	"1366x768_60.00" "1280x720_60.00"

connecting a monitor to the HDMI nets me a nvidia splash logo and stays there
the log again reads
(II) Initializing extension GLX

so any new headway on this?
i’m still working on my end but its a frustrating glitch to encounter

i’m just curious do i even have the right file?
sha1sum 9f86d9c1ea34a84b3c9ca7c41918692aa7c4984b
md5sum cb2d99ddc51639efe52dfa60d50b6f79

in my PATH there was a (dead) libnvidia-glcore symlink to the previous driver, 331.20, despite the fact that the correct link also existed is the same file.
while installing the the 337.12 binary i cleaned up both links before prefix installing the opengl files, this behavior subsequently vanished
its possible the driver checks for the correct file but loads whichever one it sees first resulting in the lockout
unfortunatly i have no means of fixing, checking, or reporting this bug