No protocol specified; unable to open display

Help
2011-01-18
2013-11-26
  • Steven Peckins
    Steven Peckins
    2011-01-18

    VirtualGL is only working remotely when the same user is logged on to X locally.  /etc/opt/VirtualGL/vgl_auth_key does not exist.  Video card is nVidia GeForce GTX470.  OS is Linux/amd64.

    Stopped gdm.
    Ran vglserver_config (Y/Y/n).
    Restarted gdm.
    VGL doesn't work.

    Stopped gdm.
    Ran vglserver_config (n/n/n).
    Restarted gdm.
    VGL doesn't work.

    Stopped gdm.
    Ran vglserver_config (Y/Y/n).
    Deleted /etc/modprobe.d/virtualgl.conf and modified existing nvidia.conf instead.
    Restarted gdm.
    VGL doesn't work.

    - Verified 750 permissions on /etc/opt/VirtualGL/
    - Verified 660 permissions + vglusers group for Section DRI in xorg.conf
    - Verified 660 permissions for root:vglusers on /dev/nvidia*
    - Verified user is in vglusers group
    - Verified X is running on :0

    Here are the errors I get (after vglconnect'ing):

    ~ $ vglrun +v glxgears
    NOTICE: Automatically setting VGL_CLIENT environment variable to
        172.20.77.164, the IP address of your SSh client.
    NOTICE: Replacing dlopen("/lib/libdl.so.2") with dlopen("libdlfaker.so")
    Shared memory segment ID for vglconfig: 51249154
    Opening local display :0
    No protocol specified
    ERROR: Could not open display :0.

    ~ $ glxinfo -display :0
    No protocol specified
    Error: unable to open display :0

     
  • DRC
    DRC
    2011-01-18

    What distribution and version is your OS?

     
  • Steven Peckins
    Steven Peckins
    2011-01-18

    Gentoo Linux 2.6.37 x86_64

     
  • Steven Peckins
    Steven Peckins
    2011-01-18

    Oh, also VirtualGL 2.2 w/ libjpeg-turbo 1.0.90 compiled from sources w/ gcc 4.5.2 and running xorg-server 1.9.2.

     
  • Steven Peckins
    Steven Peckins
    2011-01-18

    I think it might be related to xauth.  The /etc/opt/VirtualGL/vgl_xauth_key file does not exist/is not created, and I get the following in Xorg.0.log when I try to "vglrun glxgears" (X is running with "-audit 4"):

    ~ $ tail -n0 -f /var/log/Xorg.0.log
    AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 rejected from local host ( uid=1001 gid=1002 pid=3010 )
    AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 disconnected
    AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 rejected from local host ( uid=1001 gid=1002 pid=3010 )
    AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 disconnected

    1002 is the user's group, not vglusers (1001).

    ~ $ ps aux | grep X
    root      9701  0.1  0.0 143600 33324 tty8     Ss+  11:23   0:01 /usr/bin/X :0 -audit 4 -auth /var/gdm/:0.Xauth -nolisten tcp vt8

     
  • DRC
    DRC
    2011-01-18

    vglserver_config is supposed to modify the gdm or kdm startup files so that the "vglgenkey" script is invoked whenever the display manager starts up.  If vgl_xauth_key is not being generated, that means that vglgenkey is not being invoked, which probably means that your system stores its gdm config files in a place that vglserver_config doesn't know about.  The GDM startup script is usually called ":0" or "Default" - some systems have both, in which case one usually invokes the other.  Most systems also have a file called "Xsetup" as well.  Sometimes, :0 or Default are just symlinks to Xsetup, but other times they are different files.  If you could examine your system and verify the locations of :0, Default, and Xsetup under /etc, that will help me determine whether vglserver_config knows about those locations.  Since I've never tested Gentoo, it's possible that it doesn't.

     
  • Steven Peckins
    Steven Peckins
    2011-01-18

    Ah ha!  Got it.  vglgenkey was in the gdm Init/Default script, but it wasn't in the $PATH (if there even is one).  I just needed to "absolutize" it - /usr/local/bin/vglgenkey.

    The gdm startup script is /etc/X11/gdm/Init/Default in Gentoo.  There are no :0 or Xsetup files under /etc.  I'd gone through the config script and confirmed that it had done what it's supposed to do.  The nvidia module config file was /etc/modprobe.d/nvidia.conf rather than just nvidia, so I altered it to match virtualgl.conf and deleted virtualgl.conf.

    Thanks!

     
  • DRC
    DRC
    2011-01-18

    Ah, yes, vglserver_config on Linux does assume that vglgenkey is in the PATH, because vglgenkey is installed under /usr/bin in the VirtualGL binary packages.  One of my hot projects is to overhaul the VGL build system using CMake (seeking funding for that project), and as soon as that happens, I can generate vglserver_config at build time and populate it with whatever install prefix the user selects.

     
  • DRC
    DRC
    2011-01-19

    Checked in a patch to CVS head which should hopefully address this problem.  vglserver_config now looks for vglgenkey in the same directory as itself and will modify the GDM startup file to invoke vglgenkey using its full pathname.  That should allow vglserver_config to work properly regardless of whether the vglgenkey directory is in the PATH.  Also modified the default 'make install' prefix to /opt/VirtualGL, to more closely mimic the official binary packages.

     
  • Steven Peckins
    Steven Peckins
    2011-01-19

    That will also solve another issue I was going to mention - when connecting with the "-s" option, vglconnect looks for vgllogin in that location (/opt/VirtualGL/bin) while the default make install path is (was) /usr/local.

     
  • DRC
    DRC
    2011-01-19

    Ugh.  Yeah, that's one I may not be able to fix.  The client doesn't have any knowledge of where things are on the server, so it has to assume that they're located in one standard location (/opt/VirtualGL.)  I can make some of VirtualGL's functionality work from an arbitrary directory, but in order to make the whole system work, it really needs to be in /opt/VirtualGL.

     
  • Steven Peckins
    Steven Peckins
    2011-01-19

    Would an environment variable be a possible solution?  Say VGL_REMOTE_PATH or VGL_LOGIN or something, which, if not set, would otherwise default to "/opt/VirtualGL".

    VGL_REMOTE_PATH="/usr/local/bin" vglconnect -s hostname

     
  • DRC
    DRC
    2011-01-20

    Done and checked in.  I used VGL_BINDIR as the variable name.  You can also pass it as an argument (-b) to vglconnect.

     
  • Devansh
    Devansh
    2011-04-27

    I am facing the same problem as speckins. I am using ubuntu 10.10 with NVIDIA GTX 480.

    1) sudo service gdm stop
    2) sudo /opt/VirtualGL/bin/vglserver_config
    3)sudo service gdm start
    4)xdpyinfo -display :0 //unable to open :0

    First I tried from my laptop dell studio 1555 it worked nicely but now I am doing from my desktop Area 51 with Ubuntu 10.10 and NVIDIA GeForce GTX 480 it is now able to start. I tried the solution provided by speckins but didn't understand. So I might be wrong in doing what he said.

    I did

    1) sudo mv /etc/modprobe.d/nvidia-graphics-driver.conf  /etc/modprobe.d/nvidia
    2) sudo rm /etc/modprob.d/virtualgl.conf

    Then again I tried executing above commands but the same error

     
  • Devansh
    Devansh
    2011-04-27

    I am sorry in the earlier post it should be "First I tried from my laptop dell studio 1555 it worked nicely but now I am doing from my desktop Area 51 with Ubuntu 10.10 and NVIDIA GeForce GTX 480 it is NOT able to start"

     
  • DRC
    DRC
    2011-04-27

    Doubtful it's the same problem, since you can note from the posts above that his issue was related to the fact that he was installing VirtualGL in a non-standard directory, and we fixed that.

    Your procedure above would never work if you answered "yes" to enabling vglusers access when you ran vglserver_config.  If that was the case, then you would have needed to run 'xauth merge /etc/opt/VirtualGL/vgl_xauth_key' prior to testing access using xdpyinfo.  You would have also needed to log out/log back in if your account was just added to the vglusers group.  See the VirtualGL User's Guide, as it goes into detail about the procedure necessary to set up VirtualGL using vglserver_config.  Please follow that procedure and see if it fixes your problem.

    If that is not the problem, then you need to examine the GDM startup scripts as speckins did and figure out whether vglgenkey is being added to them and, if so, whether the correct path for it is being specified.