Unable to open a display about source

[godbyk]

I enabled some debug options and got more info printed to the console:

 2015-10-27 14:19:32,057 Command to run daemon: /usr/bin/python3 /home/godbyk/git/BlenderVR/source/utils/daemon.py memex:31416 console debug
 2015-10-27 14:19:32,058 Its environment variables: {}
 2015-10-27 14:19:32,102 Daemon for screen 'console' started
 2015-10-27 14:19:36,413 Command to run blenderplayer: /home/godbyk/blender/blenderplayer -d -w 400 400 .basic.vr.blend - memex:31416 console
 2015-10-27 14:19:36,414 Its path: /home/godbyk/git/BlenderVR/samples/basic/basic
 2015-10-27 14:19:36,414 Its environment variables: {'DISPLAY': ':0.0', 'PYTHONPATH': '/home/godbyk/git/BlenderVR/source/modules'}
No protocol specified
Unable to open a display

[PyrApple]

Could you send me your configuration file?

[godbyk]

@PyrApple Do you have any other suggestions on how to troubleshoot this? Thanks!

[PyrApple]

can you run xclock after ssh connection to localhost?

ssh memex@localhost (or ssh -X memex@localhost)
xclock

[godbyk]

If I use ssh -X localhost and run xclock, it works okay. If I leave out the -X option, it fails to open the display.

Does BlenderVR ssh to the localhost when running on a single machine? Do I need to enable X-forwarding by default?

[PyrApple]

yes it does ssh to localhost (for uniformity's sake with more complex architectures). try enabling X-forwarding but I doubt that's the issue.
What appends if you replace the path to blenderplayer with xclock's in BlenderVR configuration file? (e.g. )

[godbyk]

Hmm.. this is interesting.

First, I have not enabled X-forwarding by default yet.

I created a shell script to run xclock (so that xclock wouldn't complain about the blenderplayer command-line arguments). I pointed the blenderplayer tag at the shell script and when I started everything up, the xclock program ran properly.

Next, I reverted back to the original blenderplayer executable instead of the xclock shell script and blenderplayer ran just fine.

I have no idea why.

(My testing this evening has been on my home PC which was exhibiting the same problems as my work PC. I'll test my work PC again and see if swapping out xclock works there as well.)

[dfelinto]

The -X means you have the X11 running in your station, not in the remote computer (which is what we want). The xhost option is what allows remote users with a different user than the owner of the X11 session to spawn new process in the remote X11.

But if I got it right, things are working at the moment, correct? If so can we close this report?

I believe that what happens is that by manually calling xclock via the terminal you went through an authentication step which you couldn't see when calling it via BlenderVR. And once you authorized the process every other process can run there.

[godbyk]

It's working on the second computer I encountered the problem on, but I haven't tested it on the first yet. I'll close this issue once I've confirmed it works there.

Regarding the authorization notion, how can I check that?

I'm aiming to run BlenderVR across a Linux cluster which drives a CAVE, so this problem will be exacerbated when I try to run it on 49 nodes.

[godbyk]

I've tested this on my work computer and the solution there seems to be to run xhost + prior to running BlenderVR.

My next step it to test this on our cluster. But I'll close this issue.

Thanks for your help, @PyrApple and @dfelinto.

[Cygn]

I'm strangely hit by this. running "xhost +" doesn't help. also I've got ssh X forxarding enabled, I can "ssh localhost" then xterm or anything gui.
main-linux.xml.txt
Any pointers ?
Thx.

[Cygn]

For future reference:
In recent fedora, if gdm is configured to use X instead of wayland, it doesn't quit on login and keeps the VT1 as a lone xsession. A new X session is spawned on vt2 for the desktop so the default DISPLAY is :1 instead of :0.0. I guess blenderVR expects the DISPLAY at 0.0, hence the breakage.