DISPLAY environment variable not pulled correctly

[olly1240]

Hi, I recently tried to set up VirtualGL. I compiled VirtualGL 2.6.5 from source with SSL enabled on both machines (Arch 5.12.2).
I found out, after setting the server up, that after connecting with vglconnect, vglrun does not pull the correct DISPLAY value from the environment.

I'm using Nouveau but, since it is an old card, that is basically nearly fully supported, and since after setting manually the display everything runs correctly, I think it has nothing to do with mesa.

I apologize if this issue has been discussed before, I haven't found anything by a quick search.

[dcommander]

It's very likely an issue stemming from a misunderstanding of how VirtualGL is supposed to work. Please clarify how you expect it to work and how it is not working as you expect. You're jumping to conclusions about the source of the problem, and in doing so, you're leaving out important details that would help me understand what's happening.

[olly1240]

When I connect to the remote machine with vglconnect, it sets the DISPLAY environment variable. When I try to run anything with vglrun I get Cannot connect to display :0 and I need to set manually the display by looking at env and then run vglrun -d _display_. I thought that the default behavior should be that vglrun tries to display the app on the local machine and not on the remote.

Edit: I'm trying to use x-11 forwarding from the remote machine

I'm sorry if I'm not giving you enough information or if I'm not clear enough, I don't want to waste your time. If you need something more specific about my issue please tell me everything you might need.

[dcommander]

When I connect to the remote machine with vglconnect, it sets the DISPLAY environment variable. When I try to run anything with vglrun I get Cannot connect to display :0 and I need to set manually the display by looking at env and then run vglrun -d _display_. I thought that the default behavior should be that vglrun tries to display the app on the local machine and not on the remote.

I think you're misunderstanding how VirtualGL is supposed to work. Let's start with the fact that, when using VirtualGL 2.6.x, there are two X servers. The "3D X server" is on the remote machine and is used by VirtualGL solely for accessing the GPU. The 3D X server is specified using vglrun -d or the VGL_DISPLAY environment variable, and it defaults to :0.0 if unspecified. The "2D X server" is on the local (client) machine in your case, since you're using vglconnect and not an X proxy such as Xvnc or FreeNX or Xpra or whatnot. When you use vglconnect with no arguments, the vglconnect script wraps ssh -Y, which causes non-OpenGL X11 commands to be forwarded through SSH. Thus, the DISPLAY environment variable in the SSH session should be of the form localhost:n.0. vglconnect does not set DISPLAY at all. SSH does. The error message about Display :0 is probably coming from the VirtualGL Faker, which is trying to open a connection to the 3D X server in order to access the GPU. It won't be able to do that unless you first run vglserver_config on the server machine to grant access to the 3D X server. Please follow the instructions in the VirtualGL User's Guide in that regard, including the "Sanity Check" section that explains how to test for a successful 3D X server connection before using vglrun.

[olly1240]

I apologize, I completely misinterpreted how VirtualGL works, I did not understand that a running X instance using the card was needed on the 3d renderer. I am very sorry for wasting your time and I greatly appreciate the effort and the time you spent for my issue. Thank you for your patience

[dcommander]

VirtualGL 3.0 will have an optional EGL back end, so a 3D X server will not be needed. You can test that feature in the 3.0 evolving pre-release build (https://virtualgl.org/DeveloperInfo/PreReleases). It has a couple of known bugs at the moment but should mostly work.