search

BlenderVR / source

Blender Virtual Reality Main Code
52 stars 21 forks source link

Unable to open a display #38

Closed godbyk closed 8 years ago

godbyk commented 8 years ago

I'm trying to run BlenderVR on a local Linux box. When I click the Start button, the following appears in the console window:

No protocol specified
Unable to open a display

The DISPLAY environment variable is being set properly in the XML file (to :0.0) and I can run blenderplayer (and blender) locally without any problems.

Do you have any suggestions on how I can resolve or further troubleshoot this issue?

godbyk commented 8 years ago

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 commented 8 years ago

Could you send me your configuration file?

godbyk commented 8 years ago

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

PyrApple commented 8 years ago

can you run xclock after ssh connection to localhost?

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

godbyk commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

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.